@grepr/cli 1.11.3 → 1.11.5-00bed08

package/build/dist/docs-index/c2067a77-5aba-422d-8991-7b1f027427ca.txt

@@ -1,220 +0,0 @@
-Aggregate logs in the Grepr data lake with Analyze mode, using Grepr SQL expressions over log fields, tags, and parsed attributes.
-
-# Aggregate logs with Analyze mode
-
-Log Explorer's Analyze mode groups and aggregates the logs your search returns instead of listing them. You describe the analysis as a set of Grepr SQL expressions, and Grepr runs it against the logs in the data lake.
-
-## Create an analysis
-
-1. Go to Log Explorer and select a dataset and a time range.
-2. Enter a search query to filter the logs you want to analyze. Analyze mode accepts the same [Datadog-like syntax](/queries/datadog) and [New Relic log query-like syntax](/queries/new-relic) as searching.
-3. Open the **Analyze...** drawer under the search controls.
-4. Under **SELECT**, enter one expression per result column, and name it in the **Alias** field beside it. An alias is optional; a column you leave unnamed is named for you, after the field or function it computes.
-5. Under **GROUP BY**, add the expressions whose distinct combinations you want as rows. When you finish a new grouping expression, the builder adds a SELECT row for it and groups by that row's alias, so the expression is written once. Renaming the alias renames the grouping with it, and removing the column puts the expression back under GROUP BY. A GROUP BY row can name any SELECT alias. Without a grouping expression, an analysis made only of aggregates returns a single row.
-6. Under **HAVING**, enter a condition over the aggregates to keep only some of the groups. Leave it empty to keep every group.
-7. Under **ORDER BY**, add the expressions to sort by and pick ascending or descending for each one.
-8. Set **Row limit**, the maximum number of rows to return. An analysis returns 2,500 rows by default. The field stops at the largest limit your deployment allows, and a larger one is refused with a message naming that maximum.
-9. Set **Scan budget** to cap how much of the lake the query may read, then run the analysis.
-
-The drawer's clauses are the SQL ones, so an analysis reads the way the query does: SELECT computes, GROUP BY collapses, HAVING filters the groups, ORDER BY and the row limit choose which of them you see. GROUP BY, HAVING and ORDER BY can refer to a result by its alias.
-
-## Log fields
-
-Expressions address the stored log columns by the following names:
-
-| Field | Type | Description |
-| --- | --- | --- |
-| `message` | VARCHAR | The log line. |
-| `severity` | INTEGER | The numeric severity level, where a higher number is more severe. |
-| `event_timestamp` | TIMESTAMP | When the event happened. |
-| `received_timestamp` | TIMESTAMP | When Grepr received the event. |
-| `id` | VARCHAR | The identifier of the event. |
-| `tags` | MAP | The tag values, keyed by tag name. |
-| `attributes` | VARIANT | The whole parsed attribute document. |
-
-> These are the Grepr SQL column names, which use `snake_case`. They are not the camelCase field names of the log event JSON that the search and export APIs return.
-
-A tag holds an array of values, so the suggestion for a tag key groups by the sorted, comma-joined set of its values — two events tagged with the same values in a different order land in one group. The suggestion shows this expression beside the key, so you can see what picking the key inserts:
-
-```sql
-ARRAY_TO_STRING(SORT_ARRAY(tags['service']), ',')
-```
-
-Index a single value with `[1]` when you want only the first:
-
-```sql
-tags['service'][1]
-```
-
-## Attribute values
-
-Grepr parses structured logs into an attribute document. Address a single attribute with the `@` form, which takes a dotted path through that document:
-
-```sql
-@duration_ms
-@http.status_code
-@kubernetes.labels.app
-```
-
-The shorthand reads one value out of the parsed document. The `attributes` column is the whole document, so use `@` when you want a field and `attributes` when you want the object itself.
-
-An attribute has no declared type, because two logs in the same dataset can carry different types under the same name. Grepr infers a type from how you use the value, so `SUM(@duration_ms)` reads it as a number and `LOWER(@user.email)` reads it as a string.
-
-Cast the attribute when you need a specific type or precision, and when you sort:
-
-```sql
--- Read the attribute as a whole number
-CAST(@duration_ms AS BIGINT)
-
--- Or aggregate the cast value
-MIN(CAST(@duration_ms AS DOUBLE))
-```
-
-> Sorting by an attribute you have not cast sorts it as text, so `100` sorts before `99`. Cast it to sort numerically.
-
-A path segment is a name or a number, and the segments are separated by dots. An `@` with nothing after it, or a segment that starts with a digit, is a syntax error, and Log Explorer reports it against the expression you typed.
-
-## Expressions
-
-Expressions are Grepr SQL, so aggregates, `CASE`, `CAST` and scalar functions are all available.
-
-Every function an analysis can call is listed in the [Analyze function reference](/queries/analyze/functions), with its arguments and a worked example. Focus an expression box or start typing to find fields, functions, sampled tag and attribute keys, and result aliases. Suggestions match the text you type; they do not check whether each option fits the surrounding SQL. Typing a space closes the menu. Press the Down arrow key to open it again.
-
-> The [SQL transform function reference](/transforms/sql-transform/sql-functions) does **not** describe Analyze. A SQL transform runs inside a pipeline on Flink SQL; an analysis runs on the query engine over the data lake. The two support different functions, so a function listed there may not exist here, and the autocomplete offers functions that page does not list.
-
-```sql
--- Log count by service: the first line goes under SELECT, the second under GROUP BY
-COUNT(*)
-ARRAY_TO_STRING(SORT_ARRAY(tags['service']), ',')
-
--- 95th percentile request duration by endpoint, the same way
-APPROX_PERCENTILE(@duration_ms, 0.95)
-@http.route
-
--- A SELECT column that buckets rather than aggregates
-CASE WHEN severity >= 4 THEN 'error' ELSE 'ok' END
-```
-
-`SEVERITY_TEXT` names the OpenTelemetry severity bucket a severity number falls in: `TRACE`, `DEBUG`, `INFO`, `WARN`, `ERROR` or `FATAL`, and nothing for a log with no severity. It takes a whole number, so text and fractional operands are errors rather than values Grepr will quietly convert. Grouping by it is the usual way to count logs per level:
-
-```sql
--- Under SELECT
-COUNT(*)
-
--- Under GROUP BY
-SEVERITY_TEXT(severity)
-```
-
-## Name the results
-
-Every SELECT column takes an optional alias, entered in the **Alias** field beside the expression. The alias becomes the result column's name. Pick a tag from the suggestions and the alias is filled in with the tag's own key, since the expression that reads a tag is a call wrapped around it. Leave the alias empty and Grepr names the column after the expression itself:
-
-| Expression | Alias | Result column |
-| --- | --- | --- |
-| `COUNT(*)` | empty | `count0` |
-| `APPROX_PERCENTILE(@duration_ms, 0.95)` | `p95` | `p95` |
-| `ARRAY_TO_STRING(SORT_ARRAY(tags['service']), ',')` | `service`, filled in for you | `service` |
-| `severity` | empty | `severity` |
-| `@http.route` | `route` | `route` |
-
-An alias can then be referred to under GROUP BY, HAVING or ORDER BY, anywhere inside that expression rather than only as the whole of it:
-
-```sql
--- Under HAVING
-count0 > 100
-
--- Under ORDER BY
-p95 / 1000
-```
-
-Aliases are lowercase, made of letters, digits and underscores, up to 128 characters, and a reference has to match exactly.
-
-> The alias goes in its own field, not in the expression: writing `AS p95` inside an expression is rejected. An alias is available to GROUP BY, HAVING and ORDER BY, and to the SELECT columns after the one that defines it.
-
-Reserved SQL words cannot be aliases, because the query engine would read them as syntax. Log Explorer refuses one and suggests an alternative, which is why the default first column is `count0` rather than `count`. The same rule applies to an alias Grepr derives for you: a derived name that lands on a reserved word gains a `0`.
-
-> `count`, `max`, `min`, `sum`, `value`, `date` and `year` are reserved. Ordinary field names such as `level`, `name`, `type`, `path`, `service`, `host` and `user` are not.
-
-## Window by time
-
-To see how an aggregate changes over time, add a time window under the grouping expressions. Every result row then carries a `window_start` and a `window_end` column, and the other grouping keys and aggregates are computed per window. The analysis is sorted by `window_start` descending, so the newest window leads.
-
-| Kind | Meaning |
-| --- | --- |
-| Tumbling | Fixed windows that do not overlap. A 5 minute window puts each log in exactly one bucket. |
-| Sliding | Windows of one size that start every *slide*. A 5 minute window sliding every 1 minute counts each log in five overlapping windows. The size must be a whole multiple of the slide, and a window can cover at most 100 slides. |
-
-Each duration is a whole number of milliseconds, seconds, minutes, hours, or days. Windows bucket by event time by default; choose receive time to bucket by when Grepr received each log instead. The time range you searched selects logs by event time either way.
-
-Windows are aligned to the clock rather than to the start of your time range, so the first and last windows of a range can be partial.
-
-Setting a window puts `window_start` and `window_end` first among the result columns and sorts the analysis by `window_start` descending, so the newest window leads without any further setup. Both are yours to change: drag the columns elsewhere, or edit the sort. Removing the window removes the bound columns and drops the sorts that referred to them.
-
-In the API, the window is the `window` object of the structured analytics query, with ISO-8601 durations:
-
-```json
-{ "kind": "SLIDING", "timestamp": "EVENT_TIMESTAMP", "size": "PT5M", "slide": "PT1M" }
-```
-
-## Read the results table
-
-Click a column header to sort the rows you already have. No second run happens and no scan budget is spent; Shift-click adds a second sort instead of replacing the first.
-
-When an analysis comes back at its row limit, the rows you have are only the top of the ranking, so sorting them on the page can put the wrong rows first. The table says so and offers **Sort on the server**, which puts the sort into ORDER BY and runs the analysis again so the engine ranks every matching row.
-
-## Share an analysis
-
-The whole analysis lives in the page URL, so copying the link from the address bar is enough to share it. The link carries the dataset, the time range, the search query, every SELECT expression and its alias, every GROUP BY expression, the HAVING condition, the ORDER BY, the time window, the row limit, the scan budget, and the way you arranged the results table — its column order, column widths and sort.
-
-Opening such a link seats every control and runs the analysis once, so the recipient sees the rows rather than a filled-in form waiting for a click. Back and Forward move between analyses you have already run, restoring the controls without re-running and spending scan budget again.
-
-An analysis long enough to overflow the address bar cannot be carried, and Log Explorer says so rather than sharing a link that silently restores something different.
-
-## Result values
-
-Each result row is a JSON object keyed by column name, so a column holds whatever the underlying attribute held, such as a number, a string, a boolean, or a nested object. Timestamps are returned as UTC ISO 8601 strings.
-
-## Limitations
-
-* An analysis reads one dataset at a time. Joins across datasets are not supported.
-* Sorting by an attribute that you have not cast sorts it by its stored text, so `100` sorts before `99`. Cast the attribute to sort numerically, as in `CAST(@http.status_code AS BIGINT)`.
-* A result alias cannot be a reserved SQL word, and a reference to one has to match its lowercase spelling exactly.
-* A sort you set from the result headers sorts the rows already on the page. When the analysis returned its row limit, use **Sort on the server** to rank every matching row instead.
-* An analysis too long to fit in the address bar cannot be shared as a link.
-* An analysis can compute at most 128 values, group by at most 64 expressions, and sort by at most 64 expressions. Each expression can be at most 4,096 characters long.
-* A time window's size and slide are whole milliseconds, and a sliding window covers at most 100 slides. `window_start` and `window_end` cannot be used as result aliases while a window is set.
-* Row, array, and map values are converted to nested JSON automatically. A column is rejected with an error that names it only if its value type has no JSON representation at all, or a constructed row has two fields with the same name.
-
-## Frequently Asked Questions
-
-### How do I aggregate logs in Grepr?
-
-Go to Log Explorer, select a dataset and time range, enter a search query, then open the Analyze... drawer under the search controls. Enter Grepr SQL expressions under SELECT for the result columns, under GROUP BY for the grouping keys, and under ORDER BY for the sort.
-
-### What are the log field names in Grepr SQL?
-
-message, severity, event_timestamp, received_timestamp, id, tags, and attributes. Read the whole set of a tag's values as ARRAY_TO_STRING(SORT_ARRAY(tags\['service']), ','), index a single value as tags\['service']\[1], and address an attribute as @http.status_code.
-
-### How do I bucket an analysis by time?
-
-Add a time window under the grouping expressions in Analyze mode. Choose tumbling or sliding, a size, and for sliding windows a slide. Results gain window_start and window_end columns.
-
-### How many rows can an analysis return?
-
-An analysis returns 2,500 rows by default. The largest limit you can ask for is set by your deployment; asking for more is refused with a message naming the maximum.
-
-### How do I share a Grepr analysis?
-
-Copy the page URL. The link carries the dataset, time range, query, every expression and alias, the window, the row limit, the scan budget and the column order, widths and sort, and opening it runs the analysis once.
-
-### Why can't I name a result column count?
-
-count is a reserved SQL word, so the query engine would read it as syntax rather than as an alias. Log Explorer suggests count0 instead, which is also why the default first column is named count0.
-
-### How do I turn severity numbers into names in Grepr?
-
-Use SEVERITY_TEXT(severity), which names the OpenTelemetry bucket: TRACE, DEBUG, INFO, WARN, ERROR or FATAL. It takes a whole number, so cast an attribute before passing it.
-
-### How do I sort an analysis by a result column?
-
-Click the column header in the results table. The rows on the page reorder immediately, without a second run. If the analysis returned its row limit, the table offers Sort on the server, which puts the sort into ORDER BY and runs the analysis again.

package/build/dist/docs-index/c770124a-829c-4ee7-be2c-1767ce5f68df.txt

@@ -1,217 +0,0 @@
-Learn how to configure how Grepr integrates with observability platforms and storage systems to support data ingestion, processing, and output in your pipelines.
-
-# Configure how Grepr integrates with observability platforms and cloud storage
-
-To support data ingestion and data output for your Grepr pipelines, you connect Grepr to external observability platforms and storage systems. To support these connections, the Grepr platform uses *integrations*. A Grepr integration provides the configuration details to connect to an external system, enabling data exchange between Grepr and that system.
-
-After configuring an integration, you can use it in your Grepr pipelines to create *sources* to ingest data from agents and collectors, such as FluentD or the OpenTelemetry collector, and *sinks* to send data to an observability platform or storage.
-
-You can use the Grepr UI or the REST API to create and manage integrations. To use the UI, see [Manage integrations in the Grepr UI](#manage-integrations-in-ui). To use the API, see the documentation for each [supported integration](#supported-integrations).
-
-## Integration types
-
-The Grepr platform includes two integration types:
-
-* Observability platform integrations: Connections to monitoring, logging, and APM platforms, such as Datadog, Splunk, New Relic, and Sumo Logic.
-* Cloud storage integrations: Connections to cloud storage. The Grepr data lake uses cloud storage to store your raw data and metadata.
-
-## Supported platform and storage integrations \[#supported-integrations]
-
-The Grepr platform includes the following integrations. For details on configuring and using an integration, refer to the linked documentation page. For a complete list of supported integrations, supported functionality, and details on vendor-specific capabilities with some integrations, see [Grepr supported vendor and storage integrations](/integrations/support-matrix).
-
-### Datadog
-
-The Datadog integration connects to the Datadog observability platform and supports sourcing data from several Datadog-compatible collectors and sending processed data to Datadog.
-
-See [Configure Datadog connections with a Grepr integration](/integrations/datadog).
-
-### New Relic
-
-The New Relic integration connects to New Relic's observability platform. Use this integration to create sources that retrieve log data from New Relic collectors and sinks that send processed data to New Relic for monitoring and analysis.
-
-See [Configure New Relic connections with a Grepr integration](/integrations/new-relic).
-
-### Splunk
-
-The Splunk integration provides connectivity to Splunk through Splunk's HTTP Event Collector (HEC) or S2S over HTTP. This integration supports reading data from Splunk collectors and writing data to Splunk indexes.
-
-See [Configure Splunk connections with a Grepr integration](/integrations/splunk).
-
-### Sumo Logic
-
-The Sumo Logic integration connects to Sumo Logic's cloud-based log management and monitoring platform using a Sumo Logic HTTP Source. You can use the integration to create sources that ingest data from Sumo Logic collectors and sinks that send processed data to Sumo Logic.
-
-See [Configure Sumo Logic connections with a Grepr integration](/integrations/sumo-logic).
-
-### OpenTelemetry
-
-The Grepr OpenTelemetry integration lets you ingest logs and Application Performance Monitoring (APM) data into Grepr from a collector that supports the OpenTelemetry Protocol over HTTP, or OTLP/HTTP, process them with a Grepr pipeline, and then send the processed data to any observability vendor that accepts OTLP/HTTP requests.
-
-See [Configure connections to OpenTelemetry compatible platforms](/integrations/open-telemetry).
-
-### Grafana Cloud
-
-You can configure Grepr's OpenTelemetry integration to connect with Grafana Cloud using the OpenTelemetry Protocol (OTLP). Use an OpenTelemetry integration to create sources that ingest data from OTLP-compatible collectors and sinks that send processed log data to Grafana Cloud.
-
-See [Configure Grafana Cloud connections with a Grepr integration](/integrations/grafana).
-
-### Amazon CloudWatch
-
-You can configure Grepr's OpenTelemetry integration to connect with Amazon CloudWatch using the OpenTelemetry Protocol (OTLP). Use an OpenTelemetry integration to create sources that ingest data from OTLP-compatible collectors and sinks that send processed log data to a CloudWatch log group.
-
-See [Configure Amazon CloudWatch connections with a Grepr integration](/integrations/cloudwatch).
-
-### Google Cloud Platform (GCP)
-
-The GCP integration as a source enables you to stream logs from Google Cloud services to Grepr for processing and analysis, and then forward the processed logs to any sink created using a Grepr-supported integration, such as Datadog, Splunk, or New Relic.
-
-See [Google Cloud Platform observability with Grepr](/integrations/gcp).
-
-### Cloud storage
-
-The Grepr data lake uses Amazon S3 to store, manage, and support querying the raw data from your Grepr pipelines. Depending on your requirements, you can choose from two S3 integrations: a Grepr-hosted integration, which uses a Grepr-managed S3 bucket, and an integration that uses an S3 bucket in your account. Both integrations provide secure, managed, and efficient storage for your data, along with an optimized query interface.
-
-To configure the Grepr-hosted integration, you only need to assign a name to the integration. The Grepr platform manages the S3 bucket, including its deployment and configuration.
-
-Using the integration with your own S3 bucket requires that you deploy and configure an S3 bucket in your AWS account, but it provides more control over your data. See [Host a Grepr data lake with the Amazon S3 integration](/integrations/aws-s3).
-
-## Manage integrations in the Grepr UI \[#manage-integrations-in-ui]
-
-The **Integrations** page displays your integrations as cards, organized by observability vendor integrations and storage integrations. In each section, cards are ordered by recent activity, with the most active integrations appearing first.
-
-In addition to the integration name and its type, for example, a Datadog integration, if the integration is assigned to one or more teams, the team names appear in the header of the card.
-
-You can get a visual overview of the health and usage of your integrations using the charts included on each integration card. If an integration has recent activity, such as requests received from agents by a vendor integration or the amount of data written to a storage integration, a time-series chart of that activity is shown on the card.
-
-* Observability vendor integrations display requests received from agents over the last 30 minutes, color-coded by HTTP status code.
-
-  * To view more detailed metrics or more details about a pipeline that uses the integration, select it from the **Pipelines** menu.
-
-* Storage integrations display data written to the integration over the last 24 hours, broken down by dataset.
-
-  * To view and query a dataset stored on a storage integration, select it from the **Datasets** menu.
-
-To view more details about the metrics in either chart type, hover over any point in the chart to see a tooltip with the value and timestamp for that point.
-
-### Add an integration
-
-To create an integration, click **Add new** next to the section heading for the type you want to add. To learn how to create and configure specific integrations, see the documentation for each [supported integration](#supported-integrations).
-
-### Edit an integration
-
-To edit an integration, click the three-dot menu on the integration card and select **Edit**. Update the fields in the dialog and click **Save**.
-
-### Delete an integration
-
-To delete an integration, click the three-dot menu on the integration card and select **Delete**. Confirm the deletion in the dialog that appears.
-
-### Identify log events that should bypass aggregation \[#passthrough-estimation]
-
-When you create an integration with an observability vendor that supports *exception parsing*, Grepr automatically parses queries used by monitors, dashboards, or alerts in your observability vendor platform. You can use this list of queries to identify log messages that should be treated as *exceptions* to log reduction in Grepr pipelines. In other words, messages that should bypass aggregation to ensure that critical alerts and dashboards continue to work as expected. To help with identifying exceptions, the Grepr UI displays a *passthrough percentage* estimate for each query. This estimate is the percentage of events, over a configurable time window, that would bypass aggregation.
-
-You can also choose to automatically add and remove exceptions by enabling **Auto-sync exceptions** when you add the integration to your pipelines. To learn more about enabling and using auto-sync when you create or edit a pipeline, see [Prevent aggregation of messages used in your observability platform](/transforms/reducer/exceptions#vendor-exceptions).
-
-If an integration does not support exception parsing, the **Parsed Alerts** button on the integration card is disabled. See [Supported integrations: observability platforms](/integrations/support-matrix#supported-observability-integrations).
-
-To view the log queries parsed from an integration and configure passthrough estimation:
-
-1. On the **Integrations** page, on the card for a vendor integration that supports query parsing, click **Parsed Alerts**.
-
-   The **Parsed alert queries** dialog displays a table with the following columns:
-
-   * **Id**: The unique identifier for this alert.
-   * **Name**: The alert or dashboard name from your vendor.
-   * **Exception Type**: The type of vendor resource the query came from, such as a monitor or dashboard widget.
-   * **Query**: The log query extracted from the alert or dashboard.
-   * **Passthrough %**: The percentage of raw logs in your configured dataset that match this query. This value is displayed only if you've configured passthrough estimation.
-   * **Last Updated**: When the passthrough percentage was last calculated. Hover over the value to see the exact date and time.
-
-   You can filter the table by name or query text and filter by exception type using the multi-select filter in the **Exception Type** column. To manage which columns are visible, click the **Manage columns** icon in the upper-right corner of the table.
-
-2. To configure passthrough estimation and view the percentage of logs that would bypass aggregation for each query, click **Configure Passthrough Estimation**.
-
-   The **Passthrough Estimation Configuration** dialog lists the datasets that pipelines using the integration write to. Each row shows whether passthrough estimation is configured for that dataset and which pipelines use it.
-
-   > When you configure passthrough estimation for a dataset, it applies to all integrations or pipelines that use that dataset as a sink.
-
-3. Expand the row for the dataset you want to configure.
-
-4. Under **Filter Query (Optional)**, select your preferred query syntax and enter a query to filter for logs to include in the estimation analysis. Use this field when your dataset contains logs from multiple sources, and you want Grepr to use only the logs relevant to this integration. Leave this field empty to include all logs in the dataset.
-
-5. In the **Lookback Duration** menu, select the time window for calculating percentages. Options range from 15 minutes to 24 hours. A shorter window scans less data, reducing costs, but may not be representative if your log patterns vary throughout the day. A longer window provides more representative results but increases the cost of the analysis queries.
-
-6. In the **Refresh Period** menu, select how often Grepr recomputes each estimation for this dataset. Options range from 1 hour to 30 days, with a default of 7 days. A shorter period uses more recent logs to calculate estimates, resulting in more up-to-date values, but increases query load on the data lake.
-
-7. In the **Log Limit** field, enter the maximum number of logs to scan per estimation run. The default is 10,000,000. Larger limits provide more representative results, but increase the cost of each estimation query.
-
-8. To save a new configuration, click **Enable**. To save edits to an existing configuration, click **Save changes**.
-
-Grepr's impact estimation cycle runs once an hour for any datasets due for refresh, based on each dataset's **Refresh Period**. New or recently changed queries are included in the next cycle. A first estimate typically appears within an hour, though it might take longer if a large number of queries are queued for processing.
-
-To stop estimating for a dataset, expand its row and click **Disable estimation**. The dataset remains in the list as **Not configured** so you can re-enable estimation later.
-
-### Interpret passthrough percentages
-
-> Although two queries might use the same log events, their estimates will be equal. Additionally, the passthrough rate remains constant and is not the sum of the estimates. For example, if you enable exceptions for two queries that use the same log events, the passthrough rate doesn't double, but remains equal to the rate when only one exception is enabled.
-
-The **Passthrough %** value for a query shows what fraction of your raw logs that alert would require to pass through without aggregation. Use these values to evaluate the impact of adding each alert as a pipeline exception:
-
-A percentage less than 1% is considered low, and an exception should have minimal impact on aggregation efficiency and storage.
-
-You should review carefully any percentage above 1% before creating an exception for the query.
-
-A dash (—) in the **Passthrough %** column indicates that no estimate is available yet, either because passthrough estimation is not configured, or because Grepr hasn't finished calculating the estimate. If passthrough estimation is configured, the first estimate typically appears within an hour, and later refreshes occur based on the dataset's **Refresh Period**.
-
-The **Passthrough Estimation Configuration** dialog also includes the **Recent Activity** table at the bottom. This section shows the most recent log events related to exception parsing, giving you visibility into recent integration activity without leaving the dialog. To view the complete log history for the integration, click **View all logs** to go to the **System Logs** page, pre-filtered to show all activity for the selected integration.
-
-### Configure passthrough estimation from a pipeline
-
-You can also configure passthrough estimation directly from a pipeline. On the pipeline details page, in the left-hand navigation menu, click **Exceptions**. In the **Actions** column for an **Avoid impacting dashboards/alerts** exception, click the **⋯** menu and select **Configure estimations** to open a dialog that includes all datasets configured as sinks for the pipeline. Any configuration changes you make to the dataset apply to every other integration or pipeline that populates that dataset.
-
-To have Grepr recompute impact percentages during the next impact estimation cycle, click the **⋯** menu and select **Reset estimations** to clear the cached impact percentages for the datasets configured as sinks for the pipeline. Use this when you've changed alert queries in your observability vendor and want updated estimates without waiting for the next scheduled refresh.
-
-## Limitations \[#limitations]
-
-Grepr might split log events over 900KB, causing them to lose their original structured format. Each split event includes a common `grepr.splitOriginId` attribute if you need to reconstruct the original message.
-
-## Frequently Asked Questions
-
-### What is a Grepr integration?
-
-A Grepr integration provides the configuration details needed to connect Grepr to an external system, such as an observability platform or cloud storage. Integrations enable data exchange between Grepr and external systems, allowing you to create sources for data ingestion and sinks for data output in your pipelines.
-
-### What types of integrations does Grepr support?
-
-Grepr supports two integration types: observability platform integrations (connections to monitoring, logging, and APM platforms like Datadog, Splunk, New Relic, and Sumo Logic) and cloud storage integrations (connections to cloud storage for the Grepr data lake).
-
-### What is a source in a Grepr pipeline?
-
-A source in a Grepr pipeline is an operator that ingests data from an external system or agent. Sources use integrations to connect to observability platforms or collectors like FluentD or OpenTelemetry to pull data into Grepr for processing.
-
-### What is a sink in a Grepr pipeline?
-
-A sink in a Grepr pipeline is an operator that outputs processed data to an external system. Sinks use integrations to send Grepr-processed logs to observability platforms, data lakes, or other storage systems based on your pipeline configuration.
-
-### Can I use multiple integrations in a single pipeline?
-
-Yes, you can configure pipelines with multiple sources to ingest data from different platforms and multiple sinks to send processed data to different destinations. This flexibility allows you to build complex multi-source, multi-destination data processing workflows.
-
-### Which observability platforms does Grepr support?
-
-Grepr supports integrations with Datadog, Splunk, New Relic, Sumo Logic, Grafana Cloud, and Google Cloud Platform (GCP). Each integration enables different source and sink capabilities depending on the platform's features and capabilities.
-
-### How do I configure a Grepr integration?
-
-To configure an integration, you need to provide connection details specific to your external system, such as API keys, tokens, endpoints, or credentials. The specific steps vary by integration type. Detailed instructions for each integration are available in the platform-specific documentation pages.
-
-### What is the Grepr data lake integration?
-
-The Grepr data lake uses Amazon S3 to store raw log data. You can configure either a Grepr-hosted integration (using a Grepr-managed S3 bucket) where you only provide a name, or an integration with your own AWS account (requiring you to configure and manage the S3 bucket yourself for more control).
-
-### What happens to logs older than 48 hours from external sources?
-
-Grepr might drop incoming data from external integration sources with timestamps older than 48 hours. This limitation helps optimize storage and processing while allowing you to retain raw logs in the data lake for longer-term analysis.
-
-### What happens when a log event is larger than 900KB?
-
-If a log event exceeds 900KB, Grepr might split it into smaller events, which can cause them to lose their original structured format. Each split event includes a common 'grepr.splitOriginId' attribute that you can use to reconstruct the original message from its component parts.

package/build/dist/docs-index/ca1fe484-d0bb-46b1-93c1-6de0c2eccf32.txt

@@ -1,18 +0,0 @@
-# Get the current maxTokens window of one LLM integration
-
-**GET** `/v1/llm-usage/{integrationId}`
-
-**Operation ID**: `currentWindow`
-**Summary**: Get the current maxTokens window of one LLM integration
-## Parameters
-
-- **integrationId** (required) - path
-  - Type: string
-
-## Responses
-
-### 200
-
-Current window retrieved
-
-- **Content-Type**: `application/json` / `LlmUsageWindow`

package/build/dist/docs-index/d9c4be08-6f77-4504-9987-6a93eeaa4607.txt

@@ -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

package/build/dist/docs-index/e228ad9c-4115-4c5f-b250-8ab6007b2703.txt

@@ -1,44 +0,0 @@
-# Start a vendor estimation run
-
-**POST** `/v1/integrations/{integrationId}/exceptions/vendor-estimation-runs`
-
-**Operation ID**: `createVendorEstimationRun`
-**Summary**: Start a vendor estimation run
-Creates a run over the given scope and window covering every exception the integration has imported, with one result row per distinct predicate, and queues its first slice. One non-terminal run per organization: starting a second returns 409 while the first is still in flight.
-
-## Tags
-- Integration Exceptions
-## Parameters
-
-- **integrationId** (required) - path
-  - Integration id
-  - Type: string
-
-## Request Body
-
-**Content-Type**: `application/json`
-
-**Schema**: `CreateVendorEstimationRunRequest`
-
-## Responses
-
-### 201
-
-Run created
-
-- **Content-Type**: `application/json` / `VendorEstimationRun`
-### 400
-
-Bad Request - Window is inverted or scope is invalid.
-
-### 401
-
-Unauthorized
-
-### 404
-
-Not Found - Integration not found.
-
-### 409
-
-Conflict - The organization already has a run that has not finished.

package/build/dist/docs-index/e82276c2-20b5-4292-820e-5129e539db7f.txt

@@ -1,16 +0,0 @@
-# QueryJobMetadata
-
-Metadata about a query job.
-
-**Type**: `object`
-
-## Properties
-
-- name: numTasksFinished (optional)
-  type: integer
-
-- name: numTasksPending (optional)
-  type: integer
-
-- name: numTasksRunning (optional)
-  type: integer

package/build/dist/docs-index/eb84f29d-ec2c-412a-8681-dc27d67c39d5.txt

@@ -1,16 +0,0 @@
-# JobID
-
-The Flink job ID for the query job.
-
-**Type**: `object`
-
-## Properties
-
-- name: bytes (optional)
-  type: string
-
-- name: lowerPart (optional)
-  type: integer
-
-- name: upperPart (optional)
-  type: integer

package/build/dist/docs-index/ec40776e-8f2f-4002-910f-0e5deb22fceb.txt

@@ -1,37 +0,0 @@
-# Resume a stalled vendor estimation run
-
-**POST** `/v1/integrations/{integrationId}/exceptions/vendor-estimation-runs/{runId}/resume`
-
-**Operation ID**: `resumeVendorEstimationRun`
-**Summary**: Resume a stalled vendor estimation run
-Triggers another slice for a run that has been running without progress for longer than the configured stale threshold. Returns 409 for a run that is progressing normally, parked on a rate limit, or already finished.
-
-## Tags
-- Integration Exceptions
-## Parameters
-
-- **integrationId** (required) - path
-  - Integration id
-  - Type: string
-- **runId** (required) - path
-  - Run id
-  - Type: string
-
-## Responses
-
-### 200
-
-Slice triggered
-
-- **Content-Type**: `application/json` / `VendorEstimationRun`
-### 401
-
-Unauthorized
-
-### 404
-
-Not Found - Integration or run not found.
-
-### 409
-
-Conflict - The run is not eligible to be resumed.

package/build/dist/docs-index/f4815d14-3f6c-489a-a657-ed9b81b4505e.txt

@@ -1,15 +0,0 @@
-Learn how to create, run, and manage Grepr pipelines that process your telemetry data to improve value and reduce size before sending it to your observability platform.
-
-# Process your telemetry data with Grepr pipelines
-
-Grepr pipelines orchestrate data processing flows that ingest your telemetry data, such as logs and Application Performance Monitoring (APM) data produced by agents and collectors, transform and enrich the data, and deliver the resulting data to your observability platform.
-
-An example of a pipeline is a log or trace reduction pipeline that reduces the volume of duplicate, low-value events by creating summarized events that retain the context of the original events.
-
-## Trace reduction pipelines
-
-Trace reduction pipelines process the APM data produced by your applications and agents by applying configured transformations, sampling to create representative subsets of the data, and forwarding the results to your observability platform. Grepr uses a novel approach to identify and sample every path through your system. Sampling reduces the volume and cost of data sent to your observability platform, while the complete set of raw traces is retained in a Grepr data lake. If you use Datadog, you can also derive and forward metrics from your trace data to track trends across your traces without forwarding every trace. See [_](/pipelines/trace-pipelines).
-
-## Agent sessions pipelines
-
-Agent sessions pipelines process the telemetry produced by coding agents such as Claude Code, Codex, and OpenCode. A coding agent reports its conversation as OpenTelemetry log events and its execution as OpenTelemetry spans, and neither signal is readable as a session on its own. An agent sessions pipeline reads both signals, reconstructs each run into a single session, and stores it in a Grepr data lake, so you can read the transcript, measure the tokens and cost the run consumed, and find the runs that failed. See [_](/pipelines/agent-sessions).