@grepr/cli 1.8.5-ca825ac → 1.8.7-20abddf

package/build/dist/docs-index/22fa3121-eddb-4234-8f93-55880689b163.txt

@@ -0,0 +1,138 @@
+Understand the data processing models, data models, and abstractions used by Grepr jobs, the types of Grepr jobs, processing modes for jobs, and the jobs lifecycle.
+
+# The Grepr processing and data models
+
+At its core, Grepr is powered by a robust data processing engine that executes *jobs*. These jobs process individual units of data, called *events*.
+
+## Log event model
+
+Grepr uses a data model that makes it easy for you to conceptualize. Log events in Grepr support both structured and unstructured data. The unstructured part is stored in a top-level field called `message` while all structured data is under `attributes`. Additional labels or tags that can be used to identify the source of data and do quick filtering is under `tags`.
+
+Grepr pipeline operators operate on this data model. When using the UI, most of the details of the model are abstracted away. When using the API, you need to understand the model well to build a well-functioning pipeline.
+
+Each log event has the following properties:
+
+* **`id`**: A globally unique id that identifies the log event.
+* **`receivedTimestamp`**: Timestamp when Grepr received the event.
+* **`eventTimestamp`**: Timestamp when the event occurred, usually parsed from the event itself.
+* **`tags`**: A set of key-value pairs that can be used to filter and route events. Some of the commonly used tags are `host`, `service`, `environment`, etc. This is a map from a string key to a set of string values.
+* **`attributes`**: Structured data and fields that are associated with the event. These could be sent with the event from the source or extracted by Grepr from the message.
+* **`message`**: The log message itself.
+* **`severity`**: The severity of the log message. This is an integer, following the OpenTelemetry convention of 1-4 for `TRACE`, 5-8 for `DEBUG`, 9-12 for `INFO`, 13-16 for `WARN`, 17-20 for `ERROR`, and 21-24 for `FATAL`. Severity is usually sent along with the message, but may be parsed from the event too.
+
+An example log event in JSON would look like:
+
+```json
+{
+  "id": "0H19GZK97FTKS",
+  "eventTimestamp": "2024-08-21T04:21:14.062Z",
+  "receivedTimestamp": "2024-08-21T04:21:14.188Z",
+  "severity": 9,
+  "message": "State backend is set to heap memory",
+  "tags": {
+    "app": "greprdev-0gvrs39hhft9q",
+    "kube_ownerref_kind": "deployment",
+    "source": "grepr-query",
+    "organizationId": "greprdev",
+    "service": "grepr-query",
+    "pod_phase": "running",
+    "host": "ip-10-12-4-129.ec2.internal",
+    "image_tag": "0.1.0-3421150",
+    "container_id": "b743c4b78b8ec25c6c73ea03de443ebe19acf760d293dc4145bd31170768a216"
+  },
+  "attributes": {
+    "process": {
+      "thread": {
+        "name": "thread-0"
+      }
+    },
+    "ecs": {
+      "version": "1.2.0"
+    },
+    "timestamp": 1724214074114,
+    "status": "info"
+  }
+}
+```
+
+## Grepr job model \[#grepr-job-model]
+
+All processing within Grepr is a *job*. Each job has a name, a desired state, a current state, and a job graph that describes the data sources, sinks, and the transformations on the data between the sources and sinks. These jobs can:
+
+* Ingest data continuously from various kinds of agents.
+* Execute queries on the Grepr data lake and return the result to the user.
+* Backfill data from the Grepr data lake back to observability vendors.
+
+### The job graph \[#grepr-job-graph]
+
+Each job is a directed acyclic graph (DAG), consisting of vertices and edges. Vertices can be sources, sinks, or transforms. We often refer to vertices in the graph as operators as well. The Grepr UI abstracts away much of the complexity of job management into an app-like experience, so learning the details of these operators and how they work are not necessary.
+
+Each operator may have 0 or more inputs and outputs. Sinks have no outputs while sources have no inputs. All transforms have at least 1 input and 1 output. Many operators will require an integration to work, such as the Iceberg sink or Datadog source.
+
+### Job execution \[#grepr-job-execution]
+
+Jobs have two properties that describe how they are executed: `Execution` and `Processing`.
+
+#### Execution
+
+Jobs have two execution modes: `SYNCHRONOUS` and `ASYNCHRONOUS`. Synchronous jobs are executed immediately and their result is streamed back to the caller. Asynchronous jobs are submitted and run in the background. The results of an asynchronous job end up in a preconfigured sink.
+
+#### Processing
+
+Jobs have two processing modes: `STREAMING` and `BATCH`. Streaming jobs execute continuously on the data as it arrives. They will continue running until they are stopped. Batch jobs have a bounded amount of data that arrives from the sources, which they will read and process, and then they will complete.
+
+When we mention "pipeline" in the docs, we mean `ASYNCHRONOUS` `STREAMING` jobs that will continuously receive data from a source, process it, and then deliver it to one or more sinks. Queries on the other hand are usually `SYNCHRONOUS` `BATCH` jobs that will return a result to the caller, although they can be `ASYNCHRONOUS` `BATCH` jobs too, such as backfill jobs.
+
+### Job lifecycle
+
+Jobs also have a lifecycle. The lifecycle of batch and streaming jobs are different. Batch jobs are submitted, processed, and then completed. Streaming jobs, on the other hand, have a long lifetime and will be running until they are stopped. However, they might need to be reconfigured, upgraded, stopped, and restarted for various reasons over their lifetimes, so their lifecycles are more complex.
+
+A user will specify the desired state for the job, and Grepr will try to make the current state of the job match the desired state. Grepr will automatically start, stop, reconfigure, and restart jobs as needed.
+
+### Autoscaling
+
+Streaming jobs automatically scale up and down to handle an increase or decrease in load and align execution cost with need. Batch jobs automatically execute at an optimal level of parallelism to reduce latency without sacrificing efficiency.
+
+During scale-up or scale-down periods for streaming jobs, there may be a few seconds of data processing delay, during which the pipeline is switching from the old deployment to the new deployment. At the same time, there may be an increase in data lag when there's an increase in load until the pipeline scales up to handle the increase. We aim to keep this lag to less than 5 minutes of delay in the worst case.
+
+## Frequently Asked Questions
+
+### What is a log event in Grepr?
+
+A log event in Grepr is a data unit containing unstructured message data and structured attributes. Each log event has a unique id, receivedTimestamp (when Grepr received it), eventTimestamp (when the event occurred), tags for filtering and routing, attributes for structured data fields, the message itself, and a severity level following OpenTelemetry conventions.
+
+### How are log events structured in Grepr?
+
+Log events support both structured and unstructured data. The unstructured message is stored in a top-level field called 'message', while all structured data is under 'attributes'. Labels or tags that identify the data source and enable quick filtering are stored under 'tags'. This model makes it easy to process logs whether they come in structured or unstructured form.
+
+### What are the different components of a log event?
+
+A log event includes: id (unique identifier), receivedTimestamp (when Grepr received it), eventTimestamp (when it occurred), tags (key-value pairs for filtering), attributes (structured data fields), message (the log text), and severity (following OpenTelemetry 1-24 scale). Each component serves a specific purpose in processing and analyzing the log.
+
+### What is a Grepr job?
+
+A Grepr job is a unit of processing work with a name, desired state, current state, and a job graph describing data sources, sinks, and transformations. Jobs can ingest data continuously from agents, execute queries on the data lake, or backfill data from the data lake to observability vendors. All processing within Grepr is implemented as jobs.
+
+### What is a job graph?
+
+A job graph is a directed acyclic graph (DAG) consisting of vertices and edges. Vertices can be sources (no inputs), sinks (no outputs), or transforms (at least 1 input and 1 output). The job graph describes the data flow from sources through transformations to sinks. The Grepr UI abstracts away the complexity of job graphs into an app-like experience.
+
+### What is the difference between streaming and batch processing?
+
+Streaming jobs execute continuously on data as it arrives and run until stopped, making them ideal for ongoing pipeline operations. Batch jobs have bounded input data from sources, process it, and then complete. Pipelines are typically asynchronous streaming jobs, while queries are usually synchronous batch jobs that return results to the caller.
+
+### What are execution modes in Grepr?
+
+Jobs have two execution modes: Synchronous jobs execute immediately and stream results back to the caller, while asynchronous jobs are submitted and run in the background with results delivered to a preconfigured sink. The choice of execution mode depends on whether you need immediate results or background processing.
+
+### How does job autoscaling work?
+
+Streaming jobs automatically scale up and down to handle increases or decreases in load and align execution cost with need. Batch jobs automatically execute at optimal parallelism levels to reduce latency without sacrificing efficiency. During scaling transitions, there may be a few seconds of processing delay, with a worst-case data lag target of less than 5 minutes.
+
+### What is the lifecycle of a Grepr job?
+
+Jobs have a lifecycle where you specify the desired state and Grepr works to match the current state to it. Batch jobs are submitted, processed, and complete. Streaming jobs have longer lifespans and may be reconfigured, upgraded, stopped, and restarted. Grepr automatically manages job state transitions and handles the complexity of job lifecycle management.
+
+### How does severity work in the Grepr data model?
+
+Severity is an integer following OpenTelemetry conventions: 1-4 for TRACE, 5-8 for DEBUG, 9-12 for INFO, 13-16 for WARN, 17-20 for ERROR, and 21-24 for FATAL. Severity is usually sent with the message from the source but may also be parsed from the event itself during processing.

package/build/dist/docs-index/22fdf795-f2fd-406e-91da-0fe4d03a15dd.json

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

package/build/dist/docs-index/22fdf795-f2fd-406e-91da-0fe4d03a15dd.txt

@@ -0,0 +1,29 @@
+# Get a Datadog MCP integration
+
+**GET** `/v1/integrations/datadog-mcp/{id}`
+
+**Operation ID**: `get_6`
+**Summary**: Get a Datadog MCP integration
+Get a Datadog MCP integration by ID.
+
+## Tags
+- Datadog MCP Integration
+## Parameters
+
+- **id** (required) - path
+  - Type: string
+
+## Responses
+
+### 200
+
+Integration retrieved successfully
+
+- **Content-Type**: `application/json` / `ReadDatadogMcp`
+### 401
+
+Unauthorized
+
+### 404
+
+Integration not found.

package/build/dist/docs-index/232b5046-fea7-4df4-85e3-64315fae57f1.json

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

package/build/dist/docs-index/232b5046-fea7-4df4-85e3-64315fae57f1.txt

@@ -0,0 +1,24 @@
+# IntegrationExceptionConfig
+
+**Type**: `object`
+
+## Properties
+
+- name: autoSync (optional)
+  type: boolean
+  description: When enabled, the exceptions list will be updated automatically based on the integration's exceptions.
+
+- name: autosyncPassthroughRateThreshold (optional)
+  type: number
+  description: Maximum impact percentage threshold for autosync (0.0 to 100.0). When set, only exceptions with impact percentage <= threshold are auto-included.
+
+- name: datasetId (optional)
+  type: string
+  description: Dataset against which the auto-sync impact threshold is evaluated. Required for threshold filtering to apply; when null, no exceptions bypass via auto-sync.
+
+- name: ids (optional)
+  type: array of string
+
+- name: integrationId (required)
+  type: string
+  description: The ID of the integration associated with this exception configuration.

package/build/dist/docs-index/23339220-bc06-4b16-8754-5cd7ffefca53.json

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

package/build/dist/docs-index/23339220-bc06-4b16-8754-5cd7ffefca53.txt

@@ -0,0 +1,44 @@
+# ReadOtlp
+
+**Type**: `object`
+
+## Properties
+
+- name: createdAt (required)
+  type: string
+  description: Timestamp when the integration was created.
+
+- name: id (required)
+  type: string
+  description: The integration id
+
+- name: jobIds (required)
+  type: array of string
+  description: List of job IDs associated with the integration.
+
+- name: name (required)
+  type: string
+  description: Name of the integration.
+
+- name: organizationId (required)
+  type: string
+  description: Organization ID of the integration.
+
+- name: payload (required)
+  type: `Otlp`
+
+- name: teamIds (optional)
+  type: array of string
+  description: The team IDs that this integration is associated with.
+
+- name: type (required)
+  type: enum: `otlp`
+  description: The type of the integration. This is used to determine the payload type.
+
+- name: updatedAt (required)
+  type: string
+  description: Timestamp when the integration was last updated.
+
+- name: version (required)
+  type: integer
+  description: Version of the integration. Should be increased by one for every new update in order for the write to succeed. Otherwise, a '409 Conflict' will be returned.

package/build/dist/docs-index/2344a4f2-0d4a-4e06-9b9d-31fbfc8c04d2.json

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

package/build/dist/docs-index/2344a4f2-0d4a-4e06-9b9d-31fbfc8c04d2.txt

@@ -0,0 +1,12 @@
+# CompositeAttributesMergeStrategy
+
+**Type**: `object`
+
+## Properties
+
+- name: strategies (required)
+  type: array of `AttributesMergeStrategy`
+
+- name: type (required)
+  type: enum: `composite`
+  description: CompositeAttributesMergeStrategy: Applies multiple merge strategies to produce multiple output attributes with suffixed keys.

package/build/dist/docs-index/23ca9fa9-0a6d-4ccc-b3d1-879bbb43e883.json

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

package/build/dist/docs-index/23ca9fa9-0a6d-4ccc-b3d1-879bbb43e883.txt

@@ -0,0 +1,25 @@
+# Get AWS console setup information for a S3 Data Warehouse integration
+
+**GET** `/v1/integrations/s3-data-warehouse/console-setup-info`
+
+**Operation ID**: `getConsoleSetupInfo`
+**Summary**: Get AWS console setup information for a S3 Data Warehouse integration
+Gets AWS console setup information for an external S3 Data Warehouse integration
+
+## Tags
+- External S3 Data Warehouse Integration
+## Parameters
+
+- **bucketName** (optional) - query
+  - Type: string
+
+## Responses
+
+### 200
+
+AWS console setup information retrieved successfully
+
+- **Content-Type**: `application/json` / `ConsoleSetupInfo`
+### 401
+
+Unauthorized

package/build/dist/docs-index/2479b6d4-af69-4f5b-9b32-0c6c50cd6eec.json

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

package/build/dist/docs-index/2479b6d4-af69-4f5b-9b32-0c6c50cd6eec.txt

@@ -0,0 +1,35 @@
+# Update an S3 Vector Index integration
+
+**PUT** `/v1/integrations/s3-vector-index/{id}`
+
+**Operation ID**: `update_13`
+**Summary**: Update an S3 Vector Index integration
+Updates an existing S3 Vector Index integration. Note: dimensions and distanceMetric are immutable after creation.
+
+## Tags
+- S3 Vector Index Integration
+## Parameters
+
+- **id** (required) - path
+  - Type: string
+
+## Request Body
+
+**Content-Type**: `application/json`
+
+**Schema**: `WriteS3VectorIndex`
+
+## Responses
+
+### 200
+
+S3 Vector Index integration updated successfully
+
+- **Content-Type**: `application/json` / `ReadS3VectorIndex`
+### 401
+
+Unauthorized
+
+### 404
+
+S3 Vector Index integration not found

package/build/dist/docs-index/248691f2-64f7-4de0-83c7-150976333257.json

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

package/build/dist/docs-index/248691f2-64f7-4de0-83c7-150976333257.txt

@@ -0,0 +1,145 @@
+Learn how to ensure specific messages are forwarded unchanged to observability platforms by configuring them as exceptions to the reducer step.
+
+# Bypass aggregation of important messages with exceptions
+
+This page describes how to use *exceptions* to specify messages that should bypass the reducer and get forwarded directly to your observability platform without summarization. Examples of why you might want to forward raw, unsummarized messages include:
+
+* You need to track activity across messages, requiring samples of all messages associated with specific identifiers.
+* You want to provide unsummarized messages for a period before and after an anomalous event occurs or in response to an external event.
+* Dashboards, alerts, or monitors in your observability platform depend on receiving full, unsummarized messages to function correctly.
+
+This page explains how to configure the different exception types in the Grepr UI. You can also use the REST API to configure exceptions. With the API, you configure exceptions as part of the [LogReducer transform](/apis/api-spec#schema/LogReducer), and then include them as vertices in the job graph defining a log pipeline.
+
+## Configure exceptions in the Grepr UI
+
+You configure exceptions on the overview page when you create or edit a pipeline. To add an exception, in the left-hand navigation menu, click **Exceptions** to open the exceptions list, click **Add**, and then select the exception type to configure. The following sections describe the different exception types and their configuration options.
+
+To write queries for exception configurations, you use the same syntaxes you use for queries in the filtering or transformation steps of your pipeline. To learn more about supported query syntaxes, see [Query log data in the Grepr data lake](/queries).
+
+To edit an existing exception, click the exception's row in the list to open the **Edit Exception** dialog. To remove an exception, click the delete icon in the exception row.
+
+## Prevent aggregation of messages used in your observability platform \[#vendor-exceptions]
+
+Some Grepr integrations, such as Datadog and New Relic, support parsing queries used by monitors, dashboards, or alerts in your observability platform. To ensure the correct functioning of your observability platform assets, Grepr can use the parsing results to configure queries that should automatically bypass reduction. You can choose to apply exceptions for any or all of the parsed queries. To configure parsed queries to use as exceptions, select **Do not aggregate logs used in existing observability alerts** to display the **Imported Queries** table. Use the links in the **Name** column to go to the alert's source in your observability vendor's UI.
+
+The **Imported Queries** table also includes the **Passthrough %** column, which is an estimate of the percentage of events over a configurable time window that would bypass aggregation. You configure passthrough estimation as part of the integration configuration. See [Identify log events that should bypass aggregation](/integrations#passthrough-estimation).
+
+You can also enable **Auto-sync exceptions** to automatically add and remove exceptions as you add and remove alerts or dashboards in your observability vendor. When you enable auto-sync and no queries are selected in the **Imported Queries** table, all queries are selected automatically as exceptions. If at least one query is already selected, that selection is retained, and you must manually select any other queries to include. In both cases, Grepr automatically adds exceptions for any new queries parsed after enabling auto-sync.
+
+When you enable auto-sync, changes such as new alerts or dashboards in your observability platform might cause an unexpectedly large increase in the log events that bypass reduction. To mitigate this risk, you can set a threshold for auto-sync exceptions. The threshold setting prevents auto-sync from adding a new exception when the estimated percentage of log events excluded from reduction for that exception exceeds the threshold. To set this threshold, enter the value in the **Max %** text box.
+
+> If you rewrite alert or dashboard queries to use summarized messages, add `processor:grepr` to the new queries so that they do not match logs that did not go through Grepr. This tag is automatically added to all log messages that Grepr sends to external vendors and never matches any raw messages. It tells Grepr that a query for an alert or dashboard has already been rewritten.
+
+## Always forward messages matching a query \[#pattern-exceptions]
+
+To ensure that certain messages always bypass the reducer and are forwarded without aggregation, for example, when processing in your observability platform has a dependency on those messages, you can define a query to identify those messages. The reducer evaluates every incoming log message and forwards every matching message unmodified. This exception type doesn't trigger a backfill or affect the aggregation of other messages.
+
+## Forward samples of full logs based on trace identifiers \[#trace-sampler-exceptions]
+
+You can ensure you have samples of full logs for events that share a trace identifier. For this exception type, a trace refers to one or more values used to group related events, and not specifically an application performance monitoring trace. For example, a trace ID could be a request ID, a user ID, or a session ID.
+
+Based on the configured trace ID for each log message, Grepr samples a configurable percentage of trace IDs and forwards every log message that belongs to a sampled trace unmodified. Use this exception type to keep a representative sample of complete, end-to-end traces in your observability backend.
+
+Grepr uses the trace samplers in the order they are specified. After a message matches for trace sampling, it is not evaluated against any remaining trace samplers.
+
+Configure the following settings:
+
+* An optional query that scopes the sampling to messages that match the query. Only messages that match the query participate in trace sampling. Leave the query empty to apply sampling to all messages that pass through the reducer.
+* Attribute paths or tag keys to use as trace identifiers. To add the paths or keys, click the plus (+) icons. To enter attribute paths, use dot notation, such as `trace.id`, or a JSON array, such as `["trace", "id"]`. Use a JSON array if any segment of the path contains a literal dot. To remove a path or key, click the delete icon next to the entry.
+* A sample percentage of distinct trace IDs to sample, from 0 to 100. You can specify up to two decimal places, such as `1.50`. Grepr forwards every log message whose trace ID falls within the sampled percentage. The default is `1.00`.
+
+> You must specify at least one **Trace ID Attribute Path** or **Trace ID Tag Key**. The form does not allow you to save the exception when both lists are empty.
+
+## Pause aggregation and backfill logs for events matching a query \[#dynamic-exceptions]
+
+You can create an exception that automatically pauses aggregation of specific messages and optionally forwards full messages for a configured period when incoming events match a query. Use this exception type to forward full logs when specific events occur, such as production incidents or other anomalous events. For example, you can configure the query `status:error` to ensure you have full logs if an event arrives from a host with an error status.
+
+In addition to the query that triggers this exception, you also configure:
+
+* An optional list of attribute paths or tag keys that scope the backfill and the paused aggregation to the values found in the triggering message. For example, if you add `service`, only messages with the same `service` value as the triggering message are backfilled and excluded from aggregation.
+* The duration of historical data to backfill from the data lake when the exception is triggered. You can also choose to skip the backfill step and only pause aggregation.
+* The duration to pause aggregation of matching messages after the exception is triggered. You can also choose to continue aggregating matching messages and only run the backfill.
+
+## Pause aggregation and backfill logs in response to an external event \[#callback-exceptions]
+
+In addition to triggering exceptions based on incoming log messages, you can configure exceptions to be triggered by external events. This exception type is activated when an external system, such as an observability monitor or alert, calls the [External Triggers endpoint](/apis/api-spec#tag/External-Triggers).
+
+Configure the following settings:
+
+* An optional list of attribute paths or tag keys that scope the backfill and the paused aggregation to the values passed in the call to the external triggers endpoint. To add an attribute, type `@` and then select from the suggested values.
+* The duration of historical data to backfill from the data lake when the exception is triggered. You can also choose to skip the backfill step and only pause aggregation.
+* The duration to pause aggregation of matching messages after the exception is triggered. You can also choose to continue aggregating matching messages and only run the backfill.
+
+The attributes and keys you define are included as key-value pairs in the `variables` object in the body of the request to the external triggers endpoint. After you save the exception, click the terminal icon in the exception's **Actions** column to display a sample `curl` command to call the external triggers endpoint for that exception. After updating the placeholders for values in the `variables` object, you can use this command for testing and as a reference when configuring calls to the trigger from an external system.
+
+## Rewrite queries \[#rewrite-queries]
+
+When you first deploy Grepr's log reduction, you typically add exceptions for all existing alerts and dashboards to minimize disruptions to existing workflows. However, over time, you might find that some of these alerts and dashboards use queries that count the occurrence of a pattern that appears with high frequency. For example, you might have a dashboard that uses a count of HTTP requests with the status code 200. Because 200 is the standard success status code, most HTTP log messages include it. Adding an exception for this dashboard results in forwarding a large number of events that would normally be aggregated.
+
+To address this, you can rewrite the query to use the [grepr.repeatCount](/transforms/reducer#summary-metadata) attribute. This attribute appears in both summary and sample messages, enabling the derivation of metrics. See your vendor's documentation for specifics on creating a metric from a log attribute.
+
+## Frequently Asked Questions
+
+### What is an exception in a Grepr pipeline?
+
+An exception is a rule that you configure on a pipeline to identify log messages that should bypass aggregation by the reducer. Messages that match an exception are forwarded to your sinks unmodified. Some exception types also trigger a backfill from the data lake and temporarily pause aggregation for related messages.
+
+### What types of exceptions can I configure?
+
+You can configure five types of exceptions: a pattern exception that always forwards messages matching a query, a query trigger exception that backfills and pauses aggregation when a query matches, an integration exception that excludes queries used by alerts in your observability tool, a trace sampler exception that forwards a representative sample of full traces, and an external trigger exception that backfills and pauses aggregation in response to a call to the Grepr External Triggers API.
+
+### How do I add an exception to a pipeline?
+
+Open the pipeline in the Grepr UI, click Exceptions in the left-hand navigation menu, and click the add button. In the Add Exception dialog, select the type of exception, complete the configuration fields, and click Add.
+
+### What query languages can I use in an exception?
+
+You write exception queries using the same query syntaxes available for the filtering and transformation steps in your pipeline. Queries are used on pattern exceptions, query trigger exceptions, and as the optional scoping query on trace sampler exceptions.
+
+### What are scoping keys on an exception?
+
+Scoping keys are the attribute paths and tag keys you configure on a query trigger exception or external trigger exception. They limit the backfill and the paused aggregation to messages whose values for those keys match the values from the triggering event.
+
+### What does Auto-sync exceptions do on an integration exception?
+
+When Auto-sync exceptions is enabled, Grepr automatically adds new queries discovered in the integration as exceptions, instead of using only the queries you initially selected. You can clear specific queries to exclude them from auto-sync, and you can use the Max % field to prevent any single exception from excluding more than a specified percentage of incoming logs.
+
+### How do I prevent an auto-synced exception from forwarding too many logs?
+
+On an integration exception with Auto-sync exceptions enabled, set the Max % field to the maximum percentage of incoming logs that any single exception is allowed to exclude from reduction. If the estimated percentage of logs excluded by an auto-synced exception exceeds this threshold, Grepr does not activate the exception.
+
+### How does trace sampling work in Grepr?
+
+Based on the configured trace ID for each log message, Grepr samples a configurable percentage of trace IDs and forwards every log message that belongs to a sampled trace unmodified. The trace ID does not have to be an APM trace; anything that groups logs together, such as a request ID, user ID, or session ID, can be used.
+
+### What's the difference between Trace ID Attribute Paths and Trace ID Tag Keys on a trace sampler exception?
+
+Trace ID Attribute Paths are paths inside the structured attributes of a log message that contain the trace ID, expressed in dot notation or as a JSON array. Trace ID Tag Keys are top-level tag keys that contain the trace ID. You must specify at least one path or one tag key.
+
+### How does the Sample Percentage on a trace sampler exception work?
+
+The Sample Percentage is the percentage of distinct trace IDs that Grepr samples. Grepr forwards every log message that belongs to a sampled trace, so a sample percentage of 1% forwards complete logs for approximately 1% of the traces seen by the reducer.
+
+### In what order does Grepr apply trace samplers?
+
+Grepr applies trace samplers in the order they are listed. After a message matches a trace sampler, Grepr does not evaluate it against any of the remaining trace samplers.
+
+### Can Grepr import exceptions from my observability platform's monitors and dashboards?
+
+Yes. Some Grepr integrations, such as the Datadog and New Relic integrations, parse the queries used by your monitors, dashboards, and alerts and suggest them as exceptions you can apply. Each suggested exception includes a link back to the source of the alert in your observability vendor's UI.
+
+### How does an external trigger exception get activated?
+
+An external trigger exception is activated by a call to the Grepr External Triggers API. After you save the exception, the row for the exception in the Exceptions list provides a sample curl command that you can use to call the API. Scoping keys configured on the exception take their values from the API call.
+
+### How does the query trigger exception work?
+
+A query trigger exception activates when an incoming log message matches the configured query. When it activates, Grepr backfills matching messages from the data lake for a configured duration and pauses aggregation of matching messages for a configured duration. You can also choose to skip the backfill and only pause aggregation, or to keep aggregating and only run the backfill. You can use scoping keys to limit the backfill and paused aggregation to messages that share the triggering message's values.
+
+### Why might I need to rewrite alert or dashboard queries after adding exceptions?
+
+When you first deploy log reduction, you typically add exceptions for existing alerts and dashboards to minimize disruption. Some of those alerts and dashboards are powered by counts of high-volume events, such as HTTP requests with status 200, which limits how much volume the reducer can reduce. Rewriting those queries lets the reducer aggregate the underlying messages while keeping the dashboards accurate.
+
+### Can I rewrite my dashboards to use reduced logs?
+
+Yes, you can rewrite dashboard and alert queries to use grepr.repeatCount for accurate metrics on aggregated data. Add the processor:grepr tag to queries to ensure they only match processed logs, enabling cost-effective metrics on sampled data.

package/build/dist/docs-index/248b5c6a-ed48-42fb-bc1f-a108bc5ac821.json

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

package/build/dist/docs-index/248b5c6a-ed48-42fb-bc1f-a108bc5ac821.txt

@@ -0,0 +1,44 @@
+# ReadOpenAi
+
+**Type**: `object`
+
+## Properties
+
+- name: createdAt (required)
+  type: string
+  description: Timestamp when the integration was created.
+
+- name: id (required)
+  type: string
+  description: The integration id
+
+- name: jobIds (required)
+  type: array of string
+  description: List of job IDs associated with the integration.
+
+- name: name (required)
+  type: string
+  description: Name of the integration.
+
+- name: organizationId (required)
+  type: string
+  description: Organization ID of the integration.
+
+- name: payload (required)
+  type: `OpenAi`
+
+- name: teamIds (optional)
+  type: array of string
+  description: The team IDs that this integration is associated with.
+
+- name: type (required)
+  type: enum: `openai`
+  description: The type of the integration. This is used to determine the payload type.
+
+- name: updatedAt (required)
+  type: string
+  description: Timestamp when the integration was last updated.
+
+- name: version (required)
+  type: integer
+  description: Version of the integration. Should be increased by one for every new update in order for the write to succeed. Otherwise, a '409 Conflict' will be returned.

package/build/dist/docs-index/24f334ae-daf9-4a8f-8099-6305efc5faf1.json

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

package/build/dist/docs-index/24f334ae-daf9-4a8f-8099-6305efc5faf1.txt

@@ -0,0 +1,17 @@
+# AttributeNode
+
+**Type**: `object`
+
+## Properties
+
+- name: attribute (required)
+  type: string
+  description: The attribute name
+
+- name: term (required)
+  type: string
+  description: The term to match. This is a string that is matched against the attribute.
+
+- name: type (required)
+  type: enum: `attribute-node`
+  description: A node that matches an attribute in a parsed query.

package/build/dist/docs-index/25e1e098-8c55-4227-a133-6cf4eef268b1.json

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

package/build/dist/docs-index/25e1e098-8c55-4227-a133-6cf4eef268b1.txt

@@ -0,0 +1,44 @@
+# ReadDatadog
+
+**Type**: `object`
+
+## Properties
+
+- name: createdAt (required)
+  type: string
+  description: Timestamp when the integration was created.
+
+- name: id (required)
+  type: string
+  description: The integration id
+
+- name: jobIds (required)
+  type: array of string
+  description: List of job IDs associated with the integration.
+
+- name: name (required)
+  type: string
+  description: Name of the integration.
+
+- name: organizationId (required)
+  type: string
+  description: Organization ID of the integration.
+
+- name: payload (required)
+  type: `Datadog`
+
+- name: teamIds (optional)
+  type: array of string
+  description: The team IDs that this integration is associated with.
+
+- name: type (required)
+  type: enum: `datadog`
+  description: The type of the integration. This is used to determine the payload type.
+
+- name: updatedAt (required)
+  type: string
+  description: Timestamp when the integration was last updated.
+
+- name: version (required)
+  type: integer
+  description: Version of the integration. Should be increased by one for every new update in order for the write to succeed. Otherwise, a '409 Conflict' will be returned.

package/build/dist/docs-index/267e1982-5dba-4401-85bb-93afe1df42ad.json

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

package/build/dist/docs-index/267e1982-5dba-4401-85bb-93afe1df42ad.txt

@@ -0,0 +1,26 @@
+# MetricAggregation
+
+One aggregation declaration inside an anomaly rule.
+
+**Type**: `object`
+
+## Properties
+
+- name: aggregations (optional)
+  type: array of `AggregationDecl`
+  description: Aggregations to emit. Null = dimension view.
+
+- name: filters (optional)
+  type: `FilterPrimitive`
+
+- name: groupBy (required)
+  type: array of string
+  description: Group-by tokens: 'object', 'cohort', 'series', or a level-prefixed attribute path. Empty list = global aggregation.
+
+- name: source (optional)
+  type: string
+  description: Exact metric name or nested-aggregation alias. Mutually exclusive with filters.metricName. Null for dimension views (when filters is also unset).
+
+- name: window (optional)
+  type: string
+  description: Aggregation window. Defaults to timeGranularity.duration.

package/build/dist/docs-index/26df42b3-fe16-40ef-88c5-3570e871f3d8.json

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