@grepr/cli 1.11.5-c840124 → 1.11.5-dbd05e7

package/build/dist/docs-index/da3cf630-5eae-4cc7-b454-ac83a7862ffd.txt

@@ -1,111 +0,0 @@
-Process data in Grepr pipelines using built-in tools for parsing, filtering, enrichment, and transformation of log events.
-
-# Transform data in a Grepr pipeline
-
-A Grepr transform is a processing step that modifies, enriches, or restructures data as it flows through a pipeline. As records move through a pipeline, transforms allow you to parse structured and semi-structured data, filter records, and use a familiar SQL interface to perform more complex transformation of records as they move through a pipeline. Transforms are configured as pipeline steps that process data sequentially. Each transform receives input data, applies its logic, and passes the result to the next step in the pipeline.
-
-Most transforms are available in the Grepr pipelines UI. Some transforms are available only in the Grepr REST API or provide more capabilities when used with the API, such as [filters](#filter) and [branching the processing of records](#message-routing) based on query matches.
-
-The following sections describe the transforms available in Grepr pipelines.
-
-## Transform semi-structured records with the Grok parser \[#grok-parser]
-
-The Grok transform parses unstructured text using pattern matching with regular expressions and named capture groups. Use this transform to extract fields from log lines, error messages, and other text-based data where you need to identify specific patterns and convert them to structured fields.
-
-See [Grok parser](/transforms/grok).
-
-## Convert JSON messages into structured objects \[#json-parser]
-
-The JSON parser transforms JSON strings into structured JSON objects. This transform handles nested objects, arrays, and various data types, making it useful for processing API responses, configuration data, and structured log entries.
-
-See [Transform JSON strings into JSON objects](/transforms/json-parsing).
-
-## Restructure JSON objects with a remapper \[#remapper]
-
-The remapper transform moves or copies attributes to top-level fields or to tags in a JSON object. You can also use rename rules to move attribute values from one path to another within the same event. In the pipelines UI, a remapper with customizable default attributes is automatically added to a pipeline.
-
-See [Remap JSON attribute fields to top-level log event fields](/transforms/remapper).
-
-## Transform records with SQL \[#sql-transform]
-
-The SQL transform allows you to use ANSI standard SQL queries to filter, transform, and enrich data records. The SQL transform provides a familiar SQL interface to perform a number of data processing and transformation tasks.
-
-You can use the SQL transform in the Grepr UI or REST API. In the UI, the SQL transform is available when you configure filters.
-
-To learn about using the SQL transform in the Grepr API, see the [SQL Operation specification](/apis/api-spec#schema/SQLOperation).
-
-For a complete reference and examples, see [Transform events with SQL](/transforms/sql-transform).
-
-## Filter records based on conditions \[#filter]
-
-The Filter transform includes or excludes data records based on specified conditions. You can create filters using familiar query interfaces, such as SQL, as well as Datadog and New Relic log query-like syntaxes.
-
-In the Grepr pipelines UI, filters are located in predefined locations in the pipeline. To learn how to configure filters, see [Filter events in a Grepr pipeline](/transforms/filter-events).
-
-To have more flexibility for where filters are included in a pipeline, use the REST API. See [LogsFilter](/apis/api-spec#schema/LogsFilter).
-
-## Reduce log volumes with dynamic aggregation \[#reducer]
-
-The Grepr log reducer uses clustering algorithms to identify patterns in your log data and aggregate similar log messages. The output of this aggregation includes summaries and samples of similar messages. The log reducer is a core step in a log reduction pipeline, where it runs before processed log events are sent to your configured sinks. By sending summaries of similar messages rather than multiple events with redundant information, Grepr significantly reduces the volume of shipped logs and your observability costs. The log reduction pipeline also persists the complete set of raw logs to a low-cost data lake, enabling you to analyze and troubleshoot issues when necessary.
-
-To learn more about how Grepr reduces log volumes with dynamic aggregation, see [Reduce noise and improve the usability of your logs with the log reducer](/transforms/reducer).
-
-To learn how to create a log reduction pipeline, see [Tutorial: Build your first Grepr pipeline](/tutorials/first-pipeline).
-
-To learn how to use the resulting summarized log events in your observability platform along with raw logs stored in Grepr, see [Troubleshoot incidents with Grepr-processed data and your observability tool](/tutorials/troubleshooting-example).
-
-## Transform and enrich log messages with the REST API \[#log-transform-action]
-
-You can use the LogTransformAction in the REST API to specify actions that transform log messages, such as adding or removing attributes and tags. See [LogTransformAction](/apis/api-spec#schema/LogTransformAction).
-
-## Route the processing of messages based on query matches \[#message-routing]
-
-You can route log messages to be processed by different pipelines based on query matches. Because the pipelines UI doesn't support branching, Grepr recommends creating multiple pipelines that ingest data using the same source, and then use filters to route data to the correct pipeline.
-
-You can also use the REST API to create more complex pipeline configurations. See [LogsBranch](/apis/api-spec#schema/LogsBranch).
-
-## Frequently Asked Questions
-
-### What transforms are available in Grepr pipelines?
-
-Grepr provides several transform types: Grok parser for parsing unstructured text with pattern matching, JSON parser for converting JSON strings into structured objects, remapper for restructuring JSON fields and attributes, SQL transform for complex filtering and enrichment using SQL queries, and Filter transform for conditional record processing. Most transforms are available in the UI, while some advanced options are available via REST API.
-
-### When should I use the Grok parser transform?
-
-Use the Grok parser when you need to extract structured data from unstructured text logs. It's ideal for parsing error messages, application logs, system logs, and other text-based data where you need to identify specific patterns and convert them into structured fields using regular expressions and named capture groups.
-
-### When should I use the JSON parser transform?
-
-Use the JSON parser when your log messages contain JSON strings that need to be converted into structured JSON objects. This is useful for processing API responses, configuration data, and structured log entries. The JSON parser handles nested objects, arrays, and various data types automatically.
-
-### What is the remapper transform and when is it used?
-
-The remapper transform moves or copies attributes to top-level fields or to tags in a JSON object. It's useful for standardizing log event structure by moving well-known fields like message, severity, and host from nested attributes to top-level fields. You can configure whether the source attribute is preserved or removed after remapping. The remapper also supports rename rules for moving attribute values from one path to another. The remapper is automatically added to pipelines in the UI with customizable default attributes.
-
-### When should I use the SQL transform?
-
-Use the SQL transform when you need complex filtering, transformation, or enrichment of log records. SQL provides a familiar interface for advanced operations like conditional logic, string manipulation, aggregations, and joining data. It's available in the UI for filters and via REST API for more flexibility.
-
-### Can I combine multiple transforms in a pipeline?
-
-Yes, transforms are configured as sequential pipeline steps. Each transform receives input from the previous step, applies its logic, and passes the result to the next step. This allows you to create complex data processing workflows by combining parsing (Grok), restructuring (remapper), and filtering/enrichment (SQL) transforms.
-
-### What is the Filter transform used for?
-
-The Filter transform includes or excludes data records based on specified conditions. You can use filters with SQL, Datadog, and New Relic-like query syntaxes. In the UI, filters are located in predefined pipeline positions, while the REST API provides more flexibility for filter placement.
-
-### Can I use the REST API for more advanced transform options?
-
-Yes, the REST API provides access to advanced transform options not available in the UI. For example, you can use LogTransformAction to add or remove attributes and tags, LogsBranch for complex message routing based on query matches, and more flexible filter placement. See the API specification for complete details on transform capabilities.
-
-### How do I choose between Grok and SQL transforms?
-
-Use Grok when you need pattern-based parsing of unstructured text to extract specific fields. Use SQL when you need complex conditional logic, calculations, string transformations, or filtering. Grok is specialized for text parsing, while SQL is more general-purpose for data manipulation and enrichment.
-
-### How does Grepr reduce log volumes and observability costs?
-
-Grepr uses clustering algorithms to identify patterns in log data and aggregates similar log messages. Instead of sending multiple redundant log events, Grepr sends summaries and samples of similar messages to your observability platform. This significantly reduces the volume of shipped logs while retaining the ability to analyze and troubleshoot issues. Raw logs are retained in a low-cost data lake for future reference.
-
-### What happens if a transform fails on a record?
-
-Transform behavior depends on the specific transform type and configuration. Parsing errors (like Grok or JSON parsing) typically skip records or add error attributes depending on your configuration. SQL transforms filter out records that don't match conditions. Review transform-specific documentation for error handling details.

package/build/dist/docs-index/e4f876b8-9fba-4fb5-b18a-e3802c713cf8.txt

@@ -1,91 +0,0 @@
-Reduce log volume using Grepr's intelligent pattern detection, clustering, and sampling for cost-effective observability at scale.
-
-# Reduce noise and improve the usability of your logs with the log reducer
-
-Grepr's log reducer uses clustering algorithms and real-time pattern discovery to identify repeated messages in high-volume log streams and aggregate those messages into summarized events. These summarized events reduce the volume of redundant, low-value log events while retaining full context for less common and often higher-value events.
-
-The log reducer is a core step in a Grepr log reduction pipeline, where it runs after log events have been processed by the parsing, filtering, and transformation steps and before they are sent to your configured sinks. By sending summarized events rather than the full set of logs to your observability vendor, Grepr significantly reduces the volume of shipped logs and your observability costs.
-
-Messages that do not match any pattern pass through unmodified. You can also configure *exceptions* for specific messages or patterns that must bypass the reducer and be forwarded unmodified to your observability platform. See [Bypass aggregation of important messages with exceptions](/transforms/reducer/exceptions).
-
-Log reduction pipelines also persist your unaggregated raw logs in a Grepr data lake, ensuring you maintain full access to your log data while dramatically reducing storage and processing costs. The data lake allows you to query and analyze your raw logs, for example, when an incident occurs or alerts are raised that require access to the full set of logs for troubleshooting or debugging. See [The Grepr data lake](/grepr-platform/data-lake).
-
-When you create a log reduction pipeline, a reducer is added with default settings suitable for many log processing flows. When needed, you can change the configuration settings to meet your requirements. You can modify reducer settings in the UI or through the Grepr REST API. To configure the reducer in the UI, see [Configure the log reducer in a Grepr pipeline](/transforms/reducer/configuration). For API documentation, see the [LogReducer API specification](/apis/api-spec#schema/LogReducer).
-
-## How log reduction works
-
-The log reducer divides incoming log events into fixed-duration, tumbling windows and produces summaries separately for each window. The reducer creates the summarized events through a multi-step process, including transformations to:
-
-* Normalize fields to help group values that represent the same entity but might differ slightly in format or content.
-* Structure messages to optimize grouping.
-* Group messages using similarity metrics.
-* Output a configurable number of raw sample messages per pattern before summarizing additional matches.
-* Create and output a concise summary of aggregated messages that match an identified pattern along with a configurable sample of raw messages. The summarized events include metadata that provides important context about the aggregated messages and preserves important fields. See [Summary message metadata](#summary-metadata).
-* Add a tag to all output events to indicate whether the type of message it contains is a sample, summary, passthrough, or exception. See [Message types](#message-types).
-
-If the reducer cannot find a matching pattern for a message, the message passes through unmodified. Reasons that the reducer cannot find a pattern include:
-
-* The clustering process is unable to extract patterns from messages.
-* The log message field is empty or null.
-* The message matches a configured exception rule that prevents it from being reduced.
-
-To learn more about the transformations the reducer applies to messages and how to modify its default behavior, see [Configure the log reducer in a Grepr pipeline](/transforms/reducer/configuration).
-
-## Example: Summarizing repeated and low-value messages
-
-The following image shows an example of a message that's logged repeatedly but provides little to no value because the service it reports on is intentionally left non-running.
-
-The log reducer identifies the pattern in this message and summarizes it into a single message indicating how many times the original message was logged. The summary also includes other metadata about the pattern and the messages that matched it. Important fields from the original messages are included in the summary. The reducer then outputs this summarized message and a sample of the raw messages.
-
-Viewing the summary message shows the added metadata, such as the number of times the message was logged and the start and end times of the messages that were summarized.
-
-## Summary message metadata \[#summary-metadata]
-
-When the reducer generates a summary message for a pattern, it adds the following metadata fields to the output event that provide important context about the aggregated messages. This metadata allows you to understand the pattern's characteristics and the messages it represents, and to link back to the original raw messages if needed.
-
-| Field | Description |
-| --- | --- |
-| `grepr.patternId` | Unique identifier for the pattern. Use this to find related messages. |
-| `grepr.rawLogsUrl` | A direct link to view all raw messages for this pattern in the Grepr data lake. |
-| `grepr.repeatCount` | The number of input messages included in the summary. This can be useful for metrics and [rewriting queries](/transforms/reducer/exceptions#rewrite-queries). |
-| `grepr.receivedTimestamp` | Milliseconds since the Unix epoch when the summary was emitted by Grepr. |
-| `grepr.firstTimeTimestamp` | Milliseconds since the Unix epoch of the first message in this summary. |
-| `grepr.lastTimeTimestamp` | Milliseconds since the Unix epoch of the last message in this summary. |
-
-## Message types \[#message-types]
-
-After processing, each record is assigned a message type, and the `grepr.messagetype` tag is added to output events with one of the following values:
-
-| Value | Description |
-| --- | --- |
-| `sample` | The message is a sample of the original log messages that matched a specific pattern. Sample messages are sent through unmodified until the deduplication threshold is reached. |
-| `summary` | The message summarizes multiple source log messages that matched a specific pattern. Summary messages are generated at the end of each aggregation window for patterns that have exceeded the deduplication threshold. |
-| `passthrough` | The message did not match any existing patterns and was sent through unmodified. |
-| `exception` | The message matched an exception rule and was sent through unmodified. |
-
-## Next steps
-
-* To modify the reducer's default settings to provide further control over how messages are processed, see [Configure the log reducer in a Grepr pipeline](/transforms/reducer/configuration).
-* If you have important messages that must be forwarded to your observability platform without aggregation, configure *exceptions* to ensure these messages skip the reducer step and are forwarded unchanged. See [Bypass aggregation of important messages with exceptions](/transforms/reducer/exceptions).
-
-## Frequently Asked Questions
-
-### What is log reduction in Grepr?
-
-Log reduction is Grepr's process of identifying patterns in high-volume log streams and aggregating similar messages into concise summaries. This reduces the volume of logs shipped to your observability vendor while preserving access to the underlying raw messages through the Grepr data lake.
-
-### How does Grepr identify log patterns?
-
-The reducer applies a multi-step process to each log message. It normalizes variable values such as timestamps, IDs, and IP addresses, structures the message to optimize grouping, and groups messages into patterns using similarity metrics. For each pattern, the reducer forwards a configurable number of raw sample messages before it summarizes additional matches into a single summary event.
-
-### What does the grepr.messagetype tag indicate?
-
-The grepr.messagetype tag records how a message was processed. The value 'sample' means the message was forwarded before the deduplication threshold was reached, 'summary' means the message is a summary of aggregated messages, 'passthrough' means the message did not match any pattern, and 'exception' means the message matched a configured exception.
-
-### What information does a summary message include?
-
-Each summary message includes grepr.patternId for pattern identification, grepr.repeatCount for the count of input messages aggregated, grepr.firstTimeTimestamp and grepr.lastTimeTimestamp for the first and last message timestamps in the summary, grepr.receivedTimestamp for when the summary was emitted, and grepr.rawLogsUrl for a direct link to the raw messages in the Grepr data lake.
-
-### Why might a message pass through without being aggregated?
-
-A message passes through unmodified when the clustering process can't find a pattern that matches it, when the log message field is empty or null, or when the message matches a configured exception rule that prevents aggregation.

package/build/dist/docs-index/ed02cf81-6bfc-43fe-882b-5fcab9c4a6c3.txt

@@ -1,25 +0,0 @@
-# List an agent's subscriptions
-
-**GET** `/v1/agents/{id}/subscriptions`
-
-**Operation ID**: `subscriptions`
-**Summary**: List an agent's subscriptions
-Returns the pipeline ids the agent is subscribed to.
-
-## Tags
-- Agents
-## Parameters
-
-- **id** (required) - path
-  - Type: string
-
-## Responses
-
-### 200
-
-Subscriptions retrieved successfully
-
-- **Content-Type**: `application/json` / array of string
-### 401
-
-Unauthorized

package/build/dist/docs-index/faaf380c-f44b-4d74-9605-d603c38e45c9.txt

@@ -1,240 +0,0 @@
-Configure the Grepr log reducer to reduce the volume of logs forwarded to your observability vendor while preserving access to your raw logs.
-
-# Configure the log reducer in a Grepr pipeline
-
-This page describes the transformations the log reducer applies to incoming log messages and how to configure them to meet your requirements. When you create log reduction pipelines, Grepr adds a log reducer with default settings that control how log messages are aggregated, grouped, tokenized, and summarized. These settings are suitable for many log-processing workloads, but you can modify these settings to meet your requirements through the Grepr UI, the REST API, or the Grepr CLI. This page describes each setting and how to configure the setting in the UI. For the API documentation, see the [LogReducer API specification](/apis/api-spec#schema/LogReducer). For the CLI, see [The Grepr CLI](/cli).
-
-The log reducer transforms logs into summarized events through a multi-step process. The reducer divides the incoming log stream into consecutive *aggregation windows* and produces summaries for each window separately. An aggregation window is a fixed-duration, tumbling window over which the reducer counts and aggregates the messages that match each pattern. Tumbling windows are contiguous and non-overlapping, so each log belongs to exactly one window. The aggregation window is two minutes by default.
-
-> To change the aggregation window duration, you must use the Grepr REST API. You cannot use the Grepr UI to change the window duration. Before changing this value, Grepr recommends contacting <support@grepr.ai> for guidance.
-
-The following describes the core steps in this process and includes links with details on changing the default behavior for each step:
-
-* Masking replaces dynamic values such as timestamps, IDs, and IP addresses with specific tokens. By normalizing values that represent the same entity but might differ slightly in format or content, masking prevents them from being split incorrectly in the next step. See [Enable grouping of dynamic fields by assigning common tokens](#mask-configuration).
-* Tokenizing breaks log messages into tokens based on configurable delimiters, creating a structured representation optimized for grouping. See [Configure delimiters used to split log messages](#delimiter-configuration).
-* Grouping uses similarity metrics to group messages into patterns. A configurable similarity threshold determines how closely messages must match to be considered part of the same pattern. You can use grouping to retain the values of important fields by excluding them from aggregation. See [Configure how messages are grouped](#grouping-configuration).
-* Sampling sends a configurable number of raw sample messages per pattern. This number is referred to as the *deduplication threshold* throughout this documentation. After this threshold is reached, you can configure the reducer to stop forwarding that pattern until the end of the aggregation window, or use logarithmic sampling. See [Configure a sampling strategy](#sampling-configuration).
-* Summarizing generates, at the end of each aggregation window, concise summaries of aggregated messages that matched an identified pattern. For details on the fields included in the summarized output events, see [Summary message metadata](/transforms/reducer#summary-metadata).
-
-To modify the configuration settings in the UI, on the overview page for your pipeline, click **Reducer** in the left-hand navigation menu to open the **Edit Reducer** dialog. The dialog contains a form to configure **Grouping Configuration**, **Aggregation Configuration**, **Sampling Configuration**, **Mask Configuration**, **Delimiter Configuration**, and **Attribute Configuration** values. The following sections describe these settings.
-
-## Configure how messages are grouped \[#grouping-configuration]
-
-The **Grouping Configuration** section controls how incoming messages are partitioned into independent groups before pattern detection, and the level of similarity messages must meet to be considered part of the same pattern.
-
-### Group-by values \[#group-by-configuration]
-
-To control how the reducer partitions messages, enter a comma-separated list of tag keys and attribute paths in the **Group-by values** field. Messages are aggregated separately for each unique combination of values across the listed tags and attributes, so patterns from different services, hosts, or other dimensions are never merged. For example, the value `service, host, @http.url.path` aggregates messages independently for each unique combination of `service`, `host`, and the `http.url.path` attribute.
-
-To specify attributes, prefix the attribute path with `@` and use dot notation for nested attributes. For example: `@http.url.path`. Enter tag keys using just the key name without any prefix.
-
-Use this setting to retain the values of important fields by excluding them from aggregation. For example, to retain the values of high-cardinality identifiers, such as user IDs. To prevent a field from being aggregated, parse the field into an attribute using the **JSON Parser** or **Grok Parser** steps earlier in the pipeline, then add that attribute to the **Group-by values** field. See [Transform JSON strings into JSON objects](/transforms/json-parsing) and [Parse log messages to enrich log events with the Grok parser](/transforms/grok).
-
-### Similarity threshold (%)
-
-The similarity threshold controls how close a set of tokens must be to an existing pattern for the reducer to consider the message a match for that pattern. To set this threshold, enter a whole number from 20 to 100. This value represents the percentage of tokens that must match between the incoming message and the pattern.
-
-* A higher value requires a closer match to group messages into the same pattern. Higher values produce more distinct patterns, each containing fewer of the tokens defined by [regular expression masks](#mask-configuration), and reduce volume less aggressively.
-* A lower value allows grouping messages with more variation into the same pattern. Lower values lead to greater reduction, but the resulting summary messages contain more mask-defined tokens.
-
-## Configure how messages are aggregated \[#aggregation-configuration]
-
-The **Aggregation Configuration** section controls how many raw messages are forwarded before aggregation begins for a pattern and how summary messages are formatted.
-
-### Minimum number of samples
-
-To set a *deduplication threshold* for messages, in the **Minimum number of samples** field, enter a whole number of two or greater. This value is the minimum count of messages matching a pattern that the reducer forwards as raw messages inside a single aggregation window before it begins aggregating additional matches into a summary message. Until this threshold is reached, unaggregated messages are forwarded to your sinks.
-
-Use a lower value to begin aggregation sooner and maximize volume reduction. Use a higher value when a pattern has a higher threshold for the number of duplicate messages to forward before beginning aggregation.
-
-### Add repeat count prefix to summary messages
-
-To have the reducer prepend a prefix to each summary message that indicates the number of raw messages aggregated and the duration of the aggregation period, select **Add repeat count prefix to summary messages**.
-
-Clear **Add repeat count prefix to summary messages** if your downstream system needs to parse the summary message body without changes. For example, if summary messages use JSON formatting, the leading prefix would cause a syntax error.
-
-## Configure a sampling strategy \[#sampling-configuration]
-
-The **Sampling Configuration** section controls whether and how additional raw messages are forwarded for a pattern after the minimum number of samples is reached in the current aggregation window. To configure the sampling strategy for a reducer, in the **Sampling strategy** menu, select one of the following options:
-
-### No Additional Sampling
-
-During each aggregation window, Grepr passes through a configurable number of sample messages for each pattern before beginning aggregation. After the deduplication threshold is reached for a specific pattern, Grepr stops sending messages for that pattern until the end of the aggregation window, at which point a summary is emitted. This ensures that a minimum number of raw messages always pass through unmodified. Low-frequency messages that usually contain important troubleshooting information pass through unmodified.
-
-While this default behavior maximizes reduction, the actual count of messages seen at the vendor is independent of the number of original raw messages. Instead, the count is based on the messages summarized in each aggregation window. Features in external log aggregators that depend on message counts by pattern, such as Datadog's "top patterns" capability, might not work as expected. To address this, select the following logarithmic sampling option.
-
-### Window-Based Logarithmic
-
-With logarithmic sampling, high-volume patterns that occur in the aggregation window are sampled more heavily than low-volume patterns.
-
-When you select this option, to configure the rate of additional sampling, enter a whole number of two or greater in the **Logarithm Base** field. The reducer process uses this base value to increase the sample size logarithmically. For example, if the base is set to two and the deduplication threshold is set to four, Grepr sends one additional sample message when the number of messages in the aggregation window first exceeds two raised to the power of the deduplication threshold + 1 (`2^5 or 32`). Additional samples are then sent at the 64th, 128th, 256th, and subsequent messages. This ensures that an unexpectedly large increase in messages matching a pattern still appears as an increase in message count at the vendor, but with a logarithmically smaller magnitude.
-
-## Enable grouping of dynamic fields by assigning common tokens \[#mask-configuration]
-
-The **Mask Configuration** section defines the regular expression masks that the reducer uses to replace variable parts of a log message, such as timestamps, IDs, or IP addresses, with specific tokens before the message is tokenized and grouped. Masking normalizes variable content so that messages that differ only in these values are grouped into the same pattern.
-
-The reducer ships with the following default masks. Each appears as a row in the **Mask Configuration** section and can be enabled, disabled, edited, or reset to its original pattern:
-
-| Mask | Default state | Description |
-| --- | --- | --- |
-| `timestamp` | Enabled | Matches many timestamp formats, such as `2024-04-26T15:30:45.123Z`, `26/04/2024 15:30:45`, or `15:30:45`. |
-| `ipport` | Enabled | Matches IPv4 addresses and optional ports, such as `192.168.0.1` or `192.168.0.1:8080`. |
-| `number` | Enabled | Matches integers and decimal numbers up to 100 digits. |
-| `uuid` | Enabled | Matches UUIDs, such as `123e4567-e89b-12d3-a456-426614174000`. |
-| `awsarn` | Disabled | Matches AWS ARNs. |
-| `awstoken` | Disabled | Matches AWS session tokens. |
-
-For each mask row, you can:
-
-* Select or clear the checkbox on the left to enable or disable the mask. Only enabled masks are applied to incoming messages.
-* Click **Edit** to display the regular expression for the mask and modify the pattern. The pattern field cannot be empty.
-* For default masks, click the restore icon to reset the pattern to its original value.
-* For custom masks, click the delete icon to remove the mask.
-
-### Enable grouping of non-default formats by assigning custom tokens
-
-To ensure the correct grouping of fields with formats that aren't handled by the default masks, you can create custom masks. For example, you might have a field with values that include delimiter characters, and you need to prevent the reducer from splitting the single field on those delimiters.
-
-When you add a custom mask, you must enter a name for the mask that:
-
-* Contains only lowercase alphabetic characters. Spaces, digits, and symbols are not allowed.
-* Is no more than 50 characters long.
-* Is unique across all masks in this reducer.
-
-Enter the mask in the **Regular Expression Pattern** text box. A custom mask pattern supports the following common regular expression constructs:
-
-* Literal characters and character classes, such as `[a-z]`, along with predefined classes such as `\d`, `\w`, and `\s`.
-* Quantifiers, such as `*`, `+`, `?`, and `{n,m}`.
-* Alternation with `|` and grouping with `(` and `)`.
-* Anchors and word boundaries, such as `^`, `$`, and `\b`.
-
-> Custom mask patterns do not support lookahead or lookbehind assertions or backreferences. A pattern that uses one of these constructs passes the validation in the form but prevents the reducer from processing messages. To confirm that a custom mask matches the values you expect, test the pattern against sample messages.
-
-## Configure delimiters used to split log messages \[#delimiter-configuration]
-
-The **Delimiter Configuration** section defines the characters that the reducer uses to split a log message into tokens during clustering. After masking, the reducer splits each message into tokens using these characters and then calculates similarity against known patterns. Characters that are not in the delimiter list are treated as part of a token.
-
-The default delimiter set contains common punctuation and whitespace characters: `:`, `#`, `[`, `]`, `(`, `)`, `{`, `}`, `|`, `,`, `;`, `"`, `'`, space, `\t`, `\n`, and `\r`.
-
-> The default set intentionally omits `@` and `.` so that email addresses and dotted identifiers, such as fully qualified class names, are not split across tokens.
-
-To modify the delimiter list:
-
-* To remove a delimiter, hover over its chip in the delimiter list and click the delete icon that appears.
-* To add a delimiter, enter the character in the **Add delimiter** field and click **Add** or press **Enter**. For control characters, enter the escape sequence: `\t` for tab, `\n` for newline, `\r` for carriage return, `\b` for backspace, `\f` for form feed, `\v` for vertical tab, or `\0` for null. Duplicate delimiters are rejected.
-* To restore the default delimiter set, click **Reset to Defaults**.
-
-## Configure how attributes are merged \[#attribute-configuration]
-
-To group log messages, the log reducer uses only the text in the `message` field. However, because of the possible variability of the attribute values associated with the grouped messages, the reducer provides multiple strategies to merge them.
-
-To control how the reducer combines attributes, you use the **Attribute Configuration** section to specify merge strategies for individual attribute paths and configure a default strategy that applies to any attribute path without an explicit configuration.
-
-The reducer supports the following merge strategy types:
-
-| Strategy | Behavior |
-| --- | --- |
-| **Exact Match** | If all aggregated messages have the same value for the attribute, the summary preserves that value. If they differ, the summary stores a wildcard, `*`. |
-| **Sample** | Collects up to a configured **Sample Limit** of values from the aggregated messages. When the limit is reached, additional values are dropped. |
-| **Preserve All** | Collects every distinct or repeated value from the aggregated messages, up to a configured **Preserve Limit**. When the incoming data exceeds the limit, the reducer emits the current summary and starts a new one, rather than dropping values. |
-| **Sum** | Sums numeric values across aggregated messages and stores the result as a scalar number. Non-numeric values are ignored. Collections of numbers are summed element by element. |
-| **Min** | Keeps the minimum numeric value across aggregated messages. Non-numeric values are ignored. |
-| **Max** | Keeps the maximum numeric value across aggregated messages. Non-numeric values are ignored. |
-| **Average** | Computes the arithmetic mean of numeric values across aggregated messages. Non-numeric values are ignored. |
-
-To see examples and learn more about the merge strategies, see [Merge strategy examples](/transforms/reducer/configuration/merge-strategy-examples).
-
-### Configure merge strategies
-
-To add a merge strategy, in the **Attribute merging strategies** section, click the plus (+) icon. Select a strategy from the **Strategy** menu and enter the target attribute path. If any part of the target path uses dot notation, enter the target path using dot notation, such as `http.response.bytes`, or a JSON array, such as `["http", "response", "bytes"]`. Each entry must have a non-empty path, and each path must be unique within the list.
-
-When you select **Sample** or **Preserve All**, you can configure the following settings:
-
-* **Sample Limit** or **Preserve Limit**: A whole number that's one or greater. These values cap the size of the collected values. **Sample** defaults to 10 and **Preserve All** defaults to 1000.
-* **Keep unique values only**: When selected, the reducer stores the collected values as a set and discards duplicates. When cleared, the reducer stores the values as a list and preserves duplicates.
-
-When you configure more than one strategy for the same attribute path, the reducer writes a separate attribute in the summary for each strategy, using a suffix such as `_sum`, `_avg`, or `_min`. The first strategy in the list also writes to the base attribute name. For example, configuring **Sum** and then **Average** for `bytes_sent` produces `bytes_sent_sum`, which is also written to `bytes_sent`, and `bytes_sent_avg`. To change the order in which strategies are applied, drag them in the list.
-
-> Adding multiple strategies, whether to a specific path or the default, adds additional attributes to the summary and requires more processing per message. Use multiple strategies only when your analytics or dashboards need more than one aggregated form of the same attribute.
-
-Each strategy type can be used only once per attribute path.
-
-### Configure the default strategy
-
-The **Default Strategy** section defines the strategies that apply to every attribute path that is not configured under **Attribute merging strategies**. You must configure at least one default strategy. **Exact Match** is the default.
-
-As with path-specific strategies, you can add multiple default strategies. When you add multiple default strategies, each strategy produces a suffixed attribute in the summary, and the first strategy also writes to the base attribute name.
-
-## Frequently Asked Questions
-
-### What is the aggregation window?
-
-The aggregation window is a fixed-duration, tumbling window over which the reducer counts and aggregates the messages that match each pattern. The reducer divides the incoming log stream into consecutive windows and produces a summary separately for each window. The window is two minutes by default. You cannot change the window duration in the Grepr UI; you must use the REST API, and Grepr recommends contacting support for guidance before changing it.
-
-### How do I prevent messages from different services being aggregated together?
-
-Add the tag key that identifies each service, such as service or env, to the Group-by values field. The reducer aggregates messages independently for each unique combination of group-by values, so patterns from different services are never merged.
-
-### What does the similarity threshold control?
-
-The similarity threshold is the percentage of tokens that must match between an incoming message and an existing pattern for the message to be considered part of that pattern. Higher values produce more distinct patterns and less aggressive reduction. Lower values produce broader patterns and more aggressive reduction, at the cost of more mask-defined tokens in each summary.
-
-### Why should I raise the minimum number of samples?
-
-The minimum number of samples is how many raw matching messages are forwarded for a pattern in an aggregation window before aggregation begins. Raise it when you want more raw samples of each pattern to be sent to your observability backend. Lower it to begin aggregation sooner and reduce more volume.
-
-### When should I disable the repeat count prefix?
-
-Disable the repeat count prefix when downstream systems parse the summary message body directly, such as when summary messages contain JSON. The prefix would otherwise prepend non-JSON text and break parsing.
-
-### What's the difference between the two sampling strategies?
-
-No Additional Sampling stops forwarding raw messages for a pattern as soon as the minimum number of samples has been reached in an aggregation window. Window-Based Logarithmic continues to forward additional raw samples at a logarithmically decreasing rate, preserving more visibility into high-volume patterns.
-
-### How does the logarithm base affect sampling?
-
-With Window-Based Logarithmic sampling, a larger logarithm base forwards fewer additional samples as message volume grows, and a smaller base forwards more. The base must be at least two.
-
-### What are masks and why does the reducer apply them?
-
-Masks are regular expressions that identify variable parts of a log message, such as timestamps, IDs, or IP addresses, and replace them with specific tokens before clustering. This normalizes messages that differ only in those values so they can be grouped into the same pattern.
-
-### Can I add my own masks?
-
-Yes. Click Add Custom Mask in the Mask Configuration section. The mask name must contain only lowercase letters, be no more than 50 characters long, and be unique across all masks in the reducer. Then enter the regular expression pattern to apply.
-
-### Which regular expression features can I use in a custom mask?
-
-A custom mask pattern supports common regular expression constructs, including literal characters and character classes such as \[a-z], \d, \w, and \s; quantifiers such as \*, +, ?, and {n,m}; alternation and grouping; and anchors and word boundaries such as ^, $, and \b. Lookahead and lookbehind assertions and backreferences are not supported. A pattern that uses an unsupported construct passes the form's validation but prevents the reducer from processing messages, so test a custom pattern against sample messages.
-
-### What are delimiters and when should I change them?
-
-Delimiters are the characters the reducer uses to split messages into tokens during clustering. The defaults cover common punctuation and whitespace but omit @ and . so email addresses and dotted identifiers are not split. Change the list when your log format uses other separators, such as a custom field delimiter.
-
-### How do I add a tab, newline, or carriage return delimiter?
-
-Enter the escape sequence in the Add delimiter field: \t for tab, \n for newline, or \r for carriage return. Additional control-character escape sequences, including \b, \f, \v, and \0, are also supported.
-
-### What does each attribute merge strategy do?
-
-Exact Match keeps a single value if all messages agree and stores a wildcard otherwise. Sample collects up to a limit of values and drops overflow. Preserve All collects every value up to a limit and emits the current summary when the limit would be exceeded. Sum, Min, Max, and Average compute the corresponding aggregation over numeric values, ignoring non-numeric values.
-
-### What is the difference between Sample and Preserve All?
-
-Sample stops collecting once its limit is reached and discards any further values in the same summary. Preserve All emits the current summary and starts a new one when adding more values would exceed its limit, so no value is discarded. Sample has a lower default limit; Preserve All has a higher default limit.
-
-### When does the 'Keep unique values only' checkbox matter?
-
-For Sample and Preserve All strategies, it controls how collected values are stored. When selected, values are stored as a set and duplicates are discarded. When cleared, values are stored as a list, and duplicates are preserved.
-
-### How do I target a specific attribute with its own strategy?
-
-Add an entry under Attribute merging strategies, enter the attribute path using dot notation or a JSON array, and configure one or more strategies. Paths must be unique within the list, and each entry must have a non-empty path.
-
-### What happens when I select multiple strategies for the same attribute?
-
-The reducer produces a separate attribute in the summary for each strategy, suffixed with the strategy name, such as _sum or _avg. The first strategy in the list also writes to the base attribute name. Each strategy type can be used only once per attribute path.
-
-### What does the default strategy apply to?
-
-The default strategy applies to every attribute path that does not have an explicit entry in Attribute merging strategies. Exact Match is the default, but you can configure one or more other strategies. As with path-specific strategies, additional default strategies produce suffixed attributes and require more processing.

package/build/dist/docs-index/fe053649-87a5-4f04-b93d-38f2aa5403ea.txt

@@ -1,37 +0,0 @@
-# QueryJobInfo
-
-Information about a query job.
-
-**Type**: `object`
-
-## Properties
-
-- name: flinkJobId (required)
-  type: `JobID`
-
-- name: integrationId (optional)
-  type: string
-  description: The integration id used for the query job. This determines where the results will be stored.
-
-- name: jobExpiry (required)
-  type: string
-  description: The time at which the job will expire. After this time, the job is bound to be terminated and any new results will not be made available.
-
-- name: metadata (optional)
-  type: `QueryJobMetadata`
-
-- name: nextHeartbeatTime (required)
-  type: string
-  description: The time after which the client should send a heartbeat. If no new heartbeats are received a certain amount of time after this, the job is bound to be terminated. To send heartbeats, do a query read.
-
-- name: resultPath (required)
-  type: string
-  description: The path where results from the query job will be available.
-
-- name: results (optional)
-  type: object
-  description: The results of the query job. The keys are the names of the result files and the values are the paths to them.
-
-- name: status (required)
-  type: enum: `PENDING`, `RUNNING`, `FINISHED`, `UNKNOWN`, `FAILED`, `TIMEOUT`, `CANCELLED`
-  description: The status of the query job.

package/build/dist/docs-index/fe4f93d9-f39a-463e-8db6-7278af4b42f5.txt

@@ -1,62 +0,0 @@
-# Variant
-
-**Type**: `object`
-
-## Properties
-
-- name: array (optional)
-  type: boolean
-
-- name: as (optional)
-  type: object
-
-- name: boolean (optional)
-  type: boolean
-
-- name: byte (optional)
-  type: string
-
-- name: bytes (optional)
-  type: string
-
-- name: date (optional)
-  type: string
-
-- name: dateTime (optional)
-  type: string
-
-- name: decimal (optional)
-  type: number
-
-- name: double (optional)
-  type: number
-
-- name: float (optional)
-  type: number
-
-- name: instant (optional)
-  type: string
-
-- name: int (optional)
-  type: integer
-
-- name: long (optional)
-  type: integer
-
-- name: null (optional)
-  type: boolean
-
-- name: object (optional)
-  type: boolean
-
-- name: primitive (optional)
-  type: boolean
-
-- name: short (optional)
-  type: integer
-
-- name: string (optional)
-  type: string
-
-- name: type (optional)
-  type: enum: `OBJECT`, `ARRAY`, `NULL`, `BOOLEAN`, `TINYINT`, `SMALLINT`, `INT`, `BIGINT`, `FLOAT`, `DOUBLE`, `DECIMAL`, `STRING`, `DATE`, `TIMESTAMP`, `TIMESTAMP_LTZ`, `BYTES`

package/build/dist/openapi-docs/api/Query-Jobs/query.md

@@ -1,29 +0,0 @@
-# Submit a query job.
-
-**POST** `/v1/jobs/query`
-
-**Operation ID**: `query`
-**Summary**: Submit a query job.
-Submit an asynchronous batch query job. The job results will be available as the paths specified in the response token. The job will expire after the expiry time specified in the response. and will be terminated if no heartbeats are received after the heartbeat expiry time. To keep the job alive, send a query read request with the received token.
-
-## Tags
-- Query Jobs
-## Request Body
-
-**Content-Type**: `application/json`
-
-**Schema**: `GreprJobGraph`
-
-## Responses
-
-### 201
-
-Query job submitted successfully. The response contains a token that can be used to query the job status and results.
-
-### 400
-
-The request was malformed or invalid.
-
-### 401
-
-Unauthorized