@grepr/cli 1.1.2 → 1.2.0

package/build/dist/docs-index/d62494c9-804e-4de5-8372-705fa0ad51ec.txt

@@ -0,0 +1,155 @@
+---
+description: Learn how to create a Sumo Logic integration and use it to add sources that ingest logs to a Grepr pipeline for processing and sinks that send the processed logs to Sumo Logic.
+---
+
+import { Callout } from 'nextra/components'
+import AddTeamAccess from '@/app/shared/add-team-access-to-resource.mdx'
+import IngestUrlConfig from '@/app/shared/configure-ingest-url.mdx'
+import IntegrationsInterchangeability from '@/app/shared/integrations-interchangeability.mdx'
+import { HiddenFAQ } from '@/components/HiddenFAQ'
+
+# Configure connections to Sumo Logic with Grepr integrations
+
+The Grepr platform includes two integrations for connecting to Sumo Logic. This page documents the Sumo Logic integration, but the integration to use depends on the source type that you are sending logs to:
+
+- If you use the OTLP/HTTP source in Sumo Logic, you must use the [Grepr OpenTelemetry integration](/integrations/open-telemetry#otel-sumo-logic) to connect Grepr and Sumo Logic.
+- If you use the HTTP source, you must use the Sumo Logic integration.
+
+To send logs to a Grepr pipeline before forwarding them to Sumo Logic, update your collector configuration to send the logs to a Grepr endpoint URL instead of the endpoint for a Sumo Logic source. To learn how to create a Sumo Logic integration in the Grepr UI and configure collectors to send logs to Grepr, see [Use a Sumo Logic integration in a Grepr pipeline](#use-sumo-logic-integration).
+
+You can also use the Grepr REST API to create and use a Sumo Logic integration. See the [Sumo Logic Integration specification](/apis/api-spec#tag/Sumo-Logic-Integration).
+
+<Callout>
+  <IntegrationsInterchangeability />
+</Callout>
+
+## Requirements
+
+- To create a Sumo Logic integration, you must have the endpoint URL from a configured `HTTP Logs and Metrics Source`. See [Configure an HTTP Logs and Metrics Source](https://www.sumologic.com/help/docs/send-data/hosted-collectors/http-source/logs-metrics/#configure-an-httplogs-and-metrics-source).
+- The only log format supported by the Sumo Logic integration is JSON. To send logs to a Grepr source, you must set `log_format:json` in your collector configuration.
+
+## Use a Sumo Logic integration in a Grepr pipeline [#use-sumo-logic-integration]
+
+Use the following steps to create a Sumo Logic integration in the Grepr UI and use it in a pipeline to source and sink logs.
+
+### Step 1: Create a Sumo Logic integration
+
+To create a Sumo Logic integration in the Grepr UI:
+
+1. Go to the **Integrations** page in the Grepr UI and click **Add new** next to **Observability Vendors**.
+1. In the **Add Observability Vendor** dialog:
+   - In the **Type** menu, select **Sumo Logic**.
+   - In the **Name** field, enter a name for the integration. To facilitate working with logs in Sumo Logic, Grepr recommends naming the integration based on the collector that will send logs to Grepr.
+   - In the **HTTP collector URL** field, enter the endpoint URL from your Sumo Logic `HTTP Logs and Metrics Source`.
+1. Click **Create**.
+
+   #### (Optional) Grant team access to the integration
+
+   <AddTeamAccess resource_type='integration' />
+
+### Step 2: Add a source to your pipeline
+
+To add a source to your pipeline that uses the Sumo Logic integration:
+
+1. In the Grepr UI, go to the overview page for an existing pipeline or create a new pipeline from the homepage.
+1. In the left-hand navigation menu on the pipeline overview page, click **Sources**.
+1. In the **Add source** dialog, select the Sumo Logic integration in the **Source** menu.
+1. (Optional) In the **Name** field, to override the Grepr-generated name, enter a new name for the source.
+1. Click **Submit**.
+
+### Step 3: Configure log forwarding to Grepr
+
+<IngestUrlConfig image_url='/images/integrations/ingestion-url-sumo.png' url='https://<integration-id>-<org-id>.ingest.grepr.ai/receiver/v1/http/<unique-http-collector>' />
+
+Also replace `{$UNIQUE_HTTP_COLLECTOR}` with the unique identifier for your Sumo Logic `HTTP Logs and Metrics Source`.
+
+The `Sumo Logic Distribution for OpenTelemetry Collector` is supported for sending logs to Grepr. To configure the OpenTelemetry collector to send logs to Grepr, set the `endpoint` value in the `exporters.sumologic` section to the ingestion URL from your Grepr source:
+
+```yaml
+exporters:
+  sumologic/grepr:
+    endpoint: <ingestion-url>
+    log_format: json
+
+service:
+  pipelines:
+    logs:
+      exporters: [sumologic/grepr]
+```
+
+Replace:
+- `<ingestion-url>` with the ingestion URL from your Grepr Sumo Logic source.
+
+Your workflow might require sending unprocessed logs directly to Sumo Logic in addition to sending the logs to Grepr. To configure dual-shipping of logs, include an exporter configuration for both Grepr and Sumo Logic in your OpenTelemetry collector configuration:
+
+```yaml
+exporters:
+  sumologic/grepr:
+    endpoint: <ingestion-url>
+    log_format: json
+
+  # Your existing Sumo Logic exporter
+  sumologic:
+    endpoint: <sumo-http-source-url>
+    log_format: json
+
+service:
+  pipelines:
+    logs:
+      exporters: [sumologic/grepr, sumologic]
+```
+
+Replace:
+- `<ingestion-url>` with the ingestion URL from your Grepr Sumo Logic source.
+- `<sumo-http-source-url>` with the endpoint URL from your Sumo Logic HTTP source.
+
+To learn more about configuration settings for the Sumo Logic OpenTelemetry Collector, see the [Sumo Logic Distribution for OpenTelemetry Collector documentation](https://github.com/SumoLogic/sumologic-otel-collector#readme).
+
+## Limitations
+
+The integration doesn't support Sumo Logic [Extended HTTP Metadata Collection](https://www.sumologic.com/help/docs/manage/fields/#extended-http-metadata-collection). Grepr drops any custom headers forwarded by collectors before processing the messages included in the payload.
+
+<HiddenFAQ
+  faqs={[
+    {
+      q: "How do I send logs from Sumo Logic to Grepr?",
+      a: "To send logs from Sumo Logic to Grepr, configure your collector to send logs to the Grepr ingestion URL instead of your Sumo Logic HTTP Logs and Metrics Source. The ingestion URL format is https://<integration-id>-<org-id>.ingest.grepr.ai/receiver/v1/http/<unique-http-collector>. Replace the unique-http-collector with the identifier from your Sumo Logic HTTP source."
+    },
+    {
+      q: "What is required to create a Sumo Logic integration with Grepr?",
+      a: "You need the endpoint URL from a configured HTTP Logs and Metrics Source in Sumo Logic. You must also ensure your logs are in JSON format, as the Sumo Logic integration only supports JSON log format. Set log_format:json in your collector configuration."
+    },
+    {
+      q: "How do I configure the Sumo Logic OpenTelemetry Collector to send logs to Grepr?",
+      a: "In your Sumo Logic Distribution for OpenTelemetry Collector configuration, set the endpoint value in the exporters.sumologic section to your Grepr ingestion URL. Set log_format to 'json'. You can also configure dual-shipping by including both Grepr and Sumo Logic exporters in your pipeline."
+    },
+    {
+      q: "Why must logs be in JSON format for the Sumo Logic integration?",
+      a: "The Grepr Sumo Logic integration is designed to work with JSON-formatted logs to ensure proper parsing and processing. If your logs are not in JSON format, you need to configure your collectors to convert them to JSON before sending to Grepr."
+    },
+    {
+      q: "Can I dual-ship logs to both Grepr and Sumo Logic?",
+      a: "Yes, you can configure your OpenTelemetry collector to send logs to both Grepr and Sumo Logic. In your collector configuration, add two exporters: one pointing to your Grepr ingestion URL and another pointing to your Sumo Logic endpoint. Both can be included in your logs pipeline."
+    },
+    {
+      q: "What is the difference between Sumo Logic HTTP source and OTLP/HTTP source?",
+      a: "Sumo Logic offers two types of sources: HTTP Logs and Metrics Source for traditional HTTP-based log collection, and OTLP/HTTP source for OpenTelemetry protocol data. If you use OTLP/HTTP, you must use the Grepr OpenTelemetry integration instead of the Sumo Logic integration."
+    },
+    {
+      q: "How do I find the unique HTTP collector identifier for my Sumo Logic source?",
+      a: "When you create an HTTP Logs and Metrics Source in Sumo Logic, the endpoint URL contains the unique collector identifier. It appears at the end of the URL path. You'll need this identifier to construct the complete Grepr ingestion URL."
+    },
+    {
+      q: "Does Grepr support Sumo Logic Extended HTTP Metadata Collection?",
+      a: "No, Grepr does not support Sumo Logic Extended HTTP Metadata Collection. Grepr drops any custom headers forwarded by collectors before processing the log messages in the payload."
+    },
+    {
+      q: "How can I reduce storage costs with the Sumo Logic integration?",
+      a: "After ingesting logs into Grepr through the Sumo Logic integration, you can use Grepr's Log Reducer and transformation features to reduce log volume before sending processed logs back to Sumo Logic. This helps optimize storage costs in Sumo Logic."
+    },
+    {
+      q: "What if my logs are not in JSON format when using Sumo Logic integration?",
+      a: "The Sumo Logic integration only supports JSON format. If your logs are in a different format, you need to configure your collector to parse and convert them to JSON before sending to Grepr. Most collectors like Fluentd and OpenTelemetry Collector support log parsing and transformation."
+    }
+  ]}
+/>

package/build/dist/docs-index/d77b1ac2-44f8-46ac-b9f3-a62eca6c35ff.json

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

package/build/dist/docs-index/d77b1ac2-44f8-46ac-b9f3-a62eca6c35ff.txt

@@ -0,0 +1,39 @@
+# Update a OTLP integration.
+
+**PUT** `/v1/integrations/otlp/{id}`
+
+**Operation ID**: `update_4`
+**Summary**: Update a OTLP integration.
+Updates an integration to connect to OTLP. The version should be increased by one for every new update in order for the write to succeed. Otherwise, a '409 Conflict' will be returned.
+
+## Tags
+- OpenTelemetry Integration
+## Parameters
+
+- **id** (required) - path
+  - Type: string
+
+## Request Body
+
+**Content-Type**: `application/json`
+
+**Schema**: `WriteOtlp`
+
+## Responses
+
+### 200
+
+Integration updated successfully
+
+- **Content-Type**: `application/json` / `ReadOtlp`
+### 401
+
+Unauthorized
+
+### 404
+
+Integration not found.
+
+### 409
+
+Integration was modified or deleted concurrently.

package/build/dist/docs-index/d7caf6f0-003c-4139-94e6-f45984a80e97.json

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

package/build/dist/docs-index/d7caf6f0-003c-4139-94e6-f45984a80e97.txt

@@ -0,0 +1,30 @@
+# Removes a user from the team
+
+**DELETE** `/v1/teams/{id}/users/{userId}`
+
+**Operation ID**: `removeUserFromTeam`
+**Summary**: Removes a user from the team
+Remove a user from the team.
+
+## Tags
+- Teams
+## Parameters
+
+- **id** (required) - path
+  - Type: string
+- **userId** (required) - path
+  - Type: string
+
+## Responses
+
+### 204
+
+User removed from team successfully
+
+### 401
+
+Unauthorized
+
+### 404
+
+Not Found

package/build/dist/docs-index/d9146c7c-6247-46a1-bdf4-07b44a6c7cfd.json

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

package/build/dist/docs-index/d9146c7c-6247-46a1-bdf4-07b44a6c7cfd.txt

@@ -0,0 +1,21 @@
+# DatasetRead
+
+**Type**: `object`
+
+## Properties
+
+- name: id (required)
+  type: string
+
+- name: name (required)
+  type: string
+
+- name: organizationId (required)
+  type: string
+
+- name: integrationId (required)
+  type: string
+
+- name: teamIds (optional)
+  type: array of string
+  description: The team IDs that this dataset is associated with.

package/build/dist/docs-index/d93c4c0d-507f-4851-9c52-85f05235f131.json

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

package/build/dist/docs-index/d93c4c0d-507f-4851-9c52-85f05235f131.txt

@@ -0,0 +1,24 @@
+# LogsFilter
+
+**Type**: `object`
+
+## Properties
+
+- name: name (required)
+  type: string
+
+- name: predicate (required)
+  type: `EventPredicate`
+
+- name: inverted (optional)
+  type: boolean
+  description: Whether to invert the predicate logic
+
+- name: maxLateEventTimestampDelta (optional)
+  type: string
+  description: Maximum allowed time delta between received and event timestamps. Events with a delta exceeding this threshold will be filtered out. ISO-8601 duration format.
+
+- name: type (required)
+  type: enum: `logs-filter`
+  description: Filters events based on a predicate.
+

package/build/dist/docs-index/d9ebb906-cfb6-4a49-abba-87b7bb7a9e06.json

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

package/build/dist/docs-index/d9ebb906-cfb6-4a49-abba-87b7bb7a9e06.txt

@@ -0,0 +1,17 @@
+# AttributeWildcardNode
+
+**Type**: `object`
+
+## Properties
+
+- name: attribute (required)
+  type: string
+  description: The attribute name
+
+- name: wildcard (required)
+  type: string
+  description: The term to match. This is a wildcard string that contains wildcards
+
+- name: type (required)
+  type: enum: `attribute-wildcard-node`
+  description: A node that represents an attribute wildcard in a parsed query.

package/build/dist/docs-index/da7879ab-ccc5-4959-bf7e-2b114abe055f.json

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

package/build/dist/docs-index/da7879ab-ccc5-4959-bf7e-2b114abe055f.txt

@@ -0,0 +1,34 @@
+# Creates or updates a Datadog integration app key
+
+**PUT** `/v1/integrations/datadog/{id}/app-key`
+
+**Operation ID**: `upsertAppKey`
+**Summary**: Creates or updates a Datadog integration app key
+Creates an app key for a Datadog integration if it doesn't exist and updates it otherwise.  If the key is updated while the integration is being used by a pipeline, the  new key will be picked at pipeline restart, rescaling or an update. 
+
+## Tags
+- Datadog Integration
+## Parameters
+
+- **id** (required) - path
+  - Type: string
+
+## Request Body
+
+**Content-Type**: `application/json`
+
+**Schema**: `SecretApi`
+
+## Responses
+
+### 204
+
+App key upserted successfully.
+
+### 401
+
+Unauthorized
+
+### 404
+
+Integration not found.

package/build/dist/docs-index/db27b65c-d09e-4067-bd6e-0462b4799de7.json

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

package/build/dist/docs-index/db27b65c-d09e-4067-bd6e-0462b4799de7.txt

@@ -0,0 +1,10 @@
+# ItemsCollectionVendorImportedException
+
+Collection of vendor imported exceptions
+
+**Type**: `object`
+
+## Properties
+
+- name: items (optional)
+  type: array of `VendorImportedException`

package/build/dist/docs-index/dbc0c97a-faa1-4641-bbc4-d5f37a7d1328.json

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

package/build/dist/docs-index/dbc0c97a-faa1-4641-bbc4-d5f37a7d1328.txt

@@ -0,0 +1,10 @@
+# ImmutableSetString
+
+Map from tag key to an ordered set of attribute paths to search for values. All paths will be tried, and all found values will be added. If no value is found, the tag will not be changed. The attribute paths are dot-separated. This does not remove existing tag values.
+
+**Type**: `array`
+
+## Properties
+
+- name: empty (optional)
+  type: boolean

package/build/dist/docs-index/dbf905fc-5cb6-4030-997a-710b87c2a894.json

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

package/build/dist/docs-index/dbf905fc-5cb6-4030-997a-710b87c2a894.txt

@@ -0,0 +1,11 @@
+# UsersUpdate
+
+**Type**: `object`
+
+## Properties
+
+- name: leaderUserIds (required)
+  type: array of string
+
+- name: memberUserIds (required)
+  type: array of string

package/build/dist/docs-index/dcab898d-db52-4e2f-afbf-15fe02cd9314.json

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

package/build/dist/docs-index/dcab898d-db52-4e2f-afbf-15fe02cd9314.txt

@@ -0,0 +1,20 @@
+# getTeamById
+
+**GET** `/v1/teams/{id}`
+
+**Operation ID**: `getTeamById`
+**Summary**: No summary provided.
+## Tags
+- Teams
+## Parameters
+
+- **id** (required) - path
+  - Type: string
+
+## Responses
+
+### default
+
+default response
+
+- **Content-Type**: `application/json` / `ReadTeam`

package/build/dist/docs-index/dcd11a4b-c142-4192-aedb-430fc359d5aa.json

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

package/build/dist/docs-index/dcd11a4b-c142-4192-aedb-430fc359d5aa.txt

@@ -0,0 +1,14 @@
+# DatabaseUserInfo
+
+**Type**: `object`
+
+## Properties
+
+- name: email (required)
+  type: string
+
+- name: firstName (required)
+  type: string
+
+- name: lastName (required)
+  type: string

package/build/dist/docs-index/de94354d-e6a6-4172-8f13-891e7f9a366c.json

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

package/build/dist/docs-index/de94354d-e6a6-4172-8f13-891e7f9a366c.txt

@@ -0,0 +1,20 @@
+# LogsValuesSource
+
+**Type**: `object`
+
+## Properties
+
+- name: name (required)
+  type: string
+
+- name: loop (optional)
+  type: boolean
+  description: If true, the source will loop over the values indefinitely when processing is STREAMING. In BATCH mode, this flag is ignored.
+
+- name: values (optional)
+  type: array of `LogEvent`
+  description: List of log events to be generated by the source.
+
+- name: type (required)
+  type: enum: `logs-values-source`
+  description: Generates log events with constant values.

package/build/dist/docs-index/decc59f9-e281-4704-bb3f-4aaf2537dc1c.json

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

package/build/dist/docs-index/decc59f9-e281-4704-bb3f-4aaf2537dc1c.txt

@@ -0,0 +1,113 @@
+---
+description: Learn how to use filters in a Grepr pipeline to include or exclude events, configure multiple processing paths, or transform events based on specific conditions.
+---
+
+import { Callout } from 'nextra/components'
+import { HiddenFAQ } from '@/components/HiddenFAQ'
+
+# Filter events in a Grepr pipeline
+
+You can use filter transforms in a Grepr pipeline to include or exclude log events based on specific conditions. Filters are configured using familiar query interfaces, such as SQL or Datadog, SPL, and New Relic-like query syntaxes.
+
+The filtering configuration options allow you to create simple to complex event routing scenarios, including selective application of transformations to a subset of events or routing different types of events to appropriate processing stages using flexible configuration options.
+
+## Filtering options
+
+The following is a summary of the options available when configuring filters in a Grepr pipeline:
+
+- Drop late-arriving events.
+- Pass all or only some events to the next step.
+- Process all or only some events using SQL before passing to a configurable pipeline step.
+- Pass all records to the next pipeline step and also through the SQL processing path.
+
+### Drop late-arriving data
+
+You can configure a maximum threshold for the difference between the event and received timestamps. The threshold is configured using a duration in the ISO-8601 format. Events that exceed this threshold are dropped from the pipeline. This is useful for scenarios where timely data is critical, and late-arriving events could affect analysis or reporting.
+
+### Pass events to the next pipeline step
+
+You can configure filters to pass events to the next step in the pipeline. You can pass all events through to the next pipeline step, use a filter query to pass only events that meet specific conditions, or disable the passthrough of events with the option of passing the events for SQL processing.
+
+Filter queries use familiar query syntax similar to that of popular observability platforms, such as Datadog, Splunk, and New Relic. To learn more about the supported query syntaxes, see [Query log data in Grepr](/queries).
+
+### Process events with SQL
+
+The SQL processing path allows you to define complex transformations using ANSI standard SQL queries. You define the SQL query to process events and the name of a view to contain the results of query processing. You can create multiple queries and views that process data sequentially, with each view able to reference input events through the `logs` input table or previously defined views. Based on the filter's location in the pipeline, the results of SQL processing can be routed to specific pipeline steps, such as the JSON or Grok parsers, the Data Lake, the Reducer, or directly to the pipeline Sinks.
+
+You can choose to process all events or only events that don't meet the criteria for passthrough to the next pipeline step. You can further select specific events for SQL processing using a filter query. This feature provides flexibility to apply SQL transformations only to relevant events.
+
+You can also choose to materialize the results of query processing for reuse in subsequent views, improving performance for complex transformation scenarios.
+
+<Callout>
+  When you transform events using SQL, the results of processing replace the original event. If you want to retain all fields from the original event, include the wildcard character (`*`) in your `SELECT` statement. For example, to transform the severity while keeping all other fields: `SELECT *, CASE WHEN severity > 16 THEN 21 ELSE severity END as severity FROM logs`.
+</Callout>
+
+To learn more about using SQL in Grepr pipelines, see [Transform events with SQL](/transforms/sql-transform).
+
+## Configure filters in the Grepr pipelines UI
+
+In the Grepr pipelines UI, filters are available in predefined locations in a pipeline. To add one of these filters to your pipeline:
+
+1. In the Grepr pipelines UI, in the left-hand navigation menu, select the **Pre-parsing**, **Post-parsing**, or **Post-warehouse** filter to open the filter detail pane.
+1. In the filter detail pane, click the pencil icon to display the filter configuration form.
+
+   ![The pre-parsing filter configuration form with the default settings.](/images/pipelines/filter-edit-config.png)
+
+1. Configure the filtering and routing of events:
+   - In the **Max Lateness** field, optionally enter a duration in ISO-8601 format to drop late-arriving data.
+   - In the **Next Step Passthrough** section, to pass events to the next pipeline step, ensure that **Enable data passthrough to next step** is selected. To optionally select events for passthrough based on specific criteria, enter a query in the **Filter Query** field.
+   - To process events using SQL, select **Enable SQL processing** and select whether to process all events or only events that are not passed to the next step. Optionally enter a query in the **Filter Query** field to conditionally select events for SQL processing. This screenshot shows a filter configuration that passes events associated with `host-1` and `host-4` to the next pipeline step. All other events are processed using SQL.
+
+    ![The filter configuration form with settings to pass specific events to the next pipeline step, and process all other events using SQL.](/images/pipelines/filter-edit-config-passthrough.png)
+
+1. Configure how to process events with SQL:
+   - To optionally apply SQL processing to events that meet specific criteria, enter a query in the **SQL Filter Query** field.
+   - In the **SQL Views** section, click the plus sign to add one or more **SQL Input** definitions. In the **View name** field, enter a name for the view to contain the results of processing, and in the **SQL** field, enter the SQL query to process input events.
+   - Optionally select **Reuse calculation** to materialize the results of query processing for reuse in subsequent views.
+   - In the **Outputs** section, configure one or more pipeline steps to receive the results of SQL processing. This screenshot shows a configuration that selects events where the message includes `No data received` and saves them to a view named `no_data_messages`. The view is then routed to the pipeline sinks, which forward it to your observability platform or other destinations.
+
+    ![The filter configuration form with a SQL view that selects log events based on message content.](/images/pipelines/filter-edit-config-sqltransform.png)
+
+<HiddenFAQ faqs={[
+  {
+    q: "What is event filtering and why would I use it?",
+    a: "Event filtering allows you to include or exclude log events from pipeline processing based on specific conditions. Use filtering to remove unwanted events, focus processing on relevant data, reduce volume, prevent sensitive data from flowing through the pipeline, or route different event types to different processing stages."
+  },
+  {
+    q: "Where are filters located in a Grepr pipeline?",
+    a: "Filters are available in predefined locations throughout a pipeline: Pre-parsing filter (before initial processing), Post-parsing filter (after Grok parsing), and Post-warehouse filter (after data lake storage). Each location allows you to filter at different stages of log processing."
+  },
+  {
+    q: "What filtering options are available in Grepr?",
+    a: "Grepr provides options to drop late-arriving events, pass all or some events to the next pipeline step using query filters, process events with SQL before passing to a pipeline step, or pass all records to the next step while also routing some through SQL processing for enrichment."
+  },
+  {
+    q: "How do I filter out late-arriving events?",
+    a: "In the filter configuration, enter a Max Lateness value in ISO-8601 duration format. Events that arrive later than this duration after their timestamp are dropped from the pipeline. This is useful when timely data is critical and late data could affect analysis."
+  },
+  {
+    q: "What query languages does Grepr support for filtering?",
+    a: "Grepr supports multiple query syntaxes including Datadog query language, Splunk Processing Language (SPL), New Relic-like syntax, and standard SQL. Choose the query language that matches your observability platform or preference."
+  },
+  {
+    q: "How do I create a simple filter to exclude events?",
+    a: "In the Pre-parsing, Post-parsing, or Post-warehouse filter, ensure 'Enable data passthrough to next step' is selected. Enter a filter query that matches events you want to keep. Events matching the query pass to the next step, while others are excluded or processed separately."
+  },
+  {
+    q: "Can I route different event types to different pipeline paths?",
+    a: "Yes. Use multiple SQL views in the filter's SQL processing path to route different events to different destinations. Each view can contain a different SQL query that processes a specific event type and routes it to appropriate pipeline steps."
+  },
+  {
+    q: "What is the difference between passthrough and SQL processing?",
+    a: "Passthrough sends events directly to the next pipeline step based on a filter query. SQL processing allows you to transform events using SQL statements before routing them to different pipeline steps. You can enable both to handle events in different ways simultaneously."
+  },
+  {
+    q: "How do I use SQL to transform events in a filter?",
+    a: "Enable SQL processing in the filter configuration, then create SQL views with names and SQL queries. Each view can process events and the results can be routed to pipeline steps like the Data Lake, Reducer, or Sinks. Reference input events using the 'logs' input table."
+  },
+  {
+    q: "What does the shouldMaterialize option do in filters?",
+    a: "When enabled, shouldMaterialize caches the results of a SQL view so subsequent SQL views can reuse the cached results instead of re-running the query. This improves performance when multiple views need the results of the same transformation."
+  }
+]} />
+

package/build/dist/docs-index/df1fe6b2-0a41-4a75-98de-91a3793d88db.json

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

package/build/dist/docs-index/df1fe6b2-0a41-4a75-98de-91a3793d88db.txt

@@ -0,0 +1,20 @@
+# List all OTLP integrations
+
+**GET** `/v1/integrations/otlp`
+
+**Operation ID**: `list_4`
+**Summary**: List all OTLP integrations
+Get all OTLP integrations.
+
+## Tags
+- OpenTelemetry Integration
+## Responses
+
+### 200
+
+Integrations retrieved successfully
+
+- **Content-Type**: `application/json` / `ItemsCollectionReadOtlp`
+### 401
+
+Unauthorized

package/build/dist/docs-index/df8f3e33-fc59-4774-b6bd-d412050a2ed6.json

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