@grepr/cli 1.13.0-2632478 → 1.14.3-a181b29

package/build/dist/docs-index/f7c3afd0-803a-4362-bdae-e4b44c8b68c3.txt

@@ -1,119 +0,0 @@
-Learn how to safely test data transformation changes to a running production pipeline with the Grepr live edit feature.
-
-# View pipeline data flows and test changes with live edit
-
-The Grepr live edit feature allows you to:
-
-* Safely test changes to data transformations in a running production pipeline. Using live edit, you can make and test changes to the pipeline's data processing and transformations without impacting the processing of live data and the flow of that data to your observability tools. After you've validated your changes, you can apply those changes to the production pipeline.
-* See a live view of how data flows and is processed by the running production pipeline. You can use this capability to monitor the data flowing through your pipeline in real time, even if you're not making changes to the pipeline.
-
-The live edit feature works by creating a temporary copy of the current pipeline but excludes the sink, preventing duplicate data from being sent to your observability platform. Your changes run in the copy of the pipeline. The state of the data at each step of the copied pipeline can be seen in the live edit view. You can also use this view to compare the results of processing between the original and copy pipelines, allowing you to get fast feedback on your changes.
-
-> To ensure that the data passing through the pipeline copy doesn't exceed the UI's capacity, the pipeline copy receives a sampling of the pipeline data. To ensure the pipeline copy is receiving the data you need and the output data contains only the fields you need, you can use filter functionality in the live edit UI. See [Create a subset of data for testing using filters](#filter-source-data).
-
-Any changes you make that are not applied to the production pipeline are visible only in the pipeline copy, and no data is sent to configured sinks or data lakes. When your changes are tested and ready to apply to production, you can apply them to the original pipeline.
-
-## Using live edit with your pipelines
-
-To use live edit:
-
-1. In the Grepr UI, go to the details page for your pipeline.
-
-2. In the lower right corner of the page, click the expand icon to open the **Pipeline Log Viewer**.
-
-3. To create and start a temporary copy of your pipeline, in the expanded **Pipeline Log Viewer** pane, click the play icon.
-
-4. Grepr creates a temporary copy of your pipeline and runs it using log events sampled from the original pipeline's source data. The **Pipeline Log Viewer** pane updates to show the status of the pipeline copy as it's created and started.
-
-5. When the temporary pipeline copy is provisioned and started, the **Pipeline Log Viewer** pane displays the raw logs sampled from the original pipeline's source data. You can use this view to examine logs at different stages of processing, and to test and validate changes to processing.
-
-To examine logs at different stages of processing, use the **Left table link** or **Right table link** menus to select the stage of processing to view.
-
-To view details of a log event, click the event in the **Pipeline Log Viewer** pane to open the log detail pane. The log detail pane displays the contents of the selected log event at the selected processing steps. The top bar of the log detail pane displays the event type, such as `INFO`, `ERROR`, or `DEBUG`, and the timestamp of the log message. To view the state of the event in the selected processing step in the left table, click **LEFT**. To view the state of the event in the selected processing step in the right table, click **RIGHT**. Click **DIFF** to view a JSON comparison of the event state in the left and right panels.
-
-## Create a subset of data for testing using filters \[#filter-source-data]
-
-Because the pipeline copy is receiving a sampling of the source data to ensure that the UI's capacity is not exceeded, the **Pipeline Log Viewer** supports functionality to filter source data. This filtering functionality ensures you get the correct data required for your testing. You can also use this feature to select specific columns to include in tables created from the filtered data.
-
-To use the filter functionality, click the filter icon next to the stop icon. In the filter dialogue, select your preferred query syntax from the **Query language** menu, and enter your filter query in the **Sampler query** text box. To select the columns you want to see in a table created from the filtered data, add and remove column names in the **Table Columns** input.
-
-## Example: Use live edit to add and test a pipeline filter
-
-You can use a local file containing logs for testing instead of streaming live data from the pipeline. This feature can be useful for tasks such as
-
-> * This example uses the pipeline created in the [Build your first Grepr pipeline](/tutorials/first-pipeline) tutorial. If you want to follow the example, first complete that tutorial.
-> * Although this example uses Datadog, you can use the live edit feature with any Grepr-supported observability platform. For the complete list of supported observability vendors, see [Supported integrations](/integrations/support-matrix).
-
-In this example, you use the following steps to test an action that drops any log messages received by your Grepr pipeline that are assigned the hostname `my-test-host-1`.
-
-1. In the Grepr UI, go to the details page for your running pipeline.
-2. In the left pane, click **Pre-Parsing Actions**, click **Add Action**, and select **Condition (If/Else)**.
-3. Make sure the query language is set to **Datadog**, and enter the following query in the **IF** row:
-
-```bash
-host:my-test-host-1
-```
-
-1. End the **IF** branch with **Drop**, and leave the **ELSE** branch ending with the next pipeline step.
-
-2. *Do not* click **Apply Changes**. Before applying the changes to the production pipeline, use the live edit feature to test and validate the action.
-
-3. In the lower right corner of the page, click the expand icon to open the **Pipeline Log Viewer** and click the play icon to create and start a temporary copy of your pipeline with the action added.
-
-4. In the **Pipeline Log Viewer** left table, click a log message from `my-test-host-1`. The log detail pane opens. Because the action drops the log messages from the pipeline, only the **LEFT** table view is displayed.
-
-5. When you complete validation of your change, click **Apply Changes** to save the new configuration to the production pipeline.
-
-## Use a local file for testing
-
-You can use log events in a local file for testing instead of streaming live data from the pipeline. This can be useful when you want to test pipeline changes against a consistent set of log events, or if you want to test with specific log events that are not currently flowing through the pipeline.
-
-> The log file must be formatted as JSON or plain text, and must not exceed 10 MB in size.
-
-To upload a file for testing:
-
-1. In the **Pipeline Log Viewer** pane, next to the play icon, click **Live** and click the **UPLOAD** tab.
-2. Drag and drop the file to upload, or click the upload area to select the file.
-3. Click **Apply**
-
-## Frequently Asked Questions
-
-### What is the Grepr live edit feature?
-
-Live edit is a feature that allows you to safely test changes to data transformations in a running production pipeline without impacting live data. It creates a temporary copy of your pipeline that excludes sinks, preventing duplicate data from being sent to your observability platform while you test changes.
-
-### How do I start using live edit?
-
-To use live edit, go to the details page for your running pipeline, click the expand icon in the lower right corner to open the Pipeline Log Viewer, and then click the play icon to create and start a temporary copy of your pipeline with sampled data.
-
-### Will live edit changes affect my production pipeline?
-
-No. Changes made in live edit are only visible in the temporary pipeline copy and do not affect production. No data is sent to configured sinks or data lakes until you explicitly apply the changes to the production pipeline.
-
-### What is the Pipeline Log Viewer?
-
-The Pipeline Log Viewer is a pane in the pipeline details that displays logs sampled from the original pipeline's source data. It allows you to examine logs at different processing stages, see how transformations affect data, and compare results between the original and test pipelines.
-
-### Can I see how data flows through each stage of my pipeline?
-
-Yes. Use the Pipeline Log Viewer to examine logs at different stages of processing. Select the processing step from the Left table link or Right table menu to see data at that point. Click a log event to open the detail pane and view its state at different processing steps.
-
-### Why does live edit use sampled data instead of all pipeline data?
-
-Live edit uses sampled data to ensure the pipeline copy doesn't exceed the UI's capacity. This prevents performance issues while still providing representative data for testing. You can use filter functionality to select specific data needed for your testing.
-
-### How do I filter the data shown in Pipeline Log Viewer?
-
-Click the filter icon next to the stop icon in the Pipeline Log Viewer. In the filter dialog, select your preferred query language syntax and enter your filter query in the Sampler query text box. You can also add or remove column names in the Table Columns input to customize the displayed data.
-
-### What does DIFF view show in the log detail pane?
-
-DIFF view shows a JSON comparison of an event's state between the left and right panels of the Pipeline Log Viewer. This allows you to see exactly what changed when processing logs through different pipeline stages or comparing original versus modified pipelines.
-
-### How do I apply tested changes to my production pipeline?
-
-After you've validated your changes in live edit, click 'Apply Changes' in the pipeline editor to save the new configuration to the production pipeline. Your changes will be applied to the running pipeline.
-
-### Can I use live edit to monitor data without making changes?
-
-Yes. You can use live edit to see a live view of how data flows and is processed by your running production pipeline without making any modifications. This allows you to monitor pipeline behavior and performance in real-time.

package/build/dist/docs-index/f7dc66fe-317d-4e6b-b8e2-12aa70741ddb.json

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

package/build/dist/docs-index/f7dc66fe-317d-4e6b-b8e2-12aa70741ddb.txt

@@ -1,28 +0,0 @@
-# PipelineChangeRequest
-
-**Type**: `object`
-
-## Properties
-
-- name: autoApply (optional)
-  type: boolean
-  description: Whether to apply the change directly (true) or record it as a suggestion for a human to review (false). This expresses intent only: the server enforces the proposing agent's approval mode, so a suggest-only agent's change is always recorded as a suggestion no matter what is passed here.
-
-- name: changeDescription (optional)
-  type: string
-  description: One or two sentences a human reviewer reads first: what the change does and why. Required when the change is recorded as a suggestion.
-
-- name: changeId (optional)
-  type: string
-  description: A caller-chosen idempotency key for this change, unique within the investigation. Resending the same changeId records one suggestion rather than a duplicate, so a retried call is safe. Required when the change is recorded as a suggestion.
-
-- name: investigationId (optional)
-  type: string
-  description: The investigation proposing the change, identifying the agent whose approval mode governs the request. Server-supplied on the MCP transport, where an agent sandbox's provenance is bound to the connection: anything sent here is ignored and replaced. Without provenance the change is applied under the caller's own permission.
-
-- name: samples (optional)
-  type: array of `LogEvent`
-  description: Sample log events the changed operations are verified against before anything is applied. Required when the change adds or edits a Grok rule, so the new rule can be run against a real log.
-
-- name: templateInputsPatch (required)
-  type: `JsonNode`

package/build/dist/docs-index/f80b6cc7-6e21-4b76-9623-5c883c9920c3.json

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

package/build/dist/docs-index/f80b6cc7-6e21-4b76-9623-5c883c9920c3.txt

@@ -1,23 +0,0 @@
-# ExternalTriggerPayload
-
-Payload that define attributes that will fire an external source trigger.
-
-**Type**: `object`
-
-## Properties
-
-- name: jobId (required)
-  type: string
-  description: ID of the job that the trigger is meant for.
-
-- name: logsRuleEngineName (required)
-  type: string
-  description: Name of the rule engine that will process the trigger. This must exist in the corresponding Grepr job graph.
-
-- name: triggerId (required)
-  type: string
-  description: ID of the external source trigger that should be triggered. This must exist in the Logs Rule Engine configuration of the corresponding job
-
-- name: variables (optional)
-  type: object
-  description: Variables needed by the conditions that get activated when the corresponding triggers gets fired. 

package/build/dist/docs-index/f8209bf9-f128-4664-ba1b-f0a1bc8280a7.json

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

package/build/dist/docs-index/f8209bf9-f128-4664-ba1b-f0a1bc8280a7.txt

@@ -1,57 +0,0 @@
-# SearchIssuesRequest
-
-Filters for searching the issues the caller can see. Every filter is optional; all given filters must match. Results are ordered by full-text rank when `query` is given, else by latest sighting.
-
-**Type**: `object`
-
-## Properties
-
-- name: assignee (optional)
-  type: `IssueAssigneeFilter`
-
-- name: closedWithinDays (optional)
-  type: integer
-  description: Include closed issues closed within this many days. Absent: 30 when `states` is absent, with those closed as IGNORED or NOT_A_PROBLEM kept at any age, and no window when it is given. Given, it's exact.
-
-- name: cursor (optional)
-  type: string
-  description: The `nextCursor` of the previous page, sent with the same filters.
-
-- name: entities (optional)
-  type: object
-  description: Entity tags to match: every key must match, and any of a key's values matches it. Keys and values match in any case. An unprefixed key is put in the `entity:` namespace.
-
-- name: fingerprint (optional)
-  type: string
-  description: Only issues with exactly this fingerprint.
-
-- name: labels (optional)
-  type: array of string
-  description: Only issues carrying every one of these labels.
-
-- name: limit (optional)
-  type: integer
-  description: The page size, at most 100; absent: 25.
-
-- name: linkedTo (optional)
-  type: `IssueLinkRef`
-
-- name: priority (optional)
-  type: enum: `P0`, `P1`, `P2`, `P3`
-  description: Only issues at this priority or more urgent.
-
-- name: query (optional)
-  type: string
-  description: Words to search the whole issue for, comments included, split and stemmed as the issue is, so checkout-api is also checkout and api: an issue matches when it has any one of them, and those with the most, above all in their title, fingerprint and entities, come first.
-
-- name: states (optional)
-  type: array of enum: `TRIAGE`, `READY`, `IN_PROGRESS`, `WAITING`, `MONITORING`, `CLOSED`
-  description: Only issues in these states. Absent: open issues plus those closed within `closedWithinDays`, and, when that is absent too, those closed as IGNORED or NOT_A_PROBLEM at any age.
-
-- name: teamIds (optional)
-  type: array of string
-  description: Only issues one of these teams can see: linked to one of them, or shared with all teams.
-
-- name: updatedSince (optional)
-  type: string
-  description: Only issues changed at or after this time.

package/build/dist/docs-index/f833b65f-97c6-4752-9c3c-efc16bd5ba29.json

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

package/build/dist/docs-index/f833b65f-97c6-4752-9c3c-efc16bd5ba29.txt

@@ -1,35 +0,0 @@
-# RecordMemoryRequest
-
-**Type**: `object`
-
-## Properties
-
-- name: clear (optional)
-  type: array of enum: `SYMPTOMS`, `ROOT_CAUSE`, `RULED_OUT`, `RESOLUTION`, `ENTITY_TAGS`
-
-- name: entityTags (optional)
-  type: object
-
-- name: resolution (optional)
-  type: string
-
-- name: rootCause (optional)
-  type: string
-
-- name: rootCauseConfidence (optional)
-  type: enum: `CONFIRMED`, `SUSPECTED`, `UNKNOWN`
-
-- name: ruledOut (optional)
-  type: string
-
-- name: searchableBySimilarity (optional)
-  type: boolean
-
-- name: significance (required)
-  type: enum: `INCIDENT`, `OBSERVATION`, `INCONCLUSIVE`, `BENIGN`
-
-- name: symptoms (optional)
-  type: string
-
-- name: title (required)
-  type: string

package/build/dist/docs-index/f8425f83-6db1-4bd9-adf0-09d2bdc72920.json

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

package/build/dist/docs-index/f8425f83-6db1-4bd9-adf0-09d2bdc72920.txt

@@ -1,49 +0,0 @@
-# MetricReducer
-
-Reduces metric volume by aggregating per-object time series into per-cohort summaries while preserving the original signal when anomaly rules fire. Series that don't belong to a monitored object flow through unchanged; series matching a drop rule are discarded.
-
-**Type**: `object`
-
-## Properties
-
-- name: anomalies (optional)
-  type: array of `AnomalyConfig`
-  description: Anomaly rules.
-
-- name: anomalyActions (optional)
-  type: `AnomalyActions`
-
-- name: cohorts (optional)
-  type: `CohortsConfig`
-
-- name: dropRules (optional)
-  type: array of `DropRule`
-  description: Drop rules — matching series are discarded outright.
-
-- name: emitInterval (required)
-  type: string
-  description: How often the reducer flushes cohort-level output.
-
-- name: hostMetadata (optional)
-  type: `HostMetadataReporting`
-
-- name: lateArrivalWaitDuration (required)
-  type: string
-  description: Watermark delay applied to give late-arriving data a chance to be aggregated.
-
-- name: name (required)
-  type: string
-
-- name: objects (required)
-  type: `ObjectsConfig`
-
-- name: spaceAggOverrides (optional)
-  type: object
-  description: Per-metric-name overrides for space (cross-object) aggregation.
-
-- name: timeGranularity (required)
-  type: `TimeGranularity`
-
-- name: type (required)
-  type: enum: `metric-reducer`
-  description: Metric reducer.

package/build/dist/docs-index/f87963f6-8c42-43a7-a2a0-19b5b756d252.json

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

package/build/dist/docs-index/f87963f6-8c42-43a7-a2a0-19b5b756d252.txt

@@ -1,39 +0,0 @@
-# Update a GitHub MCP integration.
-
-**PUT** `/v1/integrations/github-mcp/{id}`
-
-**Operation ID**: `update_6`
-**Summary**: Update a GitHub MCP integration.
-Updates a GitHub MCP integration. 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
-- GitHub MCP Integration
-## Parameters
-
-- **id** (required) - path
-  - Type: string
-
-## Request Body
-
-**Content-Type**: `application/json`
-
-**Schema**: `WriteGithubMcp`
-
-## Responses
-
-### 200
-
-Integration updated successfully
-
-- **Content-Type**: `application/json` / `ReadGithubMcp`
-### 401
-
-Unauthorized
-
-### 404
-
-Integration not found.
-
-### 409
-
-Integration was modified or deleted concurrently.

package/build/dist/docs-index/f88f937d-dd61-41a4-9925-93e2a4e6f5b6.json

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

package/build/dist/docs-index/f88f937d-dd61-41a4-9925-93e2a4e6f5b6.txt

@@ -1,231 +0,0 @@
-Learn how to create a Grepr pipeline, integrate the pipeline with your observability platform, such as Datadog, Splunk, or New Relic, and use that pipeline to lower your observability costs by dynamically reducing shipped log volumes.
-
-# Tutorial: Build your first Grepr pipeline
-
-This tutorial is an end-to-end example that shows you how Grepr dynamically reduces the volume of shipped logs without losing data. It does this by walking you through an example that integrates Grepr with Datadog, creates a Grepr pipeline that processes log events forwarded from Datadog agents, and sends the resulting events to Datadog.
-
-In this tutorial, you:
-
-1. Verify that you can directly send log events from your local environment to Datadog.
-2. Configure a Grepr integration with Datadog.
-3. Configure a Grepr storage integration to store raw logs in the Grepr data lake.
-4. Create a Grepr pipeline that processes raw logs and sends the resulting processed events to Datadog.
-5. Use Docker to simulate multiple hosts sending log events to Grepr by running multiple Datadog agents in your local environment.
-6. Run the pipeline and view the output in the Grepr and Datadog UIs.
-
-> * This tutorial uses Datadog as the observability tool. However, you can use this tutorial to create a pipeline that integrates with any Grepr-supported observability tool. For the complete list of supported observability vendors, see [Grepr supported vendor and storage integrations](/integrations/support-matrix).
-> * To show you the most direct way to create a pipeline in the Grepr UI, this tutorial walks you through creating an end-to-end pipeline directly in the Grepr pipeline editor. However, to give you more control over configurations, the Grepr UI also includes separate interfaces to configure pipeline components such as integrations.
-> * This tutorial shows you how to send logs to Grepr using Datadog agents running in local Docker containers. However, if you have existing infrastructure forwarding logs to Datadog, you can use that infrastructure for this example. The Grepr Datadog integration also supports log collectors other than Datadog agents. To learn more about supported collectors, including configuration details, see [Configure Datadog connections with a Grepr integration](/integrations/datadog).
-
-## Requirements
-
-To complete this tutorial, you must have:
-
-* A Grepr account and a login to your organization's Grepr UI. If you don't have a Grepr account, sign up at <https://app.grepr.ai/signup>.
-* An organization identifier. A 3–31 character identifier containing only lowercase letters, numbers, and hyphens. If you don't have one, create an organization ID when you sign up for a Grepr account.
-* An account with an observability vendor supported by Grepr. This tutorial uses Datadog. If you don't have a Datadog account, you can sign up for a free trial at [www.datadoghq.com](https://www.datadoghq.com). For the complete list of supported observability vendors, see [Grepr supported vendor and storage integrations](/integrations/support-matrix).
-* A Datadog API key for your account. You can retrieve this from your Datadog Organization Settings or copy it from the Agent Setup page instructions.
-* The Datadog site parameter that the Datadog agents should use. This parameter is determined by the Datadog site you selected. For example, if you select `US1`, the site parameter's value is `datadoghq.com`.
-* A Docker installation in your local environment. Docker is used to run the Datadog agents that send log events to Grepr.
-
-## Step 1: Verify that agents can send events to Datadog
-
-Before working through this tutorial, you should verify that Datadog agents running in your local environment can send log events directly to Datadog. In a terminal window, run the following command, replacing `DD_API_KEY_VALUE` with your Datadog API key and `DD_SITE_VALUE` with your Datadog site parameter. Optionally replace `DD_HOSTNAME` with a preferred hostname for testing. This value can be used in the Datadog UI to filter incoming log events:
-
-```bash
-docker run --rm --name dd-agent \
--e DD_API_KEY=DD_API_KEY_VALUE \
--e DD_SITE="datadoghq.com" \
--e DD_LOGS_ENABLED=true \
--e DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL=true \
--e DD_HOSTNAME=my-test-host \
--v /var/run/docker.sock:/var/run/docker.sock:ro \
--v /proc/:/host/proc/:ro \
--v /sys/fs/cgroup/:/host/sys/fs/cgroup:ro \
-gcr.io/datadoghq/agent:latest
-```
-
-While this command runs, go to the Datadog UI, click **Logs**, and then click **Live Tail**. If everything's working correctly, you see log events arriving from the Datadog agent.
-
-To learn more about the Datadog Docker Agent, including details for the configuration options, see the [Datadog documentation](https://docs.datadoghq.com/containers/docker/).
-
-When you've finished testing, shut down the agent by running the following command in a separate terminal:
-
-```bash
-docker stop dd-agent
-```
-
-## Step 2: Create a Grepr pipeline to process log events
-
-A Grepr pipeline defines the steps to process log data. Pipelines you create in the Grepr UI implement a flow with the following steps to reduce the volume of log data sent to your observability platform:
-
-* Read logs from one or more sources. Sources use Grepr integrations that connect Grepr to external systems, such as observability vendors or cloud storage providers. This tutorial guides you through creating a source that uses a Grepr Datadog integration.
-
-* Filter log events at several stages in the pipeline.
-
-* Extract structured data from unstructured log messages or attributes using the Grepr Grok parser. See the [Grok parser](/transforms/grok) documentation.
-
-* Persist the raw logs into your Grepr data lake. To add a data lake in the pipeline editor, you must have a Grepr storage integration and a Grepr dataset configured.
-
-  * The storage integration is used to ensure retention of all data by storing raw logs in low-cost cloud storage. This tutorial uses a storage integration that uses a Grepr-hosted Amazon S3 bucket.
-  * The dataset defines a namespace in your storage specifying where the raw logs are stored.
-
-* Reduce the amount of log data to forward to your observability platform through the log reducer. To learn more about the log reducer, see [Reduce shipped data volumes with the Grepr log reducer](/transforms/reducer).
-
-* Send the result of processing the logs to one or more sinks. Like sources, sinks use a configured Grepr integration.
-
-To create pipelines with more complex functionality, you can use the Grepr REST API. See the [Job creation API guide](/apis/job-creation-guide).
-
-To create a new pipeline:
-
-1. In the Grepr UI, click **Home** in the navigation menu, then click **Create Pipeline**.
-
-2. In the **Create Pipeline** dialog, enter a name for your new pipeline.
-
-3. Click **Create**.
-
-After clicking **Create**, the pipeline editor view appears. The left pane displays the flow for a log reduction pipeline. In the next step, you begin configuring the pipeline by adding a source.
-
-### Add a source for Datadog logs
-
-To add a source in the pipeline editor, you first configure a Grepr integration. To create an integration and add a source:
-
-1. Click **Continue** in the pipeline editor view.
-
-2. Click **Add integration**.
-
-3. In the **Add Observability Vendor** dialog:
-
-   * In the **Type** menu, select **Datadog**.
-   * In the **Name** field, enter a name for the integration.
-   * In the **Site** menu, select the parameter matching your Datadog site.
-   * In the **API Key** field, enter your Datadog API key.
-   * Leave the **Application Key** field empty.
-
-4. Click **Create**.
-
-   After clicking **Create**, Grepr validates the API key with Datadog, creates the integration, and returns a success message. If any issues are found, an error message is returned instead.
-
-5. In the **Add source** dialog, select the Datadog integration you created in the previous step. A name for this source is automatically added for you.
-
-6. Click **Submit**.
-
-### Add a data lake
-
-To add a Grepr data lake to retain raw log data, you first configure a Grepr storage integration. To create a storage integration and add a data lake to your pipeline:
-
-1. Click **Data Lake** in the left pane, then click **Add**.
-
-2. In the **Add Data Lake** dialog:
-
-   * In the **Type** menu, select **Grepr-hosted**.
-   * In the **Name** field, enter a name for the integration.
-
-3. Click **Next**.
-
-4. In the **Dataset Name** field, enter a name for the dataset to contain raw data. This can be any name you choose, but it should be descriptive.
-
-5. In the **Integration** menu, select the storage integration you created in the previous step.
-
-6. Click **Add**.
-
-To send the processed logs to Datadog, a sink is automatically added to your pipeline. Click **Sinks** in the left pane to view the sink. Under **Additional Tags / Attributes**, you can see automatically populated tags. These tags are appended to messages before they're sent to Datadog. Grepr recommends retaining these tags because they allow you to distinguish Grepr-processed logs from other logs.
-
-## Step 3: Create and start the pipeline
-
-Click **Create Pipeline** in the top bar, then click **Confirm** in the **Create pipeline** dialog. Your pipeline will shortly go from **Starting** to **Running**. When the pipeline reaches the **Running** state, it's ready to start processing logs. In the next step, you simulate sending log messages through your pipeline.
-
-## Step 4: Simulate multiple agents sending logs through Grepr
-
-1. Before sending log messages to your pipeline, make sure no Docker containers are running the Datadog agent. In a terminal, run the following command:
-
-   ```bash
-   docker stop dd-agent
-   ```
-
-2. To configure the Datadog agents to send logs to Grepr, you need the Grepr ingestion URL. To find the URL, click **Sources** in the left pane and copy the **Ingest URL** value.
-
-3. To start five agents to send logs through Grepr, run the following command, replacing `INGESTION_URL` with the Grepr ingestion URL you copied above, and `DD_API_KEY_VALUE` with your Datadog API key:
-
-   ```bash
-   for i in $(seq 1 5); do docker run -d --rm --name dd-agent-$i \
-   -e DD_API_KEY=DD_API_KEY_VALUE \
-   -e DD_SITE="datadoghq.com" \
-   -e DD_LOGS_ENABLED=true \
-   -e DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL=true \
-   -e DD_HOSTNAME=my-test-host-$i \
-   -v /var/run/docker.sock:/var/run/docker.sock:ro \
-   -v /proc/:/host/proc/:ro \
-   -v /sys/fs/cgroup/:/host/sys/fs/cgroup:ro \
-   -e DD_LOGS_CONFIG_LOGS_DD_URL=INGESTION_URL \
-   -e DD_LOGS_CONFIG_USE_HTTP="true" \
-   gcr.io/datadoghq/agent:latest; done
-   ```
-
-   This command starts five agents, each with a different hostname. There are two new environment variables added to the command: `DD_LOGS_CONFIG_LOGS_DD_URL` and `DD_LOGS_CONFIG_USE_HTTP`. The first variable provides the agents with the Grepr URL to send logs to, and the second variable tells the agents to use HTTPS instead of TCP when sending logs to Grepr.
-
-   > Before sending logs for ingestion, ensure there's at least one running pipeline that includes a Datadog source that matches the Datadog integration you created in Step 2. If a pipeline doesn't exist, the ingestion requests are not accepted.
-
-## View the results
-
-After the agents are running, to monitor log ingestion activity, go to the Grepr Pipelines UI and select **Overview**.
-
-To see the logs arriving to Datadog, go to the Datadog **Log Explorer**. To filter for only messages arriving from your test agents, enter `host:my-test-host*` in the **Filter your logs** text box.
-
-When you scroll through the logs in the Datadog **Log Explorer**, you can see that repeated log events are aggregated. This aggregation, which reduces the data volumes sent to Datadog, is the result of the Grepr log reducer. To learn more about the log reducer, see [Reduce shipped data volumes with the Grepr log reducer](/transforms/reducer).
-
-## Cleaning up
-
-When you've finished the tutorial, you can stop the Datadog agents by running the following command in a terminal:
-
-```bash
-for i in $(seq 1 5); do docker stop dd-agent-$i; done
-```
-
-To stop the pipeline, go to the Grepr UI home page, click the **More options** icon (⋮) in the top-right corner of the pipeline card, select **Stop**, and then confirm that you would like to stop the pipeline.
-
-## Next steps
-
-To see an example of troubleshooting incidents with Grepr and Datadog, see the [troubleshooting tutorial](/tutorials/troubleshooting-example).
-
-## Frequently Asked Questions
-
-### What is a Grepr pipeline?
-
-A Grepr pipeline is a configurable data processing workflow that reads logs from sources, applies filters and transformations, optionally stores raw logs in a data lake, reduces log volume using intelligent aggregation, and sends processed logs to sinks. Pipelines allow you to dynamically control log volumes without losing important data.
-
-### How do I create my first Grepr pipeline?
-
-To create your first pipeline, sign in to the Grepr UI, click 'Create Pipeline' on the Home page, enter a name, and click Create. The pipeline editor will open where you can add sources, configure integrations, set up storage, and create sinks. This tutorial walks through the complete process with a Datadog example.
-
-### What observability platforms does Grepr support?
-
-Grepr supports multiple observability vendors, including Datadog, Splunk, New Relic, and others. For a complete list of supported platforms and regions, see the Grepr supported vendor and storage integrations documentation.
-
-### Do I need a Datadog account to follow this tutorial?
-
-Yes, this tutorial uses Datadog as an example. However, you can follow the same steps with any Grepr-supported observability platform. If you don't have a Datadog account, sign up for a free trial at www\.datadoghq.com or use your preferred observability platform.
-
-### What is the log reducer and how does it work?
-
-The log reducer is a Grepr component that intelligently aggregates repeated log events into summary messages, reducing the volume of logs sent to your observability platform. It identifies patterns in logs and uses placeholders for varying fields, allowing you to maintain visibility while reducing storage and processing costs.
-
-### How do I configure a Datadog integration in Grepr?
-
-To configure a Datadog integration, click 'Add integration' in the pipeline editor, select Datadog as the Type, enter a name for the integration, select your Datadog site from the menu, and enter your Datadog API key. Click Create and Grepr will validate the API key with Datadog.
-
-### What is the Grepr data lake and why do I need it?
-
-The Grepr data lake is a storage system that retains all raw log data in low-cost cloud storage using a Grepr-hosted Amazon S3 bucket. It ensures you don't lose any data while using the log reducer and allows you to backfill logs or perform historical analysis later.
-
-### How do I monitor logs flowing through my pipeline?
-
-You can monitor log ingestion in the Grepr Pipelines UI by selecting 'Overview' to see real-time event metrics. Additionally, go to your observability platform (Datadog, Splunk, etc.) to see the processed logs after reduction. In Datadog, filter using labels like 'host:my-test-host\*' to see logs from your test agents.
-
-### What happens to logs after the log reducer aggregates them?
-
-After the log reducer aggregates logs into summary messages, they are sent to your observability platform sinks. The summary messages include metadata like repeat count, first/last timestamps, and a pattern ID, allowing you to trace back to raw logs stored in the data lake if needed.
-
-### Can I test my pipeline changes before applying them to production?
-
-Yes, Grepr provides a live edit feature that allows you to safely test changes to your pipeline without impacting production. Live edit creates a temporary copy of your pipeline and excludes sinks, preventing duplicate data from being sent to your observability platform.

package/build/dist/docs-index/f8c02de3-98df-4d8e-8ed0-cb24defa993b.json

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

package/build/dist/docs-index/f8c02de3-98df-4d8e-8ed0-cb24defa993b.txt

@@ -1,28 +0,0 @@
-# TemplateOperation
-
-**Type**: `object`
-
-## Properties
-
-- name: draftMode (optional)
-  type: boolean
-  description: Set as a variable in the script scope, this input tells the script to run in 'draft' mode, which should enable additional outputs from various parts of the built pipeline, according to the Template's defined draft outputs.
-
-- name: name (required)
-  type: string
-
-- name: templateId (required)
-  type: string
-  description: The ID of the template to use for this operation.
-
-- name: templateInputs (optional)
-  type: object
-  description: Inputs to the template. Each entry in the map is added to the scope of the template javascript as a variable and can be accessed directly. In addition to the inputs, a 'user' object is also bound providing information about the current user.
-
-- name: templateVersion (required)
-  type: integer
-  description: The version of the template to use for this operation. Note that whether templates are forward- or backward-compatible are dependent on the template script, so updating or downgrading versions may result in an error in the job depending on the script.
-
-- name: type (required)
-  type: enum: `template-operation`
-  description: Runs a template script to generate a subgraph running in place of the operation in the parent graph.

package/build/dist/docs-index/f8cbca4d-ff11-41f4-bb8c-0f016d0df5c0.json

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