@grepr/cli 1.11.5 → 1.11.6-674b35e

package/build/dist/docs-index/7def411a-f59f-4be0-bd96-390f50a79f37.txt

@@ -0,0 +1,229 @@
+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. Each grouping expression also becomes a result column, so the rows show the values they are grouped on. 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, up to the largest limit your deployment allows.
+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.
+
+Every SELECT column is either an aggregate or one of the grouping expressions. To count events by a field, add the field under SELECT and group by it.
+
+## 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 picking a tag key from the suggestions 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:
+
+```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 name is a dotted path of letters, digits, and underscores. A hyphen or a slash can join characters inside a segment, so `@trace-id` and `@app.kubernetes.io/name` are each one name. Because `-` and `/` are name characters, put whitespace around them when you mean subtraction or division: write `@bytes / 1024`, not `@bytes/1024` (which reads `bytes/1024` as one name). Every other character ends the name, so `@status=500` and `@duration_ms*2` work without spaces.
+
+To read a key that uses any other character, such as a space, comma, or bracket, reference it through the `attributes` column with a single-quoted key in brackets. The bracketed key can be any string, dots included, and names exactly one key; double a single quote to include one. Add one bracketed key per level of a nested path:
+
+```sql
+attributes['service.status']
+attributes['special outer key']['special inner key']
+```
+
+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))
+```
+
+Grepr reads a numeric attribute as a 64-bit floating point value, which represents whole numbers exactly only up to 9,007,199,254,740,992. Above that limit, two different whole numbers can compare as equal. Store large identifiers such as trace ids and 64-bit request ids as strings, which always match exactly. If an attribute already holds a large whole number, cast it to `BIGINT` to compare it exactly.
+
+> 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.
+
+## 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.
+
+> 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 cast an attribute before passing it. 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. Leave it 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.
+
+> Enter the alias in its own field, not in the expression: `AS p95` inside an expression is not valid. 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. That is why the default first column is `count0` rather than `count`, and why a name Grepr derives for you gains a `0` when it lands on a reserved word.
+
+> `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.
+
+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. **Sort on the server** 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.
+
+## 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 value whose type has no JSON representation at all, or a constructed row with two fields of the same name, cannot be returned.
+
+## 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.
+
+### 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. Name the column count0 or anything else that is not reserved; that is 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, use Sort on the server, which puts the sort into ORDER BY and runs the analysis again.

package/build/dist/docs-index/7fc706cd-f16d-4533-ba9b-5da7af53cdff.txt

@@ -0,0 +1,81 @@
+This page provides a comprehensive overview of the Grepr-supported integrations with observability platforms and cloud storage, and the features supported by those integrations.
+
+# Grepr supported vendor and storage integrations
+
+This page provides an overview of the observability platform and cloud storage integrations supported by the Grepr platform. This page also specifies the features supported by each integration, including whether it can be used as a source or a sink.
+
+> If you require an integration that Grepr does not support, contact <support@grepr.ai>.
+
+## Supported integrations: cloud storage
+
+Grepr supports Amazon S3 for storing, querying, and backfilling raw data. See [Host a Grepr data lake with the Amazon S3 integration](/integrations/aws-s3).
+
+## Supported integrations: AI agents \[#supported-ai-integrations]
+
+The following integrations support Grepr AI agents. None of them are a pipeline source or sink, so they do not appear in the source and sink tables on this page.
+
+| Integration | What it provides |
+| --- | --- |
+| LLM provider | The generative model an agent reasons with and the embedding model agent memory uses. |
+| MCP server | The tools of another system that an agent can call. |
+| Grepr Agent webhook | An endpoint that turns events from another system into investigations. |
+| Vector index | Storage for the agent memory search index. |
+
+To configure these, see [_](/integrations/llm), [_](/integrations/mcp), [_](/integrations/grepr-agent-webhooks), and [_](/ai-agents/memory#vector-index).
+
+Grepr adds integrations continuously. To get an agent connected to the provider you use, contact <support@grepr.ai>.
+
+## Supported integrations: observability platforms \[#supported-observability-integrations]
+
+A Grepr integration provides the configuration details needed to connect to an external system, such as an observability platform. Integrations support moving data into Grepr and between Grepr and external systems by enabling the creation of sources and sinks in your Grepr pipelines.
+
+Some integrations support the automatic creation of exceptions based on information returned by vendor tools. These exceptions ensure that Grepr passes through important messages without aggregation. For some integrations, this feature is available when the integration is enabled as a *cloud source*, which allows Grepr to read and process data from the external service. To learn more, see [Identify log events that should bypass aggregation](/integrations#passthrough-estimation)
+
+The following are the observability platform and tool integrations supported by Grepr as data sources and sinks:
+
+| Integration | As source | As sink | Exception parsing |
+| --- | --- | --- | --- |
+| Datadog | Yes | Yes | Yes. See [Enable Datadog selective reduction](/integrations/datadog#enable-selective-reduction). |
+| New Relic | Yes | Yes | Yes. See [Enable New Relic selective reduction](/integrations/new-relic#enable-selective-reduction). |
+| Splunk | HEC, HTTP | HEC only | No |
+| Google Cloud Platform | Yes | No \[^gcpsink] | Not applicable \[^gcpep] |
+| Grafana Cloud | Yes | Yes | No |
+| OpenTelemetry | Yes | Yes | Not applicable |
+| Sumo Logic | Yes | Yes | No |
+| Amazon S3 \[^awsstorage] | Yes | No | Not applicable |
+
+\[^gcpsink]: Although Grepr supports streaming data from GCP, you cannot use GCP as a sink. Instead, you configure a supported sink for the output from your Grepr pipeline. To learn more, see [Google Cloud Platform observability with Grepr](/integrations/gcp). \[^gcpep]: Because the exception parsing feature is configured as a separate step in your pipeline, support for this feature is based on the sink configured on the pipeline. \[^awsstorage]: The support mentioned in this table is for reading from arbitrary files in Amazon S3 and writing to files in arbitrary formats, such as JSON or plain text. To learn about using S3 as data lake storage, see [Host a Grepr data lake with the Amazon S3 integration](/integrations/aws-s3).
+
+## Frequently Asked Questions
+
+### Which observability platforms can I use as sources in Grepr?
+
+Grepr supports the following platforms as sources: Datadog, Splunk (HEC and HTTP), Google Cloud Platform, Grafana Cloud, New Relic, OpenTelemetry, Sumo Logic, and Amazon S3. Each platform provides different capabilities for ingesting data into Grepr pipelines.
+
+### Which observability platforms can I use as sinks in Grepr?
+
+Grepr supports the following platforms as sinks: Datadog, Splunk (HEC only, not HTTP), Grafana Cloud, New Relic, and OpenTelemetry. Note that GCP and Amazon S3 have specific limitations: GCP cannot be used as a sink, and S3 supports arbitrary format writing but not Iceberg data lake functionality.
+
+### What is exception parsing in Grepr integrations?
+
+Exception parsing is a feature that automatically creates exceptions from information returned by vendor tools, ensuring that important messages pass through without aggregation. This feature is supported by Datadog and Splunk integrations, and is available when the integration is enabled as a cloud source.
+
+### Does Grepr support OpenTelemetry?
+
+Yes, Grepr supports OpenTelemetry as both a source and a sink. You can use the OpenTelemetry Protocol (OTLP) to ingest data from compatible collectors or output processed logs to platforms like Grafana Cloud that accept OTLP data.
+
+### What is the difference between Splunk HEC and HTTP support?
+
+Splunk HEC (HTTP Event Collector) is supported for both source (reading) and sink (writing) operations. Splunk HTTP support is available as a source only. When configuring a Splunk sink, use the HEC integration for data output.
+
+### Can I use Google Cloud Platform (GCP) as a data sink?
+
+No, GCP cannot be used as a sink in Grepr pipelines. While Grepr supports streaming logs from GCP sources, for data output you must configure a different supported sink such as Datadog, Splunk, New Relic, Grafana Cloud, or OpenTelemetry.
+
+### How does exception parsing work with GCP integrations?
+
+Exception parsing for GCP is not applicable as a direct feature. Instead, the exception parsing feature is configured as a separate step in your pipeline, and support is based on the sink you configure for your pipeline output.
+
+### What cloud storage options does Grepr support?
+
+Grepr supports Amazon S3 for storing and querying raw data in the Grepr data lake. You can use either a Grepr-hosted S3 integration or configure your own S3 bucket in your AWS account. S3 can also be used as a source for reading arbitrary files in any format.

package/build/dist/docs-index/80198dde-08e6-4b47-ac48-5d17a8195f1f.txt

@@ -0,0 +1,79 @@
+Learn how Grepr integrates with Datadog, Splunk, New Relic, and other platforms to reduce observability costs and provide real-time log processing and analysis.
+
+# What is Grepr?
+
+Grepr is an enterprise-grade data storage, processing, and analytics platform for your observability data. Grepr collects, transforms, and analyzes your log data and then sends the processed logs to your observability platform.
+
+Before sending log data to the destination platform, Grepr uses machine learning to analyze and intelligently aggregate the data. During normal operations, Grepr reduces your observability costs by reducing the volume of data sent to your observability tools, while retaining all of your raw data in low-cost cloud storage. If an incident or anomaly occurs, Grepr increases the granularity of the forwarded data to ensure that sufficient data is available for troubleshooting. Grepr also uses the raw data to backfill any historical data relevant to the incident.
+
+Grepr supports popular observability platforms, including Datadog, Splunk, New Relic, Sumo Logic, Grafana Cloud, and OpenTelemetry-compatible platforms.
+
+Grepr AI agents build on the same data. An agent examines your logs and pipeline configuration with the capabilities you grant it and reports what it found. Start an investigation yourself, or connect an agent to a pipeline or another system so it investigates on its own. To learn more, see [_](/ai-agents).
+
+If you're just getting started with Grepr, follow the **Get started** guides below. If you're already using Grepr and need information on creating pipelines to process logs or to query raw logs stored in Grepr, see the guides under **Process and explore your logs**. If you need to automate your Grepr tasks or implement clients that use Grepr features, or use JavaScript to code reusable components for your pipelines, see the **Developers** documentation.
+
+## Get started
+
+[Create your first pipeline](/tutorials/first-pipeline)
+
+[Learn about the platform](/grepr-platform)
+
+## Process and explore your logs
+
+[Connect to external tools](/integrations)
+
+[Process and transform data](/transforms)
+
+[Query logs in the data lake](/queries)
+
+[Grepr AI agents](/ai-agents)
+
+## Developers
+
+[Use the Grepr Rest API](/apis)
+
+[Use the Grepr CLI](/cli)
+
+[Custom pipeline components](/templates)
+
+## Frequently Asked Questions
+
+### What is Grepr?
+
+Grepr is an enterprise-grade data storage, processing, and analytics platform for observability data. It collects, transforms, and analyzes log data, then sends processed logs to your observability platform while retaining raw data in low-cost cloud storage.
+
+### How does Grepr reduce observability costs?
+
+Grepr uses machine learning to intelligently aggregate and reduce the volume of log data sent to your observability tools during normal operations, while automatically increasing data granularity during incidents. This significantly reduces costs while maintaining full raw data access.
+
+### What observability platforms does Grepr integrate with?
+
+Grepr supports popular platforms including Datadog, Splunk, New Relic, Sumo Logic, Grafana Cloud, and OpenTelemetry-compatible platforms.
+
+### What is the Grepr data lake?
+
+The Grepr data lake is a secure cloud storage layer built on Apache Iceberg and S3 that stores your raw log data. It provides efficient querying capabilities and serves as the foundation for historical analysis and incident backfills.
+
+### Can I query raw logs in Grepr?
+
+Yes, you can query raw logs stored in the Grepr data lake using the query interface or REST API. The data lake supports powerful queries with tags, time ranges, and custom filters to analyze historical log data.
+
+### How do I create a Grepr pipeline?
+
+You can create pipelines using the Grepr UI, REST API, or CLI. Pipelines consist of data sources, transformations (like log reduction and parsing), and destinations. Follow the 'Create your first pipeline' guide to get started.
+
+### What happens to my data during an incident?
+
+During incidents or anomalies, Grepr automatically increases the granularity of forwarded data to ensure sufficient detail for troubleshooting. It also backtransfers historical raw logs relevant to the incident from the data lake.
+
+### Is my data secure in Grepr?
+
+Yes, Grepr maintains a SOC 2 Type II report and a HIPAA attestation, and implements enterprise security controls including encryption in transit (TLS 1.2+) and at rest, role-based access controls, and secure identity management with Auth0.
+
+### Can I use Grepr with my existing observability tools?
+
+Yes, Grepr is designed to integrate seamlessly with existing observability platforms. You continue using your current tools while Grepr handles data reduction and optimization in the background.
+
+### How can I automate Grepr tasks?
+
+You can automate tasks using the Grepr REST APIs, CLI, or custom JavaScript components in pipelines. The CLI supports job creation, queries, integration management, and dataset operations.

package/build/dist/docs-index/8114f427-fbd9-470d-9bad-b0831559e129.txt

@@ -0,0 +1,168 @@
+Turn on Grepr AI agent memory so an agent records what it concluded, counts recurrences, and searches past investigations during a new one.
+
+# Remember past investigations
+
+Without memory, every investigation starts from nothing. An agent that diagnosed a problem last week reaches the same conclusion the same slow way this week, and nobody learns that the problem has now happened five times.
+
+*Memory* changes that. An agent with memory enabled records what it concluded when it reaches a diagnosis, recognizes when a later investigation reaches the same conclusion and counts the recurrence, and searches those records at the start of a new investigation to find out whether it has seen this before.
+
+Both halves show up in the investigation's tool calls. A memory search runs near the start, before the agent has looked at anything else, and the record is written at the end, when it has a diagnosis.
+
+The agent decides what to record and whether something is a recurrence. Grepr does not extract conclusions on its behalf or merge records by similarity, because the investigating agent is the only thing that saw the evidence.
+
+Memory is off until you turn it on and choose where the memories are stored.
+
+## What an agent records \[#what-recorded]
+
+An agent records at most one memory per investigation, written when it reaches a diagnosis rather than after the fact. Each memory holds:
+
+| Field | What it holds |
+| --- | --- |
+| Title | A short name for the problem. |
+| Symptoms | What was observed. |
+| Root cause | What the agent concluded was responsible. |
+| Root cause confidence | Whether the cause is **confirmed**, **suspected**, or **unknown**. |
+| Ruled out | Causes the agent checked and eliminated, so a later investigation does not repeat that work. |
+| Resolution | What resolved it, or what was attempted. |
+| Significance | How much the conclusion matters. See [Significance](#classification). |
+| Entity tags | The services, pipelines, and environments the memory is about. See [Entity tags](#tagging). |
+| Recurrence count | How many investigations reached this same conclusion. |
+
+An agent can correct its own memory for an investigation while that investigation is running, so an early diagnosis it later disproves does not stay on the record. Correcting a memory does not count as a new recurrence.
+
+### Significance \[#classification]
+
+Significance is how an agent classifies what it found, and it decides how the memory can be found later:
+
+| Significance | Meaning |
+| --- | --- |
+| Incident | A real problem was identified. |
+| Observation | Not a problem, but a conclusion worth keeping. |
+| Inconclusive | The agent could not determine whether there was a problem. |
+| Benign | Triaged as no problem. |
+
+Benign memories are recorded but not indexed for search by meaning or by text. They are reachable only by a timeline search over their entity tags. This keeps the large number of routine all-clear findings out of the way of searches for real problems, at the cost of making them harder to find. If you want an agent to notice that a given service has been triaged as benign many times, search the timeline for that service rather than searching by text.
+
+## Turn on memory \[#enable]
+
+Memory needs somewhere to store its search index and a model to build that index with, so there are three things to set up.
+
+### Step 1: Create a vector index integration \[#vector-index]
+
+1. On the **Integrations** page, next to the **S3 Vector Index** section heading, click **Add new**.
+2. In the **Add Vector Index** dialog, enter a **Name** and the number of **Dimensions** the embedding model you plan to use produces, then click **Create**.
+
+The dimensions must match the model's output, so choose the embedding model first and use its dimension count. An index's dimensions are fixed after creation.
+
+### Step 2: Create an embedding integration \[#embedding-integration]
+
+Memory embeds each record with a model from an LLM integration that provides embeddings. If you do not have one, create it before you continue. See [_](/integrations/llm).
+
+An agent's reasoning model and its embedding model are separate choices. An agent can reason with one integration and embed with another.
+
+### Step 3: Turn on memory for the agent \[#agent-memory]
+
+1. On the agent's page, go to the **Memory** step.
+2. Turn on **Remember past investigations**.
+3. Under **Storage**, select the **Vector index integration**, the **Embedding credentials**, and the **Embedding model**.
+4. Save the agent.
+
+Grepr creates the search index when you create the vector index integration in Step 1, and discards the integration if the index cannot be created. Saving the agent then checks that the embedding model actually works against that index, by embedding a test value with it. So a wrong model or an unusable credential stops the save rather than surfacing later as memories that were never indexed.
+
+### Choose an embedding model and keep it \[#embedding-model]
+
+A memory is embedded with the model the agent had when it was recorded, and a query can only be compared against embeddings from the same model. Changing an agent's embedding model therefore cuts its new memories off from the ones it already recorded, as far as searching by meaning is concerned. Treat the choice as long lived.
+
+Using the same model across several agents does not pool their memories into one semantic search. A search by meaning always targets one agent, as described next.
+
+## How an agent searches its memory \[#search-modes]
+
+A search runs in exactly one of three modes, and which mode fits depends on what the agent is trying to find:
+
+| Mode | What it finds | Use it to answer |
+| --- | --- | --- |
+| Semantic | Investigations whose conclusions mean something similar to the query. | Has a problem like this happened before? |
+| Text | Investigations mentioning specific words, using full-text search. | Has this exact error string or identifier come up before? |
+| Timeline | Investigations about given entities, ordered by time. | What has been happening to this service recently? |
+
+Semantic search finds a past incident described in different words, which text search misses. Text search finds a literal, such as an error code or a host name, which semantic search can rank poorly. Timeline search needs entity tags rather than a query, and it is the only mode that returns benign memories.
+
+The modes also differ in how much they cover, which matters when you read an empty result:
+
+* A semantic search covers one agent at a time, because a query is only comparable against embeddings made with that agent's model. An empty semantic result means nothing similar was found within what the search could reach. It is not evidence that the agent recorded nothing similar, and it is not evidence that your organization has not seen the problem. A memory embedded with a model the agent no longer uses is unreachable until it is embedded again, and a search that cannot reach the embedding provider returns empty as well. When an empty result matters, confirm it with a text or timeline search, which read the records directly.
+* A text or timeline search covers every agent in your organization by default, so it is the one to use when you want the organization's whole history.
+
+So to find out whether any agent has seen something, search by text or timeline, or repeat the semantic search against each agent you care about.
+
+A result carries the memory's content along with its recurrence count, how long ago it was recorded, when it was last seen, and whether it is active, recent, or historical. There is no relevance score, because the agent judges from the content and the provenance rather than a ranking number.
+
+Search returns at most 50 results and has no pagination, so a broad query can be incomplete. Narrowing by entity tags or by significance is more effective than raising the limit.
+
+## Entity tags \[#tagging]
+
+Entity tags are what make memories findable by the thing they are about, such as a service, a pipeline, or an environment. Each memory carries two kinds:
+
+* Tags Grepr derives from the triggering signal, which identify the source and the signal type.
+* Tags the agent adds, which name the entities it concluded the memory is about.
+
+Grepr derives its tags using a mapping per signal type, which extracts values from the signal payload by path. The shipped mappings cover the common cases:
+
+| Signal type | Tags derived from the signal |
+| --- | --- |
+| Log pattern | The pipeline, the pattern, and the service, environment, and Kubernetes namespace from the sample log event. |
+| Webhook | The integration, and the service and host from the payload. |
+| Manual | The signal type only. |
+
+The webhook mapping reads the service and host from field names Grepr expects. If your payloads name those fields differently, add a mapping so the tags resolve. On the agent's **Memory** step, under **Entity tags**, add a mapping for the signal type, then add each tag key with the paths to read it from. Grepr tries the paths in order and uses the first that resolves.
+
+Consistent tag values matter more than complete ones. A service tagged `checkout` in some memories and `checkout-svc` in others splits its history in two, and a timeline search finds only half. Grepr gives an agent the tag values already in use in your organization when it searches, so an agent that searches before recording reuses existing values rather than inventing new ones.
+
+## Who can read and write memories \[#scope]
+
+* Reads are organization-wide. Any agent can search any other agent's memories in your organization. Operational history is only useful shared, so an agent investigating a service finds what another agent concluded about the same service. Permission is uniform across the modes, but coverage is not: a semantic search still examines one agent at a time. See [How an agent searches its memory](#search-modes).
+* Writes are owner-only. A memory can be written or corrected only by the agent that ran the investigation, so one agent cannot overwrite another's conclusions.
+
+When an agent finds that a past memory describes what it is now seeing, it links its investigation to that memory, which raises the recurrence count rather than creating a near-duplicate record. Each contributing investigation counts once.
+
+Memories outlive the agent that wrote them. Deleting an agent leaves its memories searchable by your other agents.
+
+## Search memories from the CLI \[#cli]
+
+The Grepr CLI searches the same memories an agent does, which is how you read what your agents have concluded.
+
+```bash
+# Find investigations mentioning a literal string
+grepr investigation:memory:search --mode text --query "connection refused" --limit 5
+
+# Find investigations whose conclusions are similar in meaning
+grepr investigation:memory:search --mode semantic --agent-id <agent-id> --query "intermittent ingestion failures"
+
+# See what has been happening to one service lately
+grepr investigation:memory:search --mode timeline --entity-tag entity:service=checkout
+```
+
+A semantic search needs an agent id, because a query can only be compared inside the index that agent embeds into. Text and timeline searches cover every agent in your organization by default. Timeline searches need at least one entity tag.
+
+The CLI is how you read what your agents have concluded outside of an investigation. To learn more about the CLI, see [_](/cli).
+
+## Frequently Asked Questions
+
+### What does Grepr AI agent memory store?
+
+One memory per investigation, holding a title, the symptoms, the root cause and the agent's confidence in it, the causes it ruled out, the resolution, a significance classification, entity tags, and a count of how many investigations reached the same conclusion.
+
+### What do I need to turn on agent memory?
+
+Three things: a vector index integration whose dimensions match your embedding model, an LLM integration that supplies the embedding model, and the embedding model name. Grepr creates the search index when you create the vector index integration. Saving the agent then checks that the embedding model works against that index, so a wrong model stops the save.
+
+### How does an agent search its memory?
+
+In one of three modes. Semantic search finds conclusions that mean something similar to the query, and covers one agent at a time. Text search finds specific words, such as an error code. Timeline search finds memories about given entities ordered by time, and is the only mode that returns benign memories. Text and timeline searches cover every agent in the organization by default.
+
+### Can one Grepr AI agent read another agent's memories?
+
+Yes, permission is organization-wide, so any agent can search any other agent's memories in your organization. Coverage differs by mode: text and timeline searches span every agent by default, while a search by meaning targets one agent at a time, because a query is only comparable against embeddings made with that agent's model. Writes are owner-only.
+
+### How do I read what my agents have remembered?
+
+Search them with the grepr investigation:memory:search command, choosing text, semantic, or timeline mode, or read them in an investigation that searched them. The Memory step of an agent holds the settings rather than the records.

package/build/dist/docs-index/8826ac11-0c7a-447a-b650-9cd8669860d7.txt

@@ -0,0 +1,33 @@
+# Get parsed alert query impacts for an integration and dataset
+
+**GET** `/v1/integrations/{integrationId}/exceptions/impacts`
+
+**Operation ID**: `getIntegrationExceptionImpactsByDataset`
+**Summary**: Get parsed alert query impacts for an integration and dataset
+Returns the estimated percentage of the dataset's raw log volume each of the integration's parsed alert queries matches, with the time that estimate was measured. Queries that have not been estimated are absent from the response rather than reported as zero. The dataset must be one of those returned by the estimation-datasets endpoint for this integration.
+
+## Tags
+- Integration Exceptions
+## Parameters
+
+- **integrationId** (required) - path
+  - Integration id
+  - Type: string
+- **datasetId** (required) - query
+  - Dataset the estimates are scoped to
+  - Type: string
+
+## Responses
+
+### 200
+
+Impact estimates retrieved
+
+- **Content-Type**: `application/json` / object
+### 401
+
+Unauthorized
+
+### 404
+
+Not Found - Integration not found, or the dataset is not reachable from it.

package/build/dist/docs-index/8d5ac858-019f-4b52-b81b-e90ffe5ec96f.txt

@@ -0,0 +1,34 @@
+# Import an integration's parsed queries now
+
+**POST** `/v1/integrations/{integrationId}/parsed-queries/import`
+
+**Operation ID**: `importParsedQueries`
+**Summary**: Import an integration's parsed queries now
+Reads the integration's alert, monitor and dashboard queries from its vendor without waiting for the hourly import. One fetch is shared by every integration in the organization using the same vendor account, so this updates all of them. If an import is already under way this joins it rather than starting another. The import runs in the background; its result appears in the integration's activity log.
+
+## Tags
+- Integrations
+## Parameters
+
+- **integrationId** (required) - path
+  - Integration id
+  - Type: string
+
+## Responses
+
+### 200
+
+Import started, or already under way
+
+- **Content-Type**: `application/json` / `ParsedQueryImportStatus`
+### 401
+
+Unauthorized
+
+### 404
+
+Not Found - Integration not found.
+
+### 409
+
+Conflict - This vendor has no parsed queries to import, or the integration has no application key saved.