@grepr/cli 1.2.0 → 1.3.0-4e666db

package/build/dist/docs-index/5039fc20-3317-43d3-8829-64a4651ccc1c.txt

@@ -1,12 +0,0 @@
-# GrokParseBatchRequest
-
-**Type**: `object`
-
-## Properties
-
-- name: grokParser (required)
-  type: `GrokParser`
-
-- name: logSamples (required)
-  type: array of string
-  description: Log sample to parse using the provided Grok rules.

package/build/dist/docs-index/507d6fd6-9247-45a0-bf9e-1f275a371647.json

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

package/build/dist/docs-index/507d6fd6-9247-45a0-bf9e-1f275a371647.txt

@@ -1,29 +0,0 @@
-# TraceReducer
-
-Performs head sampling on trace data by filtering CompleteSpan instances based on deterministic hash-based sampling of their trace IDs. Uses MD5 hash function to ensure consistent sampling decisions across processing instances.
-
-**Type**: `object`
-
-## Properties
-
-- name: name (required)
-  type: string
-
-- name: headSamplingRate (optional)
-  type: number
-  description: The probability (0.0 to 1.0) of sampling a trace based on its ID. Uses deterministic MD5 hashing to ensure the same trace ID always produces the same sampling decision. Supports precision down to 0.001% (0.00001). This is implemented via head sampling, so there's minimal latency.
-
-- name: tailSampling (optional)
-  type: `TailSamplingConfig`
-
-- name: datasetId (optional)
-  type: string
-  description: Dataset ID used for naming the Iceberg table (traces_raw_{datasetId}). If not provided, traces will not be persisted to Iceberg.
-
-- name: actions (optional)
-  type: array of `TraceAction`
-  description: Actions to execute on traces. Actions process spans after sampling decisions have been made and can trigger operations like logs backfill.
-
-- name: type (required)
-  type: enum: `trace-reducer`
-  description: Reduces trace volume by sampling CompleteSpan instances based on trace ID hashing. Sampling is deterministic - the same trace ID will always produce the same sampling decision, ensuring consistent behavior across restarts and processing instances.

package/build/dist/docs-index/50ce9e81-0af6-407b-81a1-a50bcb17f301.json

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

package/build/dist/docs-index/50ce9e81-0af6-407b-81a1-a50bcb17f301.txt

@@ -1,118 +0,0 @@
----
-description: Learn how to use Grepr-processed data and your observability tools to investigate and troubleshoot incidents.
----
-
-import { Callout } from 'nextra/components'
-import { HiddenFAQ } from '@/components/HiddenFAQ'
-
-# Tutorial: Troubleshoot incidents with Grepr-processed data and your observability tool
-
-This tutorial describes how to use your observability tools to examine Grepr-processed log data, providing a powerful tool for investigating and troubleshooting issues in your infrastructure or applications.
-
-This tutorial describes using the Datadog UI to work with log data, but you can follow the same steps with any Grepr-supported observability tool. For the complete list of supported observability vendors, see [Supported integrations](/integrations/support-matrix).
-
-## Requirements
-
-To use the example in this tutorial, you must first complete the [Build your first Grepr pipeline](/tutorials/first-pipeline) tutorial, which creates the processed logs used by this tutorial.
-
-## Troubleshooting Example
-
-Suppose you need to find the root cause of a production incident. As part of your investigation, you need to view the raw log messages that Grepr aggregated into a summary message. To find the raw log messages, you can use the following steps:
-
-1. In the Datadog Log Explorer, open one of the summary messages. These are messages that start with `Repeats Nx in the past...`. Grepr replaces parameters that change between aggregated messages with a placeholder, such as `<number>`, `<timestamp>`, or `<any>`.
-
-   ![Summary message view in the Datadog Log Explorer.](/images/tutorials/troubleshooting/datadog-log-details.png)
-
-   In this example message, Grepr has identified a `timestamp` parameter and a `number` parameter that change between log messages. You can also see some Grepr-specific fields in the details, including:
-
-   - `firstTimestamp` and `lastTimestamp` are the timestamps of the first and last log message that Grepr aggregated into this summary message.
-   - `receivedTimestamp` is the timestamp when Grepr created this summary message.
-   - `patternId` is the identifier of the pattern matched by messages in this summary.
-   - `rawLogsUrl` is a URL that you can click on to see the raw log messages from the Grepr data lake that Grepr aggregated into this summary message.
-   - `repeatCount` is the number of log messages that Grepr aggregated into this summary message.
-
-1. To find the other messages that belong to this summary's pattern, hover over `patternId` and click **Filter by `@grepr.patternId:<pattern-id>`**, where `<pattern-id>` is the unique pattern identifier of the aggregated messages.
-
-   ![Filter messages in the Datadog Log Explorer detail view.](/images/tutorials/troubleshooting/datadog-log-filter.png)
-
-   This selection filters the logs to display only log messages with the same pattern as the selected message.
-
-    ![View of messages filtered by pattern in the Datadog Log Explorer.](/images/tutorials/troubleshooting/datadog-log-filtered.png)
-
-   <Callout>
-     You might see multiple summary messages with the same pattern ID. This is expected behavior and indicates that Grepr is actively aggregating these messages. For example:
-
-      - Frequent pattern: The pattern ID might be reused over long periods if the same pattern occurs frequently in your logs, resulting in multiple summary messages for the same pattern ID.
-      - Late-arriving data: If a message arrives after a summary message is created, Grepr creates a new summary message to include the late-arriving message, ensuring you receive the late-arriving data correctly.
-    </Callout>
-
-1. Reopen the summary message and click the URL in the **rawLogsUrl** field.
-
-   ![Raw log URL in the Datadog Log Explorer summary view.](/images/tutorials/troubleshooting/datadog-log-url.png)
-
-   The Grepr Data Explorer opens and displays the results of a search for the raw messages belonging to the same hosts, service, and time period as the summarized messages, highlighting all the messages with the same pattern ID.
-
-   ![Raw log view in the Grepr Data Explorer.](/images/tutorials/troubleshooting/grepr-raw-logs.png)
-
-1. To open a side panel displaying the details of a message, click one of the messages.
-
-   ![Log message detail in the Grepr Data Explorer.](/images/tutorials/troubleshooting/grepr-raw-log-details.png)
-
-1. To load all these raw log messages to Datadog so that you can use the Datadog UI to search and analyze them, expand the menu next to **Search** in the top right of the Data Explorer and select **Backfill**.
-
-   ![Selecting backfill from the Search menu.](/images/tutorials/troubleshooting/grepr-backfill.png)
-
-   Clicking **Backfill** starts a Grepr backfill job that loads the raw logs into Datadog. You can see the status of the job by clicking **Jobs** in the top bar of the Grepr Data Explorer.
-
-   ![Viewing the status of a backfill job in the Grepr Data Explorer.](/images/tutorials/troubleshooting/grepr-backfill-job.png)
-
-1. To view the backfilled messages in Datadog after the job completes, select the job in the **Jobs** menu. Selecting the job takes you to the Datadog Log Explorer, where you can view the backfilled messages. Because Datadog needs to index the new messages, there might be a short delay before they appear in the Datadog UI.
-
-   ![Datadog backfilled logs](/images/tutorials/troubleshooting/datadog-backfilled-logs.png)
-
-   Grepr automatically deduplicates messages when you run a backfill to prevent multiple copies of log messages if you backfill logs across multiple searches.
-
-   You can now use the Datadog Log Explorer to search and analyze the backfilled messages.
-
-<HiddenFAQ faqs={[
-  {
-    q: "How do I investigate production incidents with Grepr?",
-    a: "Use Grepr-processed data along with your observability platform to investigate incidents. When you find an aggregated log message in your observability tool, click on it to see Grepr metadata including the pattern ID, repeat count, and timestamps. Use this information to trace back to raw logs and perform root cause analysis."
-  },
-  {
-    q: "What are summary messages in Grepr logs?",
-    a: "Summary messages are aggregated log entries created by Grepr's Log Reducer. They start with 'Repeats Nx in the past...' and contain placeholders for varying fields (like <number>, <timestamp>, <any>). They represent multiple identical log patterns aggregated into a single message for volume reduction."
-  },
-  {
-    q: "What is the patternId field in Grepr logs?",
-    a: "The patternId is a unique identifier for the pattern of aggregated log messages. It allows you to find other log messages belonging to the same pattern in your observability platform. Filter logs by patternId to see all messages that follow the same pattern."
-  },
-  {
-    q: "How do I find all raw logs from an aggregated message?",
-    a: "Open the aggregated message in your observability platform and look for the rawLogsUrl field. Click this URL to open the Grepr Data Explorer, which displays all raw messages from the data lake that belong to the same pattern, host, service, and time period."
-  },
-  {
-    q: "What information does the Grepr Data Explorer show?",
-    a: "The Grepr Data Explorer displays raw log messages from the data lake with the same pattern ID as your selected aggregated message. It shows the actual unprocessed logs that were aggregated, allowing you to see the original data for detailed analysis."
-  },
-  {
-    q: "What is the backfill feature and when should I use it?",
-    a: "Backfill loads raw logs from the Grepr data lake into your observability platform for analysis. Use backfill when you need to perform detailed investigation of raw logs, run complex queries, or share historical data with your team in your observability platform."
-  },
-  {
-    q: "How do I start a backfill job?",
-    a: "In the Grepr Data Explorer, expand the menu next to 'Search' in the top right and select 'Backfill'. Grepr creates a backfill job that loads the raw logs into your observability platform. Monitor the job status in the Jobs menu."
-  },
-  {
-    q: "Does Grepr prevent duplicate logs when backfilling?",
-    a: "Yes. Grepr automatically deduplicates messages when you run a backfill to prevent multiple copies of the same log message if you backfill logs across multiple searches or time periods."
-  },
-  {
-    q: "How long does it take for backfilled logs to appear in my observability platform?",
-    a: "After a backfill job completes, there may be a short delay before backfilled logs appear in your observability platform because the platform needs to index the new messages. The time depends on your observability platform and the volume of logs being backfilled."
-  },
-  {
-    q: "What should I do if I see multiple summary messages with the same patternId?",
-    a: "Multiple summary messages with the same pattern ID is expected behavior. This indicates that Grepr is actively aggregating messages. It can happen when a pattern occurs frequently over long periods, or when late-arriving data triggers creation of a new summary message to include the delayed data."
-  }
-]} />

package/build/dist/docs-index/50f2cf09-68be-4c59-a02a-9acd41d438d6.json

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

package/build/dist/docs-index/50f2cf09-68be-4c59-a02a-9acd41d438d6.txt

@@ -1,26 +0,0 @@
-# updateUserOrgRoles
-
-**PUT** `/v1/users/{id}/orgRoles`
-
-**Operation ID**: `updateUserOrgRoles`
-**Summary**: No summary provided.
-## Tags
-- Users
-## Parameters
-
-- **id** (required) - path
-  - Type: string
-
-## Request Body
-
-**Content-Type**: `application/json`
-
-**Schema**: `RoleIds`
-
-## Responses
-
-### default
-
-default response
-
-- **Content-Type**: `application/json` / array of `Role`

package/build/dist/docs-index/522741fb-758f-46b1-9c46-8789e2ac0ce1.json

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

package/build/dist/docs-index/522741fb-758f-46b1-9c46-8789e2ac0ce1.txt

@@ -1,14 +0,0 @@
-# SignupRequest
-
-**Type**: `object`
-
-## Properties
-
-- name: orgName (required)
-  type: string
-
-- name: user (required)
-  type: `UserInfo`
-
-- name: reCaptchaToken (required)
-  type: string

package/build/dist/docs-index/52b39a00-db49-41de-890b-3c3e181191dc.json

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

package/build/dist/docs-index/52b39a00-db49-41de-890b-3c3e181191dc.txt

@@ -1,111 +0,0 @@
----
-description: Query log data using New Relic's Lucene-based syntax for text searches, field filtering, and logical operations with attributes and tags.
----
-
-import { HiddenFAQ } from '@/components/HiddenFAQ'
-
-# Search logs using a New Relic Lucene-like syntax
-
-New Relic's log query language is based on [Lucene](https://lucene.apache.org/core/) syntax, designed to enable fast, flexible search of log data. Grepr supports a log query syntax similar to a subset of the New Relic Lucene query language. This guide outlines the key differences between Grepr's implementation and the complete New Relic Lucene syntax.
-
-For the full New Relic query language, refer to the [New Relic documentation](https://docs.newrelic.com/docs/logs/ui-data/query-syntax-logs/).
-
-## Supported behavior
-
-Grepr supports a simplified form of text and field-based search:
-
-- **Text search (default field)**: Simple unqualified text searches (e.g., `error`) are matched only against the `message` field.
-
-- **Field-based search**: Grepr allows searching specific fields using `field:value` syntax. By default, these will search in attributes only, unless the field name starts with `tags.`.
-
-- **Logical operators**: Boolean operators `AND` and `OR` can be used to combine multiple conditions with `-` to negate conditions. For example,
-
-  ```bash
-  error AND warning           # Both "error" and "warning" must be present in message
-  error OR warning            # Either "error" or "warning" must be present in message
-  status:500 AND error        # Status code is 500 and message contains "error"
-  -req.status:200 AND error   # req.status is not 200 and message contains "error"
-  ```
-
-- **Existence operators**: The `has:` and `missing:` operators check for the presence or absence of field keys:
-
-  ```bash
-  has:field          # field exists
-  missing:field      # field does not exist
-  ```
-
-- **Negation operators**: The `-` prefix can be used to negate queries:
-
-  ```bash
-  -field:value        # Field does not equal value
-  -error              # Message does not contain "error"
-  ```
-
-- **Numeric comparisons**: Comparison operators such as `>`, `<`, `>=`, `<=` are supported on numerical fields:
-
-  ```bash
-  field:>30                     # Field value greater than 30
-  field:<10                     # Field value less than 10
-  field:>=30.0                  # Field value greater than or equal to 30.0
-  field:<=-10                   # Field value less than or equal to -10
-  ```
-
-  Refer to the [The Grepr processing and data models](/grepr-platform/grepr-model) for more about how attributes and tags are handled.
-
-- **Range searches**: Use syntax like `field:[value1 TO value2]` to search for values in ranges:
-
-  ```bash
-  field:[10 TO 20]              # Field value between 10 and 20 inclusive
-  field:{10 TO 20}              # Field value between 10 and 20 exclusive
-  field:[* TO 100]              # Field value less than or equal to 100
-  ```
-
-## Limitations
-
-Grepr **does not support** the following features of the New Relic Lucene language:
-
-- **Proximity and fuzzy searches**: Queries like `"error crash"~3` or `hello~2` are not supported.
-
-<HiddenFAQ faqs={[
-  {
-    q: "How does Grepr's Lucene syntax differ from New Relic's?",
-    a: "Grepr supports a simplified subset of New Relic's Lucene-based syntax, focusing on essential search capabilities. The core differences include: text search defaults to the message field, field-based searches use field:value syntax for attributes or tags.field:value for tags, and some advanced features like proximity and fuzzy searches are not supported."
-  },
-  {
-    q: "What is the default search behavior for unqualified text?",
-    a: "Unqualified text searches like 'error' are matched only against the message field. This is different from some Lucene implementations that search all fields. If you want to search specific attributes or tags, use explicit field:value syntax."
-  },
-  {
-    q: "How do I search attributes versus tags in Lucene syntax?",
-    a: "Both attributes and tags are searched using field:value syntax. By default, field-based searches look in attributes first. To specifically search a tag, prefix the field name with 'tags.' (e.g., tags.service:web-app). To explicitly search an attribute, use the attribute name directly (e.g., req.status:200)."
-  },
-  {
-    q: "What logical operators are supported in New Relic Lucene queries?",
-    a: "Grepr supports AND and OR operators to combine conditions. You can negate conditions using the minus prefix (-). For example, 'error AND warning' requires both terms, 'error OR warning' requires either term, and '-req.status:200 AND error' excludes logs with status 200 that also contain 'error'."
-  },
-  {
-    q: "How do I check if a field exists or is missing?",
-    a: "Use the has: and missing: operators to check for field existence. The query 'has:field' matches logs where the field key exists, regardless of value. The query 'missing:field' matches logs where the field is not present."
-  },
-  {
-    q: "Can I perform numeric comparisons in New Relic Lucene queries?",
-    a: "Yes, Grepr supports comparison operators >, <, >=, and <= on numeric fields. For example, field:>30 matches logs where the field value is greater than 30. You can use field:<10 for less than or field:>=30.0 for greater than or equal to comparisons."
-  },
-  {
-    q: "What range query syntax does Grepr support?",
-    a: "Grepr supports range queries using [value1 TO value2] for inclusive ranges and {value1 TO value2} for exclusive ranges. You can also use open-ended ranges like field:[* TO 100] for values up to 100 or field:[100 TO *] for values of 100 and above."
-  },
-  {
-    q: "How do I negate a condition in Lucene queries?",
-    a: "Use the minus prefix (-) to negate conditions. For example, -field:value excludes logs where field equals value, and -error excludes logs containing 'error' in the message field. You can negate any condition including field existence (e.g., -has:field)."
-  },
-  {
-    q: "What advanced Lucene features are NOT supported?",
-    a: "Grepr does not support proximity searches like \"error crash\"~3 or fuzzy matching like hello~2. These features are not part of the simplified Lucene-like syntax implementation. Use alternative approaches like multiple separate conditions or phrase searches instead."
-  },
-  {
-    q: "Can I use wildcards with tags in Lucene syntax?",
-    a: "Yes, wildcards are supported with both attributes and tags. For example, tags.service:web-* matches any tag with key 'service' starting with 'web', and req.path:/api/* matches attribute paths starting with '/api/'. Use * for zero or more characters."
-  }
-]} />
-

package/build/dist/docs-index/52f53672-3a64-4b14-ad18-f19017580632.json

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

package/build/dist/docs-index/52f53672-3a64-4b14-ad18-f19017580632.txt

@@ -1,37 +0,0 @@
-# Update a template
-
-**PUT** `/v1/templates/{id}`
-
-**Operation ID**: `updateTemplate`
-**Summary**: Update a template
-Updates a template by ID. The previous version is tombstoned.
-
-## Tags
-- Templates
-## Parameters
-
-- **id** (required) - path
-  - Type: string
-
-## Request Body
-
-The updated template.
-
-**Content-Type**: `application/json`
-
-**Schema**: `Template`
-
-## Responses
-
-### 200
-
-Template updated successfully
-
-- **Content-Type**: `application/json` / `Template`
-### 400
-
-Template not found
-
-### 401
-
-Unauthorized

package/build/dist/docs-index/544bcaea-aa93-465a-8602-eed23b215d29.json

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

package/build/dist/docs-index/544bcaea-aa93-465a-8602-eed23b215d29.txt

@@ -1,32 +0,0 @@
-# Create a Splunk integration
-
-**POST** `/v1/integrations/splunk`
-
-**Operation ID**: `create_5`
-**Summary**: Create a Splunk integration
-Creates an integration to connect to Splunk.
-
-## Tags
-- Splunk Integration
-## Request Body
-
-**Content-Type**: `application/json`
-
-**Schema**: `WriteSplunk`
-
-## Responses
-
-### 200
-
-Integration created successfully
-
-- **Content-Type**: `application/json` / `ReadSplunk`
-### 401
-
-Unauthorized
-
-### 409
-
-Integration already exists.
-
-- **Content-Type**: `application/json` / `ReadSplunk`

package/build/dist/docs-index/55382716-13ce-4376-aea1-1808274c5565.json

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

package/build/dist/docs-index/55382716-13ce-4376-aea1-1808274c5565.txt

@@ -1,15 +0,0 @@
-# SamplingAttributesMergeStrategy
-
-**Type**: `object`
-
-## Properties
-
-- name: unique (optional)
-  type: boolean
-
-- name: limit (optional)
-  type: integer
-
-- name: type (required)
-  type: enum: `sample`
-  description: SamplingAttributesMergeStrategy: Collects up to 'limit' samples. The 'unique' flag determines if samples must be distinct.

package/build/dist/docs-index/55a6c096-d2b7-4a4a-98ce-c6e880afc7e7.json

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

package/build/dist/docs-index/55a6c096-d2b7-4a4a-98ce-c6e880afc7e7.txt

@@ -1,39 +0,0 @@
-# LogReducerTemplateInput
-
-Schema for the log reducer job graph.
-
-**Type**: `object`
-
-## Properties
-
-- name: sources (required)
-  type: array of `Operation`
-  description: A list of data sources, each conforming to one of the defined source types.
-
-- name: sinks (required)
-  type: array of `TemplateLogSink`
-  description: A list of template log sinks, each specific to a vendor with optional filter configuration.
-
-- name: filters (required)
-  type: `LogReducerFilters`
-
-- name: exceptions (required)
-  type: array of `TemplateException`
-  description: A list of template-specific exceptions to apply in log reducer.
-
-- name: datasetId (required)
-  type: string
-  description: The unique identifier for the dataset.
-
-- name: parsers (required)
-  type: array of `Operation`
-  description: A list of parsers to be applied to the data.
-
-- name: reducer (required)
-  type: `LogReducer`
-
-- name: sampler (optional)
-  type: `LogsEventSampler`
-
-- name: sqlOperations (optional)
-  type: `SqlOperations`

package/build/dist/docs-index/5728eb9c-f366-4230-a28e-376561393dc9.json

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

package/build/dist/docs-index/5728eb9c-f366-4230-a28e-376561393dc9.txt

@@ -1,15 +0,0 @@
-# ActionRule
-
-Base class of all Action Rules
-
-**Type**: `object`
-
-## One Of
-
-This schema accepts one of the following types:
-
-### Option 1
-`EventActionRule`
-
-### Option 2
-`JobActionRule`

package/build/dist/docs-index/578aa0d7-6408-41c1-b241-062dd368c7ae.json

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

package/build/dist/docs-index/578aa0d7-6408-41c1-b241-062dd368c7ae.txt

@@ -1,34 +0,0 @@
-# Creates or updates a Splunk integration auth token
-
-**PUT** `/v1/integrations/splunk/{id}/auth-token`
-
-**Operation ID**: `upsertAuthToken`
-**Summary**: Creates or updates a Splunk integration auth token
-Creates an HEC API auth token for a Splunk 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.  Ingestion supports the previous and the updated key for up to 24 hours of  a key update. Make sure to change the key used by the agents to send data within  24 hours of an update for a seamless transition
-
-## Tags
-- Splunk Integration
-## Parameters
-
-- **id** (required) - path
-  - Type: string
-
-## Request Body
-
-**Content-Type**: `application/json`
-
-**Schema**: `SecretApi`
-
-## Responses
-
-### 204
-
-HEC API Auth token upserted successfully.
-
-### 401
-
-Unauthorized
-
-### 404
-
-Integration not found.

package/build/dist/docs-index/57ab65fb-2837-4de0-be4c-d838e233e0b1.json

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

package/build/dist/docs-index/57ab65fb-2837-4de0-be4c-d838e233e0b1.txt

@@ -1,20 +0,0 @@
-# List all valid NewRelic sites
-
-**GET** `/v1/integrations/newrelic/sites`
-
-**Operation ID**: `listValidNewRelicSites`
-**Summary**: List all valid NewRelic sites
-Get all valid NewRelic sites for your organization.
-
-## Tags
-- New Relic Integration
-## Responses
-
-### 200
-
-Sites retrieved successfully
-
-- **Content-Type**: `application/json` / array of string
-### 401
-
-Unauthorized

package/build/dist/docs-index/5820530a-2cd4-49d1-9fa3-fdd2b02c263f.json

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