@grepr/cli 1.12.7 → 1.14.3-5fb972a

package/build/dist/docs-index/dac958ad-7daf-4e78-8524-0768caf550f0.txt

@@ -1,24 +0,0 @@
-# Get Organization
-
-**GET** `/v1/organization`
-
-**Operation ID**: `getOrganization`
-**Summary**: Get Organization
-Get the organization to which the authenticated user belongs.
-
-## Tags
-- Organizations
-## Responses
-
-### 200
-
-The organization for the authenticated user.
-
-- **Content-Type**: `application/json` / `Read`
-### 401
-
-Unauthorized
-
-### 404
-
-Not Found

package/build/dist/docs-index/db0ee715-0364-4b35-a21c-0bb8d25fb050.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/db0ee715-0364-4b35-a21c-0bb8d25fb050.txt

@@ -1,20 +0,0 @@
-# SumoLogSink
-
-**Type**: `object`
-
-## Properties
-
-- name: additionalAttributes (optional)
-  type: object
-  description: Additional attributes to add to the logs when writing to SumoLogic. Gets combined with the integration's additionalAttributes.
-
-- name: integrationId (required)
-  type: string
-  description: The New Relic integration id.
-
-- name: name (required)
-  type: string
-
-- name: type (required)
-  type: enum: `sumologic-log-sink`
-  description: Writes processed logs to Sumo Logic.

package/build/dist/docs-index/db4a9c11-d826-42cf-be24-6876e3e3f2b5.json

@@ -1 +0,0 @@
-{"docType":"api"}

package/build/dist/docs-index/db4a9c11-d826-42cf-be24-6876e3e3f2b5.txt

@@ -1,38 +0,0 @@
-# Resume a stopped investigation
-
-**POST** `/v1/investigations/{investigationId}/resume`
-
-**Operation ID**: `resume`
-**Summary**: Resume a stopped investigation
-Resumes a stopped (resumable) investigation in place. A non-blank message is appended as a new user turn; an empty body continues the agent with no added input.
-
-## Tags
-- Investigations
-## Parameters
-
-- **investigationId** (required) - path
-  - Type: string
-
-## Request Body
-
-**Content-Type**: `application/json`
-
-**Schema**: `ResumeInvestigationRequest`
-
-## Responses
-
-### 202
-
-Resume requested
-
-### 401
-
-Unauthorized
-
-### 404
-
-Investigation not found
-
-### 409
-
-Investigation is not resumable

package/build/dist/docs-index/db4c7b5b-dbb3-484d-87e7-12c75b6d7946.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/db4c7b5b-dbb3-484d-87e7-12c75b6d7946.txt

@@ -1,3 +0,0 @@
-# ScalarData
-
-**Type**: `object`

package/build/dist/docs-index/db7a77d0-b570-4764-b669-5d4602b99b3b.json

@@ -1 +0,0 @@
-{"docType":"doc"}

package/build/dist/docs-index/db7a77d0-b570-4764-b669-5d4602b99b3b.txt

@@ -1,117 +0,0 @@
-Connect another system's MCP server to Grepr so your AI agents can call the tools it publishes.
-
-# Configure MCP server connections with a Grepr integration
-
-An MCP integration connects Grepr to a Model Context Protocol server, or MCP server, run by another system. After you create one, you can let a Grepr AI agent call the tools that server publishes, so the agent gains capabilities, such as reading an incident, querying a dashboard, posting to a channel, or opening a pull request.
-
-> MCP integrations, along with the rest of the Grepr AI agent features, are in a closed beta. To request access, contact <support@grepr.ai>.
-
-> This page is about Grepr calling another system's MCP server. For the opposite direction, where an AI agent, such as Claude, calls Grepr's own MCP server, see [_](/apis/mcp).
-
-## Requirements
-
-To create an MCP integration, you need:
-
-* A credential for the system you are connecting. See [Create an MCP integration](#create) for where to get it.
-
-## What an agent can do through a connected server \[#server-tools]
-
-The tools an agent gains depend on the server you connect:
-
-| Type | What an agent can do with it |
-| --- | --- |
-| Datadog MCP | Read monitors, dashboards, logs, and metrics from your Datadog organization. |
-| GitHub MCP | Read and change repository content, issues, pull requests, and workflow runs. |
-| PagerDuty MCP | Read and act on incidents, services, and schedules. |
-| Slack MCP | Read and post messages in the channels the token can reach. |
-
-Each integration has a server URL you set, so you can point one at a self-hosted or regional endpoint rather than the vendor's.
-
-Don't see an MCP in the list? Send a request to <support@grepr.ai>.
-
-## Create an MCP integration \[#create]
-
-1. On the **Integrations** page, next to the **MCP Servers** section heading, click **Add new**.
-2. In the **Add MCP Server** dialog, select the server from the **Type** menu.
-3. Complete the remaining fields, which depend on the type you selected.
-4. Click **Create**.
-
-You cannot change an integration's type after you create it. You can change its other fields at any time, and each investigation picks up the change when it starts.
-
-Every type has a **Name** field, which identifies the integration when you configure an agent, and an **MCP Server URL** field. The remaining fields are the credential the server authenticates with.
-
-The credential decides what the agent can do through that MCP. Grepr passes it through as you supply it, so give the token minimal access for what the agent needs. Select the tab for the MCP you are connecting.
-
-| Field | Value |
-| --- | --- |
-| **MCP Server URL** | `https://mcp.datadoghq.com/v1/mcp`, or your regional Datadog MCP endpoint. |
-| **API Key (DD-API-KEY)** | A Datadog API key. |
-| **Application Key (DD-APPLICATION-KEY)** | A Datadog application key. |
-
-Create both keys in Datadog under **Organization Settings**. An application key carries the authorization scopes that decide what the agent can read, so scope it to the data you want the agent to reach, such as monitors, dashboards, and logs. To learn more, see [API and Application Keys](https://docs.datadoghq.com/account_management/api-app-keys/) and [Authorization Scopes](https://docs.datadoghq.com/api/latest/scopes/) in the Datadog documentation.
-
-If you already use Datadog as a Grepr source or sink, this is a separate integration. Reusing the same keys is fine. See [_](/integrations/datadog).
-
-| Field | Value |
-| --- | --- |
-| **MCP Server URL** | `https://api.githubcopilot.com/mcp/`, or your GitHub Enterprise MCP endpoint. |
-| **Personal access token** | A GitHub personal access token. |
-
-Create the token in GitHub under **Settings** > **Developer settings** > **Personal access tokens**. A fine-grained token is the better choice, because you can limit it to the repositories the agent works in.
-
-Grant the token access to the repository content, issues, pull requests, and workflow runs the agent needs. An agent that only reads code needs read access alone, and an agent that opens pull requests needs write access to contents and pull requests. To learn more, see [Managing your personal access tokens](https://docs.github.com/en/authentication/keeping-your-account-secure/managing-your-personal-access-tokens) in the GitHub documentation.
-
-| Field | Value |
-| --- | --- |
-| **MCP Server URL** | `https://mcp.pagerduty.com/mcp`, or your PagerDuty MCP endpoint. |
-| **Account URL** | Your PagerDuty account URL, such as `https://<your-org>.pagerduty.com`. Optional. |
-| **API Key** | A PagerDuty API key. |
-
-Create the key in PagerDuty under **Integrations** > **API Access Keys**. A read-only key lets an agent read incidents, services, and schedules, and a full-access key also lets it acknowledge or resolve incidents, so choose the one that matches what you want the agent to do. To learn more, see [API Access Keys](https://support.pagerduty.com/main/docs/api-access-keys) in the PagerDuty documentation.
-
-Grepr uses the **Account URL** to build links back to incidents in the actions an agent records, so set it if you want those links to resolve.
-
-| Field | Value |
-| --- | --- |
-| **MCP Server URL** | `https://mcp.slack.com/mcp`, or your Slack MCP endpoint. |
-| **User token** | A Slack user token, which begins with `xoxp-`. |
-
-Create a Slack app in your workspace, add the user token scopes the agent needs, then install the app to get the token. Grant `channels:read` and `channels:history` for an agent that reads channels, and add `chat:write` for one that posts. The agent reaches only the channels the token's user is in, so invite that user to the channels you want covered. To learn more, see [Access tokens](https://docs.slack.dev/authentication/tokens) in the Slack documentation.
-
-## Choose which tools an agent can call \[#allowed-tools]
-
-Creating an integration does not give any agent access to it. You enable an integration on each agent, and you choose which of the server's tools that agent can call. Two agents can therefore share one integration with different tool allowances.
-
-The tool allowance lives on the agent, not on the integration. To set it, go to the agent's **Capabilities** step, find the integration in the **MCP integrations** table, and edit its allowed tools. Grepr reads the tool list from the server, marks each tool as read only or writing, and lets you allow all tools or only the ones you select. To learn more, see [_](/ai-agents/capabilities#mcp-integrations).
-
-An agent can enable at most one GitHub MCP integration. The agent's `github_code` tool also requires an enabled GitHub MCP integration, because that is how it reaches source code.
-
-## Grant team access \[#team-access]
-
-When you have teams in your Grepr organization, you can grant access to the integration to one or more of those teams. To configure team access when you create or edit an integration:
-
-1. In the **Grant Team Access** section, click the plus sign icon (+).
-
-2. Select the team or teams that should be granted access to the integration.
-
-3. Click **Create**.
-
-To learn more, see [Manage teams in the Grepr platform](/admin/manage-teams) and [Permissions in the Grepr platform](/grepr-platform/permissions).
-
-## Frequently Asked Questions
-
-### Which MCP servers can Grepr AI agents connect to?
-
-You set each integration's server URL, so you can point one at a self-hosted or regional endpoint. Grepr adds integrations continuously, so contact support\@grepr.ai to get an agent connected to the server you use.
-
-### How do I limit which MCP tools a Grepr AI agent can call?
-
-The allowance is set on the agent, not on the integration. On the agent's Capabilities step, find the integration in the MCP integrations table and either allow all of the server's tools or select individual tools. Grepr reads the tool list from the server and marks each tool as read only or writing.
-
-### What is the difference between an MCP integration and the Grepr MCP server?
-
-An MCP integration lets a Grepr AI agent call another system's MCP server. The Grepr MCP server is the reverse: it lets an AI assistant such as Claude or Claude Code call Grepr to list pipelines, query logs, and propose pipeline changes.
-
-### How do I change an MCP integration after creating it?
-
-Edit it from the three-dot menu on the integration card. Investigations that start after the change use the new settings, and one already running keeps the settings it started with. An integration's type is fixed when you create it, so to move to a different server type, create a new integration.

package/build/dist/docs-index/db8b773e-43ec-4b60-9e80-1f8b73760f1e.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/db8b773e-43ec-4b60-9e80-1f8b73760f1e.txt

@@ -1,17 +0,0 @@
-# WriteSsoClaimMapping
-
-**Type**: `object`
-
-## Properties
-
-- name: claimKey (required)
-  type: string
-
-- name: claimValue (required)
-  type: string
-
-- name: roleIds (required)
-  type: array of string
-
-- name: teamAssignments (required)
-  type: array of `TeamAssignment`

package/build/dist/docs-index/dbd1ed83-2ffe-4974-abe7-e09e39036b96.json

@@ -1 +0,0 @@
-{"docType":"doc"}

package/build/dist/docs-index/dbd1ed83-2ffe-4974-abe7-e09e39036b96.txt

@@ -1,248 +0,0 @@
-Learn how to configure how Grepr integrates with observability platforms and storage systems to support data ingestion, processing, and output in your pipelines.
-
-# Configure how Grepr integrates with observability platforms and cloud storage
-
-To support data ingestion and data output for your Grepr pipelines, you connect Grepr to external observability platforms and storage systems. To support these connections, the Grepr platform uses *integrations*. A Grepr integration provides the configuration details to connect to an external system, enabling data exchange between Grepr and that system.
-
-After configuring an integration, you can use it in your Grepr pipelines to create *sources* to ingest data from agents and collectors, such as FluentD or the OpenTelemetry collector, and *sinks* to send data to an observability platform or storage.
-
-You can use the Grepr UI or the REST API to create and manage integrations. To use the UI, see [Manage integrations in the Grepr UI](#manage-integrations-in-ui). To use the API, see the documentation for each [supported integration](#supported-integrations).
-
-## Integration types
-
-The Grepr platform includes the following integration types:
-
-* Observability platform integrations: Connections to monitoring, logging, and APM platforms, such as Datadog, Splunk, New Relic, and Sumo Logic.
-* Cloud storage integrations: Connections to cloud storage. The Grepr data lake uses cloud storage to store your raw data and metadata.
-* AI integrations: Connections that Grepr AI agents use, covering the model providers they reason with, the MCP servers they call, the webhook endpoints that trigger them, and the vector indexes that store their memories. See [Supported AI integrations](#ai-integrations).
-
-Observability platform and cloud storage integrations become the sources and sinks of your pipelines. AI integrations are used by AI agents instead, so they are not selectable as a pipeline source or sink.
-
-## Supported platform and storage integrations \[#supported-integrations]
-
-The Grepr platform includes the following integrations. For details on configuring and using an integration, refer to the linked documentation page. For a complete list of supported integrations, supported functionality, and details on vendor-specific capabilities with some integrations, see [Grepr supported vendor and storage integrations](/integrations/support-matrix).
-
-### Datadog
-
-The Datadog integration connects to the Datadog observability platform and supports sourcing data from several Datadog-compatible collectors and sending processed data to Datadog.
-
-See [Configure Datadog connections with a Grepr integration](/integrations/datadog).
-
-### New Relic
-
-The New Relic integration connects to New Relic's observability platform. Use this integration to create sources that retrieve log data from New Relic collectors and sinks that send processed data to New Relic for monitoring and analysis.
-
-See [Configure New Relic connections with a Grepr integration](/integrations/new-relic).
-
-### Splunk
-
-The Splunk integration provides connectivity to Splunk through Splunk's HTTP Event Collector (HEC) or S2S over HTTP. This integration supports reading data from Splunk collectors and writing data to Splunk indexes.
-
-See [Configure Splunk connections with a Grepr integration](/integrations/splunk).
-
-### Sumo Logic
-
-The Sumo Logic integration connects to Sumo Logic's cloud-based log management and monitoring platform using a Sumo Logic HTTP Source. You can use the integration to create sources that ingest data from Sumo Logic collectors and sinks that send processed data to Sumo Logic.
-
-See [Configure Sumo Logic connections with a Grepr integration](/integrations/sumo-logic).
-
-### OpenTelemetry
-
-The Grepr OpenTelemetry integration lets you ingest logs and Application Performance Monitoring (APM) data into Grepr from a collector that supports the OpenTelemetry Protocol over HTTP, or OTLP/HTTP, process them with a Grepr pipeline, and then send the processed data to any observability vendor that accepts OTLP/HTTP requests.
-
-See [Configure connections to OpenTelemetry compatible platforms](/integrations/open-telemetry).
-
-### Grafana Cloud
-
-You can configure Grepr's OpenTelemetry integration to connect with Grafana Cloud using the OpenTelemetry Protocol (OTLP). Use an OpenTelemetry integration to create sources that ingest data from OTLP-compatible collectors and sinks that send processed log data to Grafana Cloud.
-
-See [Configure Grafana Cloud connections with a Grepr integration](/integrations/grafana).
-
-### Amazon CloudWatch
-
-You can configure Grepr's OpenTelemetry integration to connect with Amazon CloudWatch using the OpenTelemetry Protocol (OTLP). Use an OpenTelemetry integration to create sources that ingest data from OTLP-compatible collectors and sinks that send processed log data to a CloudWatch log group.
-
-See [Configure Amazon CloudWatch connections with a Grepr integration](/integrations/cloudwatch).
-
-### Google Cloud Platform (GCP)
-
-The GCP integration as a source enables you to stream logs from Google Cloud services to Grepr for processing and analysis, and then forward the processed logs to any sink created using a Grepr-supported integration, such as Datadog, Splunk, or New Relic.
-
-See [Google Cloud Platform observability with Grepr](/integrations/gcp).
-
-### Cloud storage
-
-The Grepr data lake uses Amazon S3 to store, manage, and support querying the raw data from your Grepr pipelines. Depending on your requirements, you can choose from two S3 integrations: a Grepr-hosted integration, which uses a Grepr-managed S3 bucket, and an integration that uses an S3 bucket in your account. Both integrations provide secure, managed, and efficient storage for your data, along with an optimized query interface.
-
-To configure the Grepr-hosted integration, you only need to assign a name to the integration. The Grepr platform manages the S3 bucket, including its deployment and configuration.
-
-Using the integration with your own S3 bucket requires that you deploy and configure an S3 bucket in your AWS account, but it provides more control over your data. See [Host a Grepr data lake with the Amazon S3 integration](/integrations/aws-s3).
-
-## Supported AI integrations \[#ai-integrations]
-
-The following integrations support Grepr AI agents. They appear on the **Integrations** page only when AI agents are enabled for your organization. To turn on AI agents, contact <support@grepr.ai>. To learn what AI agents do, see [_](/ai-agents).
-
-### LLM providers
-
-An LLM integration holds the credentials for a large language model provider. Grepr AI agents use generative models for reasoning and embedding models for memories.
-
-See [_](/integrations/llm).
-
-### MCP servers
-
-An MCP integration connects Grepr to a MCP server run by another system, so an agent can call that system's tools during an investigation. You set each integration's server URL, so you can point one at a self-hosted or regional endpoint.
-
-See [_](/integrations/mcp).
-
-### Grepr Agent webhooks
-
-A Grepr Agent integration is a webhook endpoint that turns events from another system, such as an alerting platform or a Kubernetes event forwarder, into AI agent investigations.
-
-See [_](/integrations/grepr-agent-webhooks).
-
-### Vector indexes
-
-A vector index integration stores the search index for agent memory, which is what lets an agent find past investigations that reached a similar conclusion. You create one in the **S3 Vector Index** section of the **Integrations** page.
-
-See [_](/ai-agents/memory#vector-index).
-
-## Manage integrations in the Grepr UI \[#manage-integrations-in-ui]
-
-The **Integrations** page displays your integrations as cards, organized by observability vendor integrations and storage integrations. In each section, cards are ordered by recent activity, with the most active integrations appearing first.
-
-In addition to the integration name and its type, for example, a Datadog integration, if the integration is assigned to one or more teams, the team names appear in the header of the card.
-
-You can get a visual overview of the health and usage of your integrations using the charts included on each integration card. If an integration has recent activity, such as requests received from agents by a vendor integration or the amount of data written to a storage integration, a time-series chart of that activity is shown on the card.
-
-* Observability vendor integrations display requests received from agents over the last 30 minutes, color-coded by HTTP status code.
-
-  * To view more detailed metrics or more details about a pipeline that uses the integration, select it from the **Pipelines** menu.
-
-* Storage integrations display data written to the integration over the last 24 hours, broken down by dataset.
-
-  * To view and query a dataset stored on a storage integration, select it from the **Datasets** menu.
-
-To view more details about the metrics in either chart type, hover over any point in the chart to see a tooltip with the value and timestamp for that point.
-
-### Add an integration
-
-To create an integration, click **Add new** next to the section heading for the type you want to add. To learn how to create and configure specific integrations, see the documentation for each [supported integration](#supported-integrations).
-
-### Edit an integration
-
-To edit an integration, click the three-dot menu on the integration card and select **Edit**. Update the fields in the dialog and click **Save**.
-
-### Delete an integration
-
-To delete an integration, click the three-dot menu on the integration card and select **Delete**. Confirm the deletion in the dialog that appears.
-
-### Identify log events that should bypass aggregation \[#passthrough-estimation]
-
-When you create an integration with an observability vendor that supports *exception parsing*, Grepr automatically parses queries used by monitors, dashboards, or alerts in your observability vendor platform. You can use this list of queries to identify log messages that should be treated as *exceptions* to log reduction in Grepr pipelines. In other words, messages that should bypass aggregation to ensure that critical alerts and dashboards continue to work as expected. To help with identifying exceptions, the Grepr UI displays a *passthrough percentage* estimate for each query. This estimate is the percentage of events, over a configurable time window, that would bypass aggregation.
-
-You can also choose to automatically add and remove exceptions by enabling **Auto-sync exceptions** when you add the integration to your pipelines. To learn more about enabling and using auto-sync when you create or edit a pipeline, see [Prevent aggregation of messages used in your observability platform](/transforms/reducer/exceptions#vendor-exceptions).
-
-If an integration does not support exception parsing, the **Parsed Alerts** button on the integration card is disabled. See [Supported integrations: observability platforms](/integrations/support-matrix#supported-observability-integrations).
-
-To view the log queries parsed from an integration and configure passthrough estimation:
-
-1. On the **Integrations** page, on the card for a vendor integration that supports query parsing, click **Parsed Alerts**.
-
-   The **Parsed alert queries** dialog displays a table with the following columns:
-
-   * **Id**: The unique identifier for this alert.
-   * **Name**: The alert or dashboard name from your vendor.
-   * **Exception Type**: The type of vendor resource the query came from, such as a monitor or dashboard widget.
-   * **Query**: The log query extracted from the alert or dashboard.
-   * **Passthrough %**: The percentage of raw logs in your configured dataset that match this query. This value is displayed only if you've configured passthrough estimation.
-   * **Last Updated**: When the passthrough percentage was last calculated. Hover over the value to see the exact date and time.
-
-   You can filter the table by name or query text and filter by exception type using the multi-select filter in the **Exception Type** column. To manage which columns are visible, click the **Manage columns** icon in the upper-right corner of the table.
-
-2. To configure passthrough estimation and view the percentage of logs that would bypass aggregation for each query, click **Configure Passthrough Estimation**.
-
-   The **Passthrough Estimation Configuration** dialog lists the datasets that pipelines using the integration write to. Each row shows whether passthrough estimation is configured for that dataset and which pipelines use it.
-
-   > When you configure passthrough estimation for a dataset, it applies to all integrations or pipelines that use that dataset as a sink.
-
-3. Expand the row for the dataset you want to configure.
-
-4. Under **Filter Query (Optional)**, select your preferred query syntax and enter a query to filter for logs to include in the estimation analysis. Use this field when your dataset contains logs from multiple sources, and you want Grepr to use only the logs relevant to this integration. Leave this field empty to include all logs in the dataset.
-
-5. In the **Lookback Duration** menu, select the time window for calculating percentages. Options range from 15 minutes to 24 hours. A shorter window scans less data, reducing costs, but may not be representative if your log patterns vary throughout the day. A longer window provides more representative results but increases the cost of the analysis queries.
-
-6. In the **Refresh Period** menu, select how often Grepr recomputes each estimation for this dataset. Options range from 1 hour to 30 days, with a default of 7 days. A shorter period uses more recent logs to calculate estimates, resulting in more up-to-date values, but increases query load on the data lake.
-
-7. In the **Log Limit** field, enter the maximum number of logs to scan per estimation run. The default is 10,000,000. Larger limits provide more representative results, but increase the cost of each estimation query.
-
-8. To save a new configuration, click **Enable**. To save edits to an existing configuration, click **Save changes**.
-
-Grepr's impact estimation cycle runs once an hour for any datasets due for refresh, based on each dataset's **Refresh Period**. New or recently changed queries are included in the next cycle. A first estimate typically appears within an hour, though it might take longer if a large number of queries are queued for processing.
-
-To stop estimating for a dataset, expand its row and click **Disable estimation**. The dataset remains in the list as **Not configured** so you can re-enable estimation later.
-
-### Interpret passthrough percentages
-
-> Although two queries might use the same log events, their estimates will be equal. Additionally, the passthrough rate remains constant and is not the sum of the estimates. For example, if you enable exceptions for two queries that use the same log events, the passthrough rate doesn't double, but remains equal to the rate when only one exception is enabled.
-
-The **Passthrough %** value for a query shows what fraction of your raw logs that alert would require to pass through without aggregation. Use these values to evaluate the impact of adding each alert as a pipeline exception:
-
-A percentage less than 1% is considered low, and an exception should have minimal impact on aggregation efficiency and storage.
-
-You should review carefully any percentage above 1% before creating an exception for the query.
-
-A dash (—) in the **Passthrough %** column indicates that no estimate is available yet, either because passthrough estimation is not configured, or because Grepr hasn't finished calculating the estimate. If passthrough estimation is configured, the first estimate typically appears within an hour, and later refreshes occur based on the dataset's **Refresh Period**.
-
-The **Passthrough Estimation Configuration** dialog also includes the **Recent Activity** table at the bottom. This section shows the most recent log events related to exception parsing, giving you visibility into recent integration activity without leaving the dialog. To view the complete log history for the integration, click **View all logs** to go to the **System Logs** page, pre-filtered to show all activity for the selected integration.
-
-### Configure passthrough estimation from a pipeline
-
-You can also configure passthrough estimation directly from a pipeline. On the pipeline details page, in the left-hand navigation menu, click **Exceptions**. In the **Actions** column for an **Avoid impacting dashboards/alerts** exception, click the **⋯** menu and select **Configure estimations** to open a dialog that includes all datasets configured as sinks for the pipeline. Any configuration changes you make to the dataset apply to every other integration or pipeline that populates that dataset.
-
-To have Grepr recompute impact percentages during the next impact estimation cycle, click the **⋯** menu and select **Reset estimations** to clear the cached impact percentages for the datasets configured as sinks for the pipeline. Use this when you've changed alert queries in your observability vendor and want updated estimates without waiting for the next scheduled refresh.
-
-## Limitations \[#limitations]
-
-Grepr might split log events over 900KB, causing them to lose their original structured format. Each split event includes a common `grepr.splitOriginId` attribute if you need to reconstruct the original message.
-
-## Frequently Asked Questions
-
-### What is a Grepr integration?
-
-A Grepr integration provides the configuration details needed to connect Grepr to an external system, such as an observability platform or cloud storage. Integrations enable data exchange between Grepr and external systems, allowing you to create sources for data ingestion and sinks for data output in your pipelines.
-
-### What types of integrations does Grepr support?
-
-Grepr supports two integration types: observability platform integrations (connections to monitoring, logging, and APM platforms like Datadog, Splunk, New Relic, and Sumo Logic) and cloud storage integrations (connections to cloud storage for the Grepr data lake).
-
-### What is a source in a Grepr pipeline?
-
-A source in a Grepr pipeline is an operator that ingests data from an external system or agent. Sources use integrations to connect to observability platforms or collectors like FluentD or OpenTelemetry to pull data into Grepr for processing.
-
-### What is a sink in a Grepr pipeline?
-
-A sink in a Grepr pipeline is an operator that outputs processed data to an external system. Sinks use integrations to send Grepr-processed logs to observability platforms, data lakes, or other storage systems based on your pipeline configuration.
-
-### Can I use multiple integrations in a single pipeline?
-
-Yes, you can configure pipelines with multiple sources to ingest data from different platforms and multiple sinks to send processed data to different destinations. This flexibility allows you to build complex multi-source, multi-destination data processing workflows.
-
-### Which observability platforms does Grepr support?
-
-Grepr supports integrations with Datadog, Splunk, New Relic, Sumo Logic, Grafana Cloud, and Google Cloud Platform (GCP). Each integration enables different source and sink capabilities depending on the platform's features and capabilities.
-
-### How do I configure a Grepr integration?
-
-To configure an integration, you need to provide connection details specific to your external system, such as API keys, tokens, endpoints, or credentials. The specific steps vary by integration type. Detailed instructions for each integration are available in the platform-specific documentation pages.
-
-### What is the Grepr data lake integration?
-
-The Grepr data lake uses Amazon S3 to store raw log data. You can configure either a Grepr-hosted integration (using a Grepr-managed S3 bucket) where you only provide a name, or an integration with your own AWS account (requiring you to configure and manage the S3 bucket yourself for more control).
-
-### What happens to logs older than 48 hours from external sources?
-
-Grepr might drop incoming data from external integration sources with timestamps older than 48 hours. This limitation helps optimize storage and processing while allowing you to retain raw logs in the data lake for longer-term analysis.
-
-### What happens when a log event is larger than 900KB?
-
-If a log event exceeds 900KB, Grepr might split it into smaller events, which can cause them to lose their original structured format. Each split event includes a common 'grepr.splitOriginId' attribute that you can use to reconstruct the original message from its component parts.

package/build/dist/docs-index/dbdd77a6-9975-40b6-9696-e9c6e951ef33.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/dbdd77a6-9975-40b6-9696-e9c6e951ef33.txt

@@ -1,43 +0,0 @@
-# AnalyticsFunction
-
-**Type**: `object`
-
-## Properties
-
-- name: aggregate (optional)
-  type: boolean
-
-- name: category (optional)
-  type: string
-  description: Function family used to group completions.
-
-- name: completions (optional)
-  type: array of `AnalyticsCompletion`
-  description: User-facing completion templates for this function.
-
-- name: examples (optional)
-  type: array of `AnalyticsExample`
-  description: Example calls demonstrating the function.
-
-- name: help (required)
-  type: string
-  description: Short user-facing explanation shown with completions.
-
-- name: keywordSyntax (optional)
-  type: boolean
-  description: True when the call is written with SQL keywords rather than a comma-separated argument list, e.g. CAST(value AS type) or EXTRACT(field FROM timestamp). Show the examples rather than a signature synthesized from parameters.
-
-- name: maxArgs (optional)
-  type: integer
-  description: Null for variadic functions.
-
-- name: minArgs (optional)
-  type: integer
-  description: Null for variadic functions.
-
-- name: name (required)
-  type: string
-
-- name: parameters (optional)
-  type: array of `AnalyticsParameter`
-  description: The function's arguments in call order, for rendering a signature. Required arguments precede optional ones.

package/build/dist/docs-index/dcb2187f-dad8-4f53-8d99-be24b3cea9de.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/dcb2187f-dad8-4f53-8d99-be24b3cea9de.txt

@@ -1,18 +0,0 @@
-# MetricNameFilter
-
-Glob-pattern filter on metric names.
-
-**Type**: `object`
-
-## Properties
-
-- name: empty (optional)
-  type: boolean
-
-- name: excludes (optional)
-  type: array of string
-  description: Glob patterns to exclude. Precedence over includes.
-
-- name: includes (optional)
-  type: array of string
-  description: Glob patterns to include. Empty list matches all.

package/build/dist/docs-index/dcd59219-ea12-49c0-a03c-391042c7e762.json

@@ -1 +0,0 @@
-{"docType":"api"}

package/build/dist/docs-index/dcd59219-ea12-49c0-a03c-391042c7e762.txt

@@ -1,36 +0,0 @@
-# Runs a template script and returns the result.
-
-**POST** `/v1/templates/test`
-
-**Operation ID**: `testTemplate`
-**Summary**: Runs a template script and returns the result.
-Runs a template script and returns the result. The result should be deserializable to a GreprJobGraph if the 'testDeserialization' parameter is true in the payload.
-
-## Tags
-- Templates
-## Request Body
-
-Template and input values for the template.
-
-**Content-Type**: `application/json`
-
-**Schema**: `TemplateAndInputs`
-
-## Responses
-
-### 200
-
-Job graph generated successfully
-
-- **Content-Type**: `application/json` / `GreprJobGraph`
-### 400
-
-Invalid input
-
-### 401
-
-Unauthorized
-
-### 429
-
-Code generation limit exceeded for bad code. This can happen if the template runs too long or uses too many resources. The organization will be throttled for executing too many bad code generations.

package/build/dist/docs-index/dd231afb-18e0-4d46-8425-d100f66cd5f6.json

@@ -1 +0,0 @@
-{"docType":"api"}

package/build/dist/docs-index/dd231afb-18e0-4d46-8425-d100f66cd5f6.txt

@@ -1,32 +0,0 @@
-# Create a Grepr pipe integration
-
-**POST** `/v1/integrations/grepr-pipe`
-
-**Operation ID**: `createGreprPipeIntegration`
-**Summary**: Create a Grepr pipe integration
-Creates a pipe that pipelines write log events into with a pipe sink and read them from with a pipe source.
-
-## Tags
-- Grepr Pipe Integration
-## Request Body
-
-**Content-Type**: `application/json`
-
-**Schema**: `WriteGreprPipe`
-
-## Responses
-
-### 200
-
-Integration created successfully
-
-- **Content-Type**: `application/json` / `ReadGreprPipe`
-### 401
-
-Unauthorized
-
-### 409
-
-Integration already exists.
-
-- **Content-Type**: `application/json` / `ReadGreprPipe`

package/build/dist/docs-index/dd457171-e855-4bcc-acb0-2d51d32deaa8.json

@@ -1 +0,0 @@
-{"docType":"schema"}