@grepr/cli 1.11.5-9face06 → 1.11.5-a7cb911

package/build/dist/docs-index/0b6cfb13-278d-4be0-80be-2904eb8dbe40.txt

@@ -0,0 +1,78 @@
+Two ways to send logs to several vendor accounts, by creating a pipeline for each group or by grouping the reducer and filtering each sink.
+
+# Route logs to several vendor accounts
+
+Your logs do not all belong in the same place. Separate teams, environments, or business units each own an account in your observability platform, and a log has to reach the account that owns it. Each account you send to is its own Grepr integration.
+
+A Grepr pipeline is a free-form processing graph rather than a fixed shape, so you can arrange this in more than one way. Here are two examples, and you can combine them.
+
+## Create a pipeline for each group \[#pipeline-per-group]
+
+Create one pipeline for each group of logs that belongs together, filter its source to that group, and give it the sink for that group's account.
+
+Each pipeline summarizes only its own logs, so you can tune each one on its own. Choose this when the groups need different configurations, or when you want them isolated from each other.
+
+To create a pipeline, see [_](/tutorials/first-pipeline). To limit what one ingests, see [_](/transforms/filter-events).
+
+## Group the reducer and filter each sink \[#grouped-sinks]
+
+Run a single pipeline, add a sink for each account, and filter each sink to that account's logs. Choose this when the groups have the same configuration, and you would rather manage one pipeline than several.
+
+Routing rests on a *routing key*, which is a field whose value names the account a log belongs to, such as `account` or `team`. Two settings act on it: the reducer groups on the key, and each sink filters on it.
+
+Grouping is what makes the filtering correct. A summary carries the values of the fields it was grouped on, so grouping on the routing key gives every summary exactly one account, and each sink's filter then matches its own account and no other.
+
+> Configure the grouping before you add the sinks, because leaving it out fails quietly. Without the routing key in the group-by, logs bound for different accounts aggregate together. A tag then carries every value the merged messages had, so every account receives the same summary, reporting counts that include the other accounts' logs. An attribute is merged instead, and the default merge strategy replaces values that differ with a wildcard, so no filter matches and the summary reaches no account.
+
+### Step 1: Put the routing key on every log \[#step1-routing-key]
+
+The routing key has to be on each log before the reducer sees it, holding one value per account. If your collectors already tag logs with the owning team or environment, use that tag. If the value is inside the message, parse it into an attribute or a tag first with the Grok parser or the JSON parser. See [_](/transforms/grok) and [_](/transforms/json-parsing).
+
+A tag and an attribute both work as the routing key. Choose one whose values are few and stable, because each value aggregates separately. Decide what happens to logs carrying no value for the key, which match no filter and so reach no account: give them a default value when you parse, or add a sink that catches them.
+
+### Step 2: Group the reducer on the routing key \[#step2-group]
+
+1. On the pipeline's **Reducer** step, click **Edit** on the **Fields** card.
+2. If the routing key is listed, set its **Behaviour** to **Match or split**.
+3. If it is not listed, enter it in the **Add field** row, set the **Behaviour** to **Match or split**, and click **Add**.
+4. Click **Save**.
+
+The **Match or split** behavior keeps a field out of aggregation, so messages whose values differ are never merged into one pattern. Enter tag keys plainly, and prefix attribute paths with `@`. An attribute is merged as well as grouped, and the default merge strategy keeps the value that every message in the group agrees on. If you set a different merge strategy for the routing attribute, check that it preserves that value rather than combining or discarding it. See [_](/transforms/reducer/configuration#attribute-configuration).
+
+### Step 3: Create a Grepr integration for each account \[#step3-integrations]
+
+Create one Grepr integration for each account you send to. An integration authenticates to a single account, so its credential is what decides where its logs land. Name each integration after its account, because that name is what you select when you add the sink. See [_](/integrations).
+
+### Step 4: Add a filtered sink for each account \[#step4-sinks]
+
+Repeat for each account:
+
+1. On the pipeline's **Sinks** step, click **Add sink**.
+2. In the **Sink** menu, select the integration for the account. Grepr fills in a **Name**, which you can change.
+3. In the **Query language** menu, select the syntax you want to write the filter in.
+4. In the **Filter Query** field, enter a query that matches only that account's logs, such as `team:platform`.
+5. Click **Add**, then save the pipeline.
+
+A sink with an empty filter forwards everything, so give each sink a filter query that matches it to one account. A sink's card reports its filter and shows **All messages** when it has none, which is how you spot one you missed. The filter runs on everything the reducer emits, so summaries, samples, passthrough messages, and exceptions all follow the same routing. To learn about the filter syntax, see [_](/queries/datadog) and [_](/queries/new-relic).
+
+## Frequently Asked Questions
+
+### Can one Grepr pipeline send logs to several accounts of the same vendor?
+
+Yes. Add one sink for each account, each pointing at that account's integration, and give each sink a filter that matches only that account's logs. Group the reducer on the same routing key the filters use, so that each summary belongs to exactly one account.
+
+### Why does the reducer need to group on the routing key?
+
+Without it, logs for different accounts aggregate together and the summary no longer identifies one account. If the key is a tag, the summary carries every value the merged messages had, so each account's filter matches it and every account receives counts that include the other accounts' logs. If the key is an attribute, the default merge strategy replaces the differing values with a wildcard, so no filter matches and the summary reaches no account.
+
+### Should I create a pipeline for each account or filter the sinks of one pipeline?
+
+Create a pipeline for each group when the groups need different reduction settings or different exceptions, or when you want them isolated. Filter the sinks of one pipeline when the groups share one reduction policy and you would rather keep a single pipeline to change.
+
+### What happens to logs that have no value for the routing key?
+
+They match no sink's filter and reach no vendor account. Give them a default value when you parse the routing key, or add a sink whose filter matches them so they land somewhere you can see.
+
+### Does a sink filter apply to summarized logs as well as raw ones?
+
+Yes. The filter runs on everything the reducer emits, so summaries, samples, passthrough messages, and exceptions all follow the same routing.

package/build/dist/docs-index/0c4d7e11-f3f9-48db-99f3-2444833f92d0.txt

@@ -0,0 +1,21 @@
+Guides that work through common Grepr situations end to end, showing the ways you can configure a pipeline to solve each one.
+
+# Solution guides
+
+A solution guide works through a situation you are likely to meet in production, rather than a single feature. A Grepr pipeline is a free-form processing graph, so most situations have more than one good shape. Each guide states the problem, then walks through the ways you can configure Grepr for it.
+
+Use these guides when you know what you want to achieve but not yet how to shape your pipelines around it. To learn a feature on its own, see the reference documentation for [pipelines](/pipelines), [transforms](/transforms), and [integrations](/integrations). To work through the product step by step, see [_](/tutorials).
+
+## Route logs to several vendor accounts
+
+Your logs belong to more than one account in your observability platform, because separate teams, environments, or business units each own their own. This guide shows two ways to get each log, and each summary of those logs, to the account that owns it: a pipeline for each group, or one pipeline whose reducer groups on a routing key and whose sinks each filter on it. See [_](/solution-guides/route-logs-to-several-accounts).
+
+## Frequently Asked Questions
+
+### What is a Grepr solution guide?
+
+A solution guide works through a situation you are likely to meet in production rather than a single feature. A Grepr pipeline is a free-form processing graph, so most situations have more than one good shape. Each guide states the problem, then walks through the ways you can configure Grepr for it.
+
+### How is a solution guide different from a tutorial?
+
+A tutorial teaches the product step by step, starting from nothing. A solution guide assumes you know what you want to achieve and shows you the ways you can shape your pipelines around it.

package/build/dist/docs-index/{ac069a96-5867-4c97-89d1-682f98a9627d.txt → 0dc6b8d5-a4d4-48ac-a10a-7c58eb6d5878.txt}

@@ -1,8 +1,8 @@
-# query_1
+# query
 
 **POST** `/v1/metrics/query`
 
-**Operation ID**: `query_1`
+**Operation ID**: `query`
 **Summary**: No summary provided.
 ## Tags
 - Status Metrics

package/build/dist/docs-index/0df80b16-22c9-4059-8717-2f16eb618e3f.txt

@@ -0,0 +1,19 @@
+# AppKeyScopeCheck
+
+Whether a Datadog application key holds one authorization scope
+
+**Type**: `object`
+
+## Properties
+
+- name: required (optional)
+  type: boolean
+  description: Whether Grepr rejects an application key without this scope
+
+- name: scope (optional)
+  type: string
+  description: The Datadog authorization scope identifier
+
+- name: status (optional)
+  type: enum: `GRANTED`, `DENIED`, `UNKNOWN`
+  description: Whether the application key was found to hold a scope, or could not be checked

package/build/dist/docs-index/2171a011-c071-4cbf-aed8-56c7c12a75dd.txt

@@ -0,0 +1,15 @@
+# ExceptionImpact
+
+Estimated passthrough for one parsed alert query against one dataset
+
+**Type**: `object`
+
+## Properties
+
+- name: measuredAt (optional)
+  type: string
+  description: When the estimation run that produced this percentage completed. Absent when the age of the measurement is not known; that is not the same as freshly measured.
+
+- name: percentage (required)
+  type: number
+  description: Estimated percentage of the dataset's raw log volume this query matches. Honouring the query as a pipeline exception passes approximately this share of the data through without aggregation.

package/build/dist/docs-index/25b5c46b-80b2-409a-a4ed-bbbb0e1ef10e.txt

@@ -0,0 +1,124 @@
+Use the skills Grepr ships and write your own, so a Grepr AI agent loads the guidance and tools a task needs only when that task comes up.
+
+# Extend agents with skills
+
+A *skill* is a directory of instructions that an agent loads only when the task it covers comes up. Grepr ships a set of skills, and you can write your own for the procedures your organization follows.
+
+Skills exist because an agent's system prompt is read at the start of every investigation, so anything you put there costs tokens on every run whether it is relevant or not. Guidance that applies to one kind of task belongs in a skill. A skill can also carry the tools its task needs, which is why enabling one is often how you grant a capability rather than pinning the tool yourself.
+
+Skills are on the **Skills** page, which shares the left rail with **Agents**.
+
+## Skill scopes \[#scopes]
+
+| Scope | Where it comes from | Who can change it |
+| --- | --- | --- |
+| Platform | Maintained by Grepr and available to every agent. | Read only. |
+| Organization | Created and managed by you. | Anyone with the Edit permission on integrations. |
+
+The scope also changes how much a skill grants. To learn more, see [_](/ai-agents/capabilities#grant-scope).
+
+## Platform skills \[#platform]
+
+Grepr maintains a catalog of platform skills, available to every agent. Read the catalog on the **Skills** page, where each skill lists what it covers and which tools it grants. The catalog changes as Grepr adds skills, so treat the page as the authoritative list.
+
+The skills fall into three groups:
+
+* **Investigation approaches.** How to work through a kind of problem. Incident Response covers a log pattern the pipeline has just flagged, and Triage Security Pattern covers a first-seen pattern that might be security relevant.
+* **Pipeline changes.** How to change a pipeline safely. Test Pipeline Change is the safety procedure, which plans a change, reads the preview of the difference, and replays the investigation's own sample logs through the proposed pipeline before submitting it. Others cover a specific kind of change, such as tuning Grok parsing or authoring a SQL transform.
+* **Grepr reference and commands.** What an agent needs to know to use Grepr itself, such as the processing model, the operations reference, and how to query the data lake or read past investigations.
+
+Most agents want an investigation approach plus Test Pipeline Change. The approach gives the agent a way to work through its signals, and Test Pipeline Change stops it submitting a pipeline change it has not verified against real samples.
+
+> An agent proposes changes to a pipeline's Grok parsers and its SQL transforms. The catalog also holds skills for changes you make yourself with the Grepr CLI, such as masking and filtering, so a skill's presence does not by itself mean an agent will make that change. To learn more, see [_](/ai-agents/capabilities#tool-table).
+
+## Create an organization skill \[#create]
+
+1. On the **Skills** page, in the **Organization skills** section, click **Add New Skill**.
+2. Enter a **Display name**. Grepr derives the skill's identifier from this name, and the identifier must be unique across your organization's skills and the platform skills.
+3. Write the skill's files, starting with `SKILL.md` at the root. See [What SKILL.md must contain](#skill-md).
+4. Select the tools the skill needs under **Approved tools**. See [Approve the tools a skill needs](#approved-tools).
+5. Save the skill.
+
+Organize a skill the way you would a short runbook. Keep `SKILL.md` to the approach and put long reference material, such as a table of service names or an example payload, in separate files the agent reads when it needs them.
+
+### What SKILL.md must contain \[#skill-md]
+
+Every skill has a `SKILL.md` file at its root, and that file must begin with front matter containing a `description`:
+
+```markdown
+---
+description: How to respond to a checkout service latency alert - which dashboards to read, which dependencies to rule out, and when to page the on-call engineer. Use when a signal names the checkout service.
+---
+
+# Responding to checkout latency
+
+...
+```
+
+The description is the only part of a skill an agent reads before deciding whether the skill is relevant, so write it to answer two questions: what the skill covers, and when to use it. A description that only names the topic leaves the agent guessing, while one that ends with a sentence starting "Use when" tells it exactly when to load the skill. The description can be up to 1,024 characters.
+
+The body of `SKILL.md` is read after the agent loads the skill, so put the approach there.
+
+### Approve the tools a skill needs \[#approved-tools]
+
+The **Approved tools** field is what grants tools to an agent that enables this skill. Select only the tools the skill's procedure actually uses.
+
+> In an organization skill, the **Approved tools** field is what grants access. An `allowed-tools` entry in the front matter of your `SKILL.md` does not grant anything, so a skill whose front matter lists tools but whose **Approved tools** field is empty grants nothing.
+
+Each tool you approve grants its whole family to any agent that enables the skill, so approving a tool is a permission decision about the agent, not only about the skill. To keep the grant narrow, approve fewer tools. A skill that needs no tools at all grants none, and is safe to enable on any agent.
+
+## Enable a skill on an agent \[#enable]
+
+Enable skills on the agent's **Capabilities** step, where they are grouped into abilities, which carry tools, and reference skills, which carry only knowledge. To learn more, see [_](/ai-agents/capabilities#grepr-access).
+
+A skill takes effect on investigations that start after you save the agent.
+
+## Update a skill \[#update]
+
+Editing a skill replaces its whole directory, so the version you save is the version agents get. Grepr tracks a revision for each skill and refuses a save based on a revision that is no longer the latest, which stops one save overwriting another.
+
+Every agent with the skill enabled picks up the new revision on its next investigation, so a change to a widely enabled skill reaches many agents at once. Change a shared skill the way you would change shared code.
+
+## Delete a skill \[#delete]
+
+Grepr refuses to delete a skill that any active agent still has enabled. Remove it from each of those agents on their **Capabilities** step, then delete it.
+
+Deleting an organization skill archives it, and investigations that already ran keep their transcripts unchanged.
+
+An agent that loses a skill also loses the tools that skill granted, so before you remove a skill that carried tools, decide whether each agent still needs them and grant them another way if so. See [_](/ai-agents/capabilities#grepr-access).
+
+## Limits \[#constraints]
+
+| Limit | Value |
+| --- | --- |
+| Files in one skill | 25 |
+| Directories in one skill | 10 |
+| Directory levels below the root | 3 |
+| Characters in a file path | 240 |
+| Size of one file | 256 KiB |
+| Total size of one skill | 1 MiB |
+| Characters in a description | 1,024 |
+| Skills enabled on one agent | 20 |
+| Total size of the skills enabled on one agent | 8 MiB |
+
+## Frequently Asked Questions
+
+### What is a Grepr AI agent skill?
+
+A skill is a directory of instructions that an agent loads only when the task it covers comes up, and which can also grant the tools that task needs. Guidance that applies to one kind of task belongs in a skill rather than in the system prompt, which is read on every investigation.
+
+### What skills does Grepr provide?
+
+Grepr maintains a catalog of platform skills available to every agent, covering investigation approaches such as Incident Response, pipeline-change procedures such as Test Pipeline Change, and reference material about Grepr itself. Read the catalog on the Skills page, which is the authoritative list because it changes as Grepr adds skills.
+
+### How do I grant tools through my own skill?
+
+Select them in the Approved tools field on the skill. An allowed-tools entry in your SKILL.md front matter does not grant anything in an organization skill, so a skill whose front matter lists tools but whose Approved tools field is empty grants nothing.
+
+### What must a SKILL.md file contain?
+
+Front matter with a description of up to 1,024 characters. The description is the only part an agent reads before deciding whether the skill is relevant, so it should say what the skill covers and when to use it. The body holds the approach and is read after the agent loads the skill.
+
+### How many skills can one Grepr AI agent use?
+
+Up to 20 skills, with a combined size of 8 MiB. A single skill can hold 25 files across 10 directories, no more than 3 levels below the root, up to 256 KiB per file and 1 MiB in total.

package/build/dist/docs-index/2f23852f-6575-4435-af65-effb0fd73dc2.txt

@@ -0,0 +1,39 @@
+# Preview authorization scopes for unsaved changes to an integration
+
+**POST** `/v1/integrations/datadog/{id}/app-key/scopes/preview`
+
+**Operation ID**: `previewDatadogAppKeyScopes`
+**Summary**: Preview authorization scopes for unsaved changes to an integration
+Probes Datadog with the integration's stored keys, overridden by whatever the body supplies, and reports each authorization scope. Nothing is written. An omitted field means "use what is stored", so an empty body reports what the stored key can do right now. A scope whose probe does not complete is reported UNKNOWN rather than as a permission the user has to grant.
+
+## Tags
+- Datadog Integration
+## Parameters
+
+- **id** (required) - path
+  - Type: string
+
+## Request Body
+
+**Content-Type**: `application/json`
+
+**Schema**: `PreviewAppKeyScopesRequest`
+
+## Responses
+
+### 200
+
+Scopes checked successfully
+
+- **Content-Type**: `application/json` / array of `AppKeyScopeCheck`
+### 400
+
+The supplied site is not allowed for this organization.
+
+### 401
+
+Unauthorized
+
+### 404
+
+Integration not found.

package/build/dist/docs-index/377b490c-13c0-46a8-bc90-f0a1f5dffad0.txt

@@ -0,0 +1,116 @@
+Connect a model provider with a Grepr LLM integration, and cap how many tokens your agents consume per time window.
+
+# Configure LLM provider connections with a Grepr integration
+
+An LLM integration holds the credentials Grepr uses to call a large language model provider. Grepr AI agents can use LLM integrations for two purposes: a generative model used for reasoning, or an embedding model used for similarity analysis.
+
+An LLM integration can be assigned a token budget, which is a mechanism that caps the amount of tokens your agents can spend. When several agents share one integration, the budget applies to all of them together.
+
+> LLM integrations, along with the rest of the Grepr AI agent features, are in a closed beta. To request access, contact <support@grepr.ai>.
+
+## Requirements
+
+To create an LLM integration, you need:
+
+* The credential your provider requires, which is an API key for most providers, or a gateway URL and a key for the gateway.
+
+## Choose a provider \[#providers]
+
+An LLM integration serves one of two purposes, so create the one that matches what you need.
+
+For the model an agent reasons with, create an integration for your model provider. You can also create a gateway integration to route your agents through a gateway you run, which reaches whatever models you configure it with, so use one to choose the model yourself, apply your own routing rules, or keep model traffic inside your own infrastructure.
+
+For the embedding model that agent memory uses, create an integration for a provider that supplies embeddings. One integration can serve both purposes, so a single integration is often enough to run an agent with memory turned on.
+
+The **Type** menu in the **Add LLM** dialog lists the providers available to you.
+
+Don't see your provider in the list? Send a request to <support@grepr.ai>.
+
+## Create an LLM integration \[#create]
+
+1. On the **Integrations** page, next to the **LLMs** section heading, click **Add new**.
+2. In the **Add LLM** dialog, select the provider from the **Type** menu.
+3. Complete the remaining fields, which depend on the provider you selected.
+4. Click **Create**.
+
+You cannot change an integration's type after you create it. To move to a different provider, create a new integration and point your agents at it.
+
+Select the tab for your provider to see the fields it requires:
+
+| Field | Description |
+| --- | --- |
+| **Name** | A name for the integration, used to identify it when you configure an agent. |
+| **API Key** | Your Gemini API key. |
+| **Max tokens per window** | The total tokens that all agents using this integration can consume in each window. Leave empty for the default of 20,000,000. |
+| **Max tokens window (hours)** | The length of the budget window. Leave empty for the default of 1 hour. |
+
+A Gemini integration can serve as both an agent's model and the embedding model for agent memory.
+
+| Field | Description |
+| --- | --- |
+| **Name** | A name for the integration, used to identify it when you configure an agent. |
+| **Gateway URL** | The base URL of your LiteLLM proxy, such as `https://litellm.example.com/team-a`. Required. |
+| **Virtual key** | The LiteLLM virtual key Grepr authenticates with. |
+| **Validate virtual key when saving** | Turn this on to have Grepr verify the virtual key against the gateway before it saves the integration. |
+| **Max tokens per window** | The total tokens that all agents using this integration can consume in each window. Leave empty for the default of 20,000,000. |
+| **Max tokens window (hours)** | The length of the budget window. Leave empty for the default of 1 hour. |
+
+Grepr reaches whatever models your gateway exposes, so the model names available to an agent are the ones your LiteLLM configuration routes.
+
+| Field | Description |
+| --- | --- |
+| **Name** | A name for the integration, used to identify it when you configure an agent. |
+| **API Key** | Your OpenAI API key. |
+
+An OpenAI integration provides the embedding model that agent memory uses.
+
+## Cap token consumption with a budget window \[#max-tokens]
+
+An integration that serves an agent's model carries a token budget, which is what caps the spend of every agent sharing it. The budget has two settings:
+
+* **Max tokens per window** is the total tokens every agent sharing the integration can consume in one window.
+* **Max tokens window (hours)** is the length of that window. The value must divide 24 evenly, so the valid lengths are 1, 2, 3, 4, 6, 8, 12, and 24 hours. Windows are aligned to UTC.
+
+Before it starts an investigation, Grepr reserves the tokens that investigation is allowed to consume and checks the reservation against two budgets: the integration's budget, and the agent's per-window budget. Both must have room. An agent whose own budget is untouched still waits when the shared integration has none left, so when investigations stop starting, check which of the two is exhausted on the agent's page before you raise a limit. To learn more about the agent-level settings, see [_](/ai-agents/create-an-agent#limits).
+
+## Update an API key \[#update-key]
+
+To replace a key, click the three-dot menu on the integration card, select **Edit**, enter the new key, and click **Save**. Every agent using the integration picks up the new key automatically.
+
+## Grant team access \[#team-access]
+
+When you have teams in your Grepr organization, you can grant access to the integration to one or more of those teams. To configure team access when you create or edit an integration:
+
+1. In the **Grant Team Access** section, click the plus sign icon (+).
+
+2. Select the team or teams that should be granted access to the integration.
+
+3. Click **Create**.
+
+To learn more, see [Manage teams in the Grepr platform](/admin/manage-teams) and [Permissions in the Grepr platform](/grepr-platform/permissions).
+
+## View token usage \[#usage]
+
+Each LLM integration card on the **Integrations** page charts the tokens its agents consumed, broken down by token type, and shows how much of the budget window remains. The card totals every agent sharing the integration and lists which agents those are, so to see how much one agent is spending, open that agent's page.
+
+## Frequently Asked Questions
+
+### Which LLM providers can a Grepr AI agent use as its model?
+
+Create an LLM integration for your model provider, or a gateway integration to route your agents through a gateway you run, which reaches whatever models you configure it with. Use a gateway to choose the model yourself, apply your own routing rules, or keep model traffic inside your own infrastructure. The Type menu in the Add LLM dialog lists the providers available to you, and Grepr adds integrations continuously, so contact support\@grepr.ai to get connected to the provider you use.
+
+### Which LLM providers can Grepr use for agent memory embeddings?
+
+Create an LLM integration for a provider that supplies embeddings. One integration can serve as both an agent's reasoning model and its embedding model, so a single integration is often enough to run an agent with memory turned on.
+
+### How does Grepr cap the tokens my AI agents consume?
+
+An LLM integration that serves an agent's model carries a max-tokens budget and a window length in hours that must divide 24 evenly. Grepr reserves an investigation's tokens up front and requires room in both the shared integration budget and the agent's own per-window budget before the investigation starts.
+
+### Can I change an LLM integration's provider after creating it?
+
+No. The type is fixed when you create the integration. To move to a different provider, create a new integration and point your agents at it.
+
+### Why have my agent's investigations stopped starting?
+
+The most common cause is an exhausted token budget. Because several agents can share one LLM integration, the shared budget can run out while the agent's own budget is untouched. The agent's page reports which of the two blocked the investigation and when the window resets.

package/build/dist/docs-index/{55141aa4-12cd-425a-a6de-37e8a0d48c0c.txt → 3bb6f221-fe39-4d59-8849-2454c9408d39.txt}

@@ -38,6 +38,14 @@ API key is invalid
 
 No such webhook integration
 
+### 409
+
+The integration has no live target agent to start
+
 ### 413
 
 Body exceeds the size limit
+
+### 503
+
+At least one target agent could not be started for a transient reason; retry

package/build/dist/docs-index/46bee073-d1da-460a-8058-3371bdb7ecb8.txt

@@ -0,0 +1,30 @@
+# Get parsed-query import state
+
+**GET** `/v1/integrations/{integrationId}/parsed-queries/import`
+
+**Operation ID**: `getParsedQueryImportStatus`
+**Summary**: Get parsed-query import state
+Says whether this vendor's parsed queries can be imported, whether the credential the import needs is saved, whether an import is already under way, and which integrations an import covers. Poll this while an import is running; what it imported is reported in the integration's activity log.
+
+## Tags
+- Integrations
+## Parameters
+
+- **integrationId** (required) - path
+  - Integration id
+  - Type: string
+
+## Responses
+
+### 200
+
+State retrieved
+
+- **Content-Type**: `application/json` / `ParsedQueryImportStatus`
+### 401
+
+Unauthorized
+
+### 404
+
+Not Found - Integration not found.

package/build/dist/docs-index/4d4bf567-ce50-417b-a390-b3648f5fc7b6.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/{0d67622d-249a-4f51-bb4d-f4aa29fb6fae.txt → 4eb23965-58ac-4215-b4f5-c880606eb961.txt}

@@ -20,15 +20,19 @@ To modify the configuration settings in the UI, on the overview page for your pi
 
 ## 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.
+Grouping 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]
+### Group messages by a field \[#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.
+Messages are aggregated separately for each unique combination of values across the fields you group on, so patterns from different services, hosts, or other dimensions are never merged. Grouping on `service`, `host`, and the `http.url.path` attribute aggregates messages independently for each unique combination of those three values.
 
-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.
+To group on a field, on the pipeline's **Reducer** step, click **Edit** on the **Fields** card, find the field, and set its behavior to **Match or split**. A field with this behavior is kept out of aggregation, so messages whose values for it differ are never merged into one pattern.
 
-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).
+Attribute paths are written with an `@` prefix and dot notation for nested attributes, such as `@http.url.path`. Tag keys are written as the key name alone.
+
+Use grouping to retain the values of important fields by excluding them from aggregation, such as high-cardinality identifiers like user IDs. To keep a field that is currently inside the message, parse it into an attribute or a tag with the **JSON Parser** or **Grok Parser** step earlier in the pipeline, then group on that 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).
+
+Grouping also decides how a summary can be routed, because a summary carries the tag values of the fields it was grouped on. To use grouping to send each group's logs to a different destination, see [_](/solution-guides/route-logs-to-several-accounts).
 
 ### Similarity threshold (%)
 
@@ -165,6 +169,16 @@ The **Default Strategy** section defines the strategies that apply to every attr
 
 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.
 
+## Send new-pattern signals to AI agents \[#agent-signals]
+
+The reducer identifies the patterns in your logs, which also makes it the first place a pattern that has never occurred before becomes visible. You can have the pipeline report each new pattern to your Grepr AI agents, so an agent investigates behavior that is new in your systems without you writing an alert for it first.
+
+To turn this on, on the reducer step of your pipeline, open the **Advanced** settings and select **Emit new-pattern signals to AI agents**.
+
+Turning it on emits nothing by itself. A signal reaches an agent only when that agent is subscribed to the pipeline, and Grepr refuses a subscription to a pipeline that has this setting off. So turn it on first, then subscribe the agent.
+
+Each pattern signals an agent once rather than on every occurrence, for as long as the reducer keeps that pattern in its state, so a pattern that keeps matching does not keep starting investigations. To learn how signals reach an agent and how to bound the volume, see [_](/ai-agents/subscriptions).
+
 ## Frequently Asked Questions
 
 ### What is the aggregation window?

package/build/dist/docs-index/{e6b7631c-8e9e-4ddb-b0d0-c9d3ae113996.txt → 526ccc55-f9d2-4c41-a262-d015245efa36.txt}

@@ -11,7 +11,7 @@
   type: `ReadOrgConstraints`
 
 - name: featureFlags (optional)
-  type: array of enum: `DATADOG_BROWSER_LOGS_INTEGRATION`, `METRICS_SOURCE`, `S3_LOGS_FILE_SOURCE`, `PIPELINE_TEMPLATES`, `AI_WORKFLOWS`, `SEARCH_ICEBERG_SOURCE`, `QUERY_JOBS`, `AUTH0_SSO_CONNECTION`, `TRINO_QUERY_ENGINE`, `UNKNOWN`
+  type: array of enum: `DATADOG_BROWSER_LOGS_INTEGRATION`, `METRICS_SOURCE`, `S3_LOGS_FILE_SOURCE`, `PIPELINE_TEMPLATES`, `AI_WORKFLOWS`, `SEARCH_ICEBERG_SOURCE`, `MULTI_GROK_PARSER`, `AUTH0_SSO_CONNECTION`, `TRINO_QUERY_ENGINE`, `UNKNOWN`
 
 - name: name (required)
   type: string

package/build/dist/docs-index/{2f63d822-1e38-48c5-998d-605beff95555.txt → 53dd6ada-3829-4870-b457-ff7d00572982.txt}

@@ -4,7 +4,7 @@
 
 **Operation ID**: `getIntegrationExceptionImpacts`
 **Summary**: Get integration exception impacts for a pipeline
-Returns the per-exception impact percentages the runtime auto-sync threshold filter would compare against for this pipeline/integration pair. The pipeline's sink dataset scopes the lookup; exceptions without an estimation row are absent from the response.
+Returns the per-exception impact percentages the runtime auto-sync threshold filter would compare against for this pipeline/integration pair, each with the time that estimate was measured. The pipeline's sink dataset scopes the lookup; exceptions without an estimation row are absent from the response rather than reported as zero.
 
 ## Tags
 - Pipeline Exceptions

package/build/dist/docs-index/{e6fde1fa-7f5b-4681-8b18-3252ffb7b4a9.txt → 5d6475c3-87cd-4d1d-a385-043a27ad815d.txt}

@@ -62,6 +62,8 @@ You can use the LogTransformAction in the REST API to specify actions that trans
 
 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.
 
+Sending logs to different destinations, rather than processing them differently, is a separate problem with its own approaches. See [_](/solution-guides/route-logs-to-several-accounts).
+
 You can also use the REST API to create more complex pipeline configurations. See [LogsBranch](/apis/api-spec#schema/LogsBranch).
 
 ## Frequently Asked Questions

package/build/dist/docs-index/609faadc-6e7f-4b3a-a0c5-d579a1d54958.txt

@@ -0,0 +1,19 @@
+# PreviewAppKeyScopesRequest
+
+Unsaved changes to check Datadog authorization scopes against
+
+**Type**: `object`
+
+## Properties
+
+- name: apiKey (optional)
+  type: string
+  description: API key to probe with instead of the stored one
+
+- name: appKey (optional)
+  type: string
+  description: Application key to check instead of the stored one
+
+- name: site (optional)
+  type: string
+  description: Site to probe instead of the stored one

package/build/dist/docs-index/{e8472eee-d8cf-4d01-9b66-c6692276fa68.txt → 60d4c246-3ebc-4e67-999d-61ea99d865b8.txt}

@@ -25,6 +25,10 @@ Creates an app key for a Datadog integration if it doesn't exist and updates it
 
 App key upserted successfully.
 
+### 400
+
+App key is missing a required authorization scope.
+
 ### 401
 
 Unauthorized

package/build/dist/docs-index/{0fc3b3f2-f1dd-49c3-9fff-3f959724d932.txt → 61a3fb16-1562-401e-8983-bb0a355ae035.txt}

@@ -4,6 +4,8 @@
 
 **Operation ID**: `archive`
 **Summary**: Archive an organization skill
+## Tags
+- Skills
 ## Parameters
 
 - **id** (required) - path