@grepr/cli 1.8.5-ca825ac → 1.8.6-7c73069

package/build/dist/docs-index/adccc9b0-cd9f-4b35-81e0-7e9c3049e657.txt

@@ -0,0 +1,244 @@
+Learn how to use the Grepr Splunk integration to ingest logs to a Grepr pipeline for processing and send the processed logs to your Splunk instance.
+
+# Configure Splunk connections with a Grepr integration
+
+The Grepr Splunk integration enables you to ingest logs into Grepr using a Grepr source, process the logs with a Grepr pipeline, and then send the processed logs to Splunk using a Grepr sink.
+
+The Grepr Splunk integration supports forwarding data through the following interfaces:
+
+* **Splunk's HTTP Event Collector (HEC)**: You can use any collector that supports HEC, including Fluent Bit, Fluentd, and the Splunk OpenTelemetry Collector.
+* **S2S over HTTP**: You can forward data from Splunk Universal Forwarders or Splunk Heavy Forwarders using S2S over HTTP. S2S over TCP is not supported.
+
+To send logs to a Grepr pipeline before forwarding them to your Splunk instance, change your collector configuration to send the logs to a Grepr endpoint URL rather than a Splunk HEC or S2S endpoint.
+
+In addition to using a Splunk integration to ingest log data with a Grepr source and send processed logs to Splunk with a Grepr sink, you can also use a Splunk HTTP source to ingest data from a Splunk instance into Grepr for processing. See [Ingest log data from Splunk using the Splunk HTTP source](#splunk-http-source).
+
+You can use the Grepr UI or REST API to add a Splunk integration. To learn how to create a Splunk integration in the Grepr UI and configure collectors to send logs to Grepr, see [Use a Splunk integration in a Grepr pipeline](#use-splunk-integration).
+
+To use the REST API, see the [Splunk Integration specification](/apis/api-spec#tag/Splunk-Integration).
+
+> Although this page describes using an integration to create a pipeline for sourcing and sending data with a single observability platform, your pipelines can use multiple integrations to source and sink data for different platforms. For example, you can create a pipeline with a Datadog integration that's used to source data from Datadog agents, and a Splunk integration and sink that sends the pipeline output to Splunk.
+
+## Requirements \[#splunk-requirements]
+
+The Grepr integration for Splunk requires the following:
+
+* An HTTP Event Collector (HEC) token is required for both HEC and S2S. You can create an HEC token in the Splunk platform settings. See [Set up and use the HTTP Event Collector in Splunk Web](https://docs.splunk.com/Documentation/Splunk/latest/Data/UsetheHTTPEventCollector).
+* A Bearer token for authentication to the Splunk REST API is required for using a Splunk HTTP source to ingest data from a Splunk instance into Grepr. The user associated with the token must have the `search` and `rest_access_server_endpoints` capabilities. See [Ingest log data from Splunk using the Splunk HTTP source](#splunk-http-source).
+
+For details on creating tokens for the Splunk API, see [Create authentication tokens](https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/9.4/authenticate-into-the-splunk-platform-with-tokens/create-authentication-tokens).
+
+## Use a Splunk integration in a Grepr pipeline \[#use-splunk-integration]
+
+Use the following steps to create a Splunk integration in the Grepr UI and use it in a pipeline to source and sink data.
+
+### Step 1: Create a Splunk integration \[#create-splunk-integration]
+
+To create a Splunk integration in the Grepr UI:
+
+1. Go to the **Integrations** page in the Grepr UI and click **Add new** next to **Observability Vendors**.
+
+2. In the **Add Observability Vendor** dialog:
+
+   * In the **Type** menu, select **Splunk** .
+   * In the **Name** field, enter a name for the integration.
+   * In the **Ingest Auth token** field, enter your Splunk HEC token.
+   * In the **Splunk Host** field, enter the hostname for your Splunk instance.
+   * Optional: To use an HTTP source to ingest data, in the **REST API Search Bearer token** field, enter a Bearer token to authenticate against the Splunk API. The token must be associated with a user with the required permissions. See the [Requirements](#splunk-requirements).
+   * Optional: Use the **Validate SSL certificate** checkbox to turn validation of SSL certificates on or off when Grepr connects to your Splunk instance.
+
+3. Click **Create**.
+
+   #### Optional: Grant team access to the integration
+
+   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).
+
+### Step 2: Add a source to your pipeline \[#add-splunk-source]
+
+To add a source to your pipeline that uses the Splunk integration:
+
+1. In the Grepr UI, go to the details page for an existing pipeline or create a new pipeline from the homepage.
+2. In the left-hand navigation menu on the pipeline details page, click **Sources**.
+3. In the **Add source** dialog, select the Splunk integration in the **Source** menu.
+4. Click **Submit**.
+
+### Step 3: Forward logs to Grepr using HEC
+
+To send data to Grepr, you configure your collector or agent to send it to the ingestion URL for your Grepr integration, rather than to your observability vendor's platform. To find the ingestion URL when using the Grepr UI to configure your pipeline, go to the details page for the pipeline, click **Sources** in the left pane, and copy the **Ingest URL**.
+
+
+
+If you connect to Grepr through AWS PrivateLink, copy the private ingestion URL and use it in place of the public ingestion URL. To learn more about sending data to Grepr over AWS PrivateLink, see [Securely forward observability data to Grepr with AWS PrivateLink](/admin/private-link).
+
+When you use the API, you can construct the ingestion URL using the following format:
+
+`https://<integration-id>-<org-id>.ingest.grepr.ai/services/collector/event`
+
+Replace `<integration-id>` with the identifier of the vendor integration used by your pipeline and replace `<org-id>` with the identifier for your organization.
+
+To use the PrivateLink endpoint service, insert `.private` after the `ingest` host segment.
+
+Although all sources created from the same integration share the same ingestion URL, you can use a single integration to create sources for multiple pipelines. The Grepr platform ensures events are routed to the correct pipelines.
+
+To see more information and configuration examples, select the tab for your preferred collector:
+
+Fluent Bit can forward logs using the Splunk output plugin. To configure the plugin, set the `Host` value to the hostname from the Splunk integration's ingestion URL and the `Splunk_Token` value to your Splunk HEC token. The following is an example `OUTPUT` section from a Fluent Bit configuration file (`fluent-bit.conf`):
+
+```fluent
+[OUTPUT]
+   Name              splunk
+   Match             *
+   Host              <ingestion-host>
+   Port              443
+   TLS               On
+   TLS.Verify        On
+   Splunk_Token      <hec-token>
+```
+
+Replace:
+
+* `<ingestion-host>` with the hostname from your ingestion URL. Do not include the `https://` prefix or the path value. For example, if the ingestion URL is `https://0abc1defghij2-<org-id>.ingest.grepr.ai/services/collector/event`, set the value to `0abc1defghij2-<org-id>.ingest.grepr.ai`.
+* `<hec-token>` with your Splunk HEC token.
+
+To learn more about configuration settings for Fluent Bit, see the documentation for the [Fluent Bit Splunk output plugin](https://docs.fluentbit.io/manual/pipeline/outputs/splunk).
+
+Fluentd can send logs to Grepr using the `splunk_hec` output plugin. When you configure Fluentd, split the ingestion URL into the `hec_host`, `hec_port`, and `hec_endpoint` settings. The following is an example `match` directive from a Fluentd configuration file (`fluentd.conf`):
+
+```fluent
+<match your_tag.**> # Adjust your match pattern as needed
+  @type                     splunk_hec
+  protocol                  https
+  hec_host                  <ingestion-host>
+  hec_endpoint              services/collector/event
+  hec_port                  443
+  hec_token                 <hec-token>
+
+  <buffer> # Grepr recommends creating a buffer configuration for production deployments
+    @type memory # Or file for persistence
+    flush_interval 5s # Adjust as needed
+    chunk_limit_size 1m # Adjust as needed
+  </buffer>
+</match>
+```
+
+Replace:
+
+* `your_tag.**` with the tag of the logs you want to forward to Grepr, or use `**` to match all tags.
+* `<ingestion-host>` with the hostname from your ingestion URL. Do not include the `https://` prefix or the path value. For example, if the ingestion URL is `https://0abc1defghij2-<org-id>.ingest.grepr.ai/services/collector/event`, set the value to `0abc1defghij2-<org-id>.ingest.grepr.ai`.
+* `<hec-token>` with your Splunk HEC token.
+
+To learn more about the Splunk output plugin for Fluentd, including configuration settings, see the [fluent-plugin-splunk-hec documentation](https://github.com/splunk/fluent-plugin-splunk-hec#readme).
+
+The OpenTelemetry Collector can forward logs to Grepr using the `splunk_hec` exporter. In the OpenTelemetry collector configuration (`collector.yaml`), set the `endpoint` value to the ingestion URL:
+
+```yaml
+exporters:
+  splunk_hec:
+    token: <hec-token>
+    endpoint: <ingestion-url>
+
+service:
+  pipelines:
+    logs:
+      receivers: [otlp] # Replace with your actual receiver(s)
+      processors: [batch] # Replace/add your actual processor(s)
+      exporters: [splunk_hec]
+```
+
+Replace:
+
+* `<hec-token>` with your Splunk HEC token.
+* `<ingestion-url>` with the ingestion URL from your Splunk integration.
+
+To learn more about the OpenTelemetry Collector and configuration settings, see the [Splunk HEC Exporter documentation](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/splunkhecexporter#readme).
+
+To forward logs using the Splunk Universal Forwarder or Heavy Forwarder, add an `[httpout]` section to your Splunk Heavy Forwarder or Universal Forwarder outputs configuration (`outputs.conf`) with the following settings:
+
+* Set `httpEventCollectorToken` with an HEC token from your Splunk settings.
+* Set `uri` to the hostname of the ingestion URL from your Grepr source. Omit the path from the ingestion URL and append the port `443`. The following is an example of a properly formatted value for the `uri` setting: `https://q0yf61xl3k2b1-orgid.app.grepr.ai:443`.
+
+```ini
+[httpout]
+httpEventCollectorToken = <hec-token>
+uri = https://<ingestion-host>:443
+```
+
+To load the new configuration, restart your forwarders.
+
+### Step 4: Add a sink to your pipeline
+
+To add a sink to your pipeline that uses the Splunk integration to send processed logs to your Splunk instance:
+
+1. In the Grepr UI, go to the details page for your pipeline.
+
+2. In the left-hand navigation menu, click **Sinks**.
+
+3. In the **Add sink** dialog:
+
+   * Select the Splunk integration in the **Sink** menu.
+   * In the **Name** field, enter a name for the integration.
+   * In the **Additional tags** field, specify comma-separated tags to add to all log messages sent through this sink. You can use these tags to filter and organize logs in Splunk. For example: `processor:grepr,pipeline:my_pipeline,environment:production`.
+
+4. The **Index Configuration** section allows you to configure how logs are routed to Splunk indexes. Grepr follows a specific index routing logic to determine the destination index for each log:
+
+   * **Index override takes priority**: If an **Index override** value is provided, all logs flowing to this sink will use this index, regardless of any other index information.
+   * **Log-level index field**: If no **Index override** value is provided and an `index` field exists on the log (from an agent or transformations), that index is used.
+   * **Sink default index**: If no **Index override** value is provided, and no `index` field exists on the log, the **Default index** field specified in this sink configuration is used.
+   * **HEC token default**: If none of these conditions are met, the log is routed to the default index configured on the HEC token in your Splunk instance.
+
+5. Click **Submit**.
+
+## Ingest log data from Splunk using the Splunk HTTP source \[#splunk-http-source]
+
+You can use the Splunk HTTP source to read log data from a Splunk instance into Grepr. You can use this feature for tasks such as moving Splunk logs to another platform or testing Splunk log processing in Grepr without modifying forwarders.
+
+To configure and use a Splunk HTTP source in a pipeline:
+
+1. Create a Splunk integration that includes an authorization token for the Splunk REST API. See [Step 1: Create a Splunk integration](#create-splunk-integration).
+2. In your pipeline, add a server source that uses the Splunk integration. See [Step 2: Add a source to your pipeline](#add-splunk-source).
+
+## Limitations
+
+* The Splunk integration supports only Splunk HEC and S2S over HTTP. TCP connections, including S2S over TCP, are not supported.
+
+## Frequently Asked Questions
+
+### How do I send logs from Splunk to Grepr for processing?
+
+To send logs from Splunk to Grepr, change your collector configuration to send logs to the Grepr ingestion URL instead of your Splunk HEC endpoint. The ingestion URL format is https\://\<integration-id>-\<org-id>.ingest.grepr.ai/services/collector/event. You can configure Fluent Bit, Fluentd, OpenTelemetry Collector, or Splunk Universal/Heavy Forwarders to use this endpoint.
+
+### What is the difference between HEC and S2S for Splunk integration with Grepr?
+
+HEC (HTTP Event Collector) is Splunk's standard HTTP-based log ingestion method supported by multiple collectors like Fluent Bit, Fluentd, and OpenTelemetry Collector. S2S (Source-to-Source) is Splunk's forwarding protocol for Universal Forwarders and Heavy Forwarders. Both are supported by Grepr over HTTP, but TCP connections including S2S over TCP are not supported.
+
+### How do I configure Fluent Bit to forward logs to Grepr with a Splunk integration?
+
+In your Fluent Bit configuration file, create an OUTPUT section with Name set to 'splunk', Host set to your Grepr ingestion hostname, Port set to 443, TLS enabled, and Splunk_Token set to your Splunk HEC token. The Host value should be the hostname portion of your ingestion URL without the https\:// prefix or path.
+
+### How can I configure index routing when sending processed logs back to Splunk?
+
+When adding a Splunk sink, Grepr follows a priority order for index routing: first, any Index override value; second, the index field on the log itself; third, the Default index specified in the sink configuration; finally, the default index configured on your HEC token. You can set an Index override to route all logs to a specific index regardless of other settings.
+
+### Can I use Splunk Universal Forwarder or Heavy Forwarder to send logs to Grepr?
+
+Yes, you can use S2S over HTTP with Splunk Universal Forwarder or Heavy Forwarder. Add an httpout section to your outputs.conf with the Grepr ingestion URL, an HEC token, and port 443. TCP connections are not supported, so ensure you use HTTP/HTTPS endpoints only.
+
+### What authentication is required for the Splunk integration with Grepr?
+
+You need an HEC (HTTP Event Collector) token from Splunk for both HEC and S2S connections. Additionally, for log reduction and exception parsing features, you need a Bearer token for the Splunk REST API with search and rest_access_server_endpoints capabilities.
+
+### How do I reduce storage costs with Grepr's Splunk integration?
+
+Use the log reducer feature by configuring a Bearer token in your Splunk integration. Grepr queries your Splunk instance for alerts and dashboards, then uses those insights to identify and exclude redundant log messages from processing. This can significantly reduce the volume of logs stored and processed.
+
+### Can I send logs to both Grepr and Splunk directly from my collectors?
+
+Yes, you can dual-ship logs using multiple OUTPUT sections in Fluent Bit or multiple exporters in Fluentd and OpenTelemetry Collector. This allows you to send unprocessed logs directly to Splunk while simultaneously sending logs to Grepr for processing and transformation.

package/build/dist/docs-index/ade7a113-7bd0-44f2-85e3-196b11710a8b.json

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

package/build/dist/docs-index/ade7a113-7bd0-44f2-85e3-196b11710a8b.txt

@@ -0,0 +1,20 @@
+# List all Anthropic integrations
+
+**GET** `/v1/integrations/anthropic`
+
+**Operation ID**: `list_1`
+**Summary**: List all Anthropic integrations
+Get all Anthropic integrations for your organization. This will contain masked API keys if present.
+
+## Tags
+- Anthropic Integration
+## Responses
+
+### 200
+
+Integrations retrieved successfully
+
+- **Content-Type**: `application/json` / `ItemsCollectionReadAnthropic`
+### 401
+
+Unauthorized

package/build/dist/docs-index/ae12554a-59ff-4f14-93b7-e9e38ef60e8b.json

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

package/build/dist/docs-index/ae12554a-59ff-4f14-93b7-e9e38ef60e8b.txt

@@ -0,0 +1,28 @@
+# Delete a dataset
+
+**DELETE** `/v1/datasets/{id}`
+
+**Operation ID**: `deleteDataset`
+**Summary**: Delete a dataset
+Delete the dataset.
+
+## Tags
+- Datasets
+## Parameters
+
+- **id** (required) - path
+  - Type: string
+
+## Responses
+
+### 200
+
+The dataset was deleted.
+
+### 404
+
+Dataset not found.
+
+### 409
+
+Dataset has jobs associated with it.

package/build/dist/docs-index/ae15592b-9234-4e90-95aa-8866fd54f1e0.json

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

package/build/dist/docs-index/ae15592b-9234-4e90-95aa-8866fd54f1e0.txt

@@ -0,0 +1,45 @@
+# EntityContextAggregation
+
+**Type**: `object`
+
+## Properties
+
+- name: capacity (optional)
+  type: integer
+  description: Maximum number of concurrent LLM calls per operator instance.
+
+- name: entityAttributes (optional)
+  type: array of string
+
+- name: entityTags (optional)
+  type: array of string
+
+- name: integrationId (required)
+  type: string
+  description: The LLM integration ID (Gemini or OpenAI).
+
+- name: llmConfig (required)
+  type: `LlmConfig`
+
+- name: maxRetries (optional)
+  type: integer
+  description: Maximum retries for failed LLM calls.
+
+- name: maxSummaryTokens (optional)
+  type: integer
+  description: Maximum token budget for the entity summary. The system prompt instructs the LLM to keep the summary within this bound.
+
+- name: name (required)
+  type: string
+
+- name: systemPromptOverride (optional)
+  type: string
+  description: Optional system prompt override. When null, a default system prompt is used that instructs the LLM to maintain a rolling entity summary and report whether the update is broadcast-worthy.
+
+- name: timeoutSeconds (optional)
+  type: integer
+  description: Timeout for LLM calls in seconds.
+
+- name: type (required)
+  type: enum: `entity-context-aggregation`
+  description: Maintains per-entity rolling context summaries using an LLM. Broadcasts significant updates for downstream prompt enrichment.

package/build/dist/docs-index/ae23abeb-9cdc-4df3-bf01-693dd2c5e8fc.json

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

package/build/dist/docs-index/ae23abeb-9cdc-4df3-bf01-693dd2c5e8fc.txt

@@ -0,0 +1,170 @@
+Use the Grepr rule engine REST API to dynamically control log processing with event triggers, conditions, and automated actions.
+
+# Control log processing with the rule engine REST API
+
+The rule engine can dynamically affect the processing of logs based on the provided context. For example, when an incident occurs, you might want to stop log aggregation and backfill previously aggregated data for a particular service over a period of time.
+
+See the [API specification](/apis/api-spec#schema/LogsRuleEngine).
+
+## Configure the rule engine
+
+To define rule engine actions, use the following configuration options:
+
+| Variables | Description |
+| --- | --- |
+| triggers | Map of trigger id to [trigger](#rule-engine-triggers) objects. The ids are a unique name for the trigger. |
+| conditions | Map of condition id to [condition](#rule-engine-conditions) objects. The ids are a unique name for the conditions. |
+
+### Example configuration
+
+Example definition of a rule engine as a vertex in the [Grepr job graph](/grepr-platform/grepr-model#grepr-job-graph):
+
+```json
+{
+  "name": "my-rule-engine",
+  "type": "rule-engine",
+  "triggers": {
+    "trigger1": {
+      "type": "event-predicate",
+      "predicate": {
+        "type": "datadog-query",
+        "query": "service:my-service"
+      },
+      "conditionIds": ["condition1"],
+      "duration": "5m",
+      "variables": {
+        "__host": "host" // Extracts host tag from the matching event
+      }
+    }
+  },
+  "conditions": {
+    "condition1": {
+      "actionRules": [
+        {
+          "type": "event-rule",
+          "actionPredicate": {
+            "type": "datadog-query",
+            "query": "host:__host" // Matches events with host tag value extracted from the event that fired trigger1
+          },
+          "actions": [
+            {
+              "type": "tag-action",
+              "order": 0,
+              "modification": "ADD",
+              "tagKey": "new-tag",
+              "values": ["new-value"] // Adds {new-tag: [new-value]} to tags
+            }
+          ]
+        },
+        {
+          "type": "job-rule",
+          "actions": [
+            {
+              "type": "backfill-job-action",
+              "name": "my_backfill_job",
+              "order": 1,
+              "backfillTimespan": "PT10M",
+              "jobTags": {
+                "job-type": "backfill"
+              },
+              "backfillQuery": { // Setting the query to define the context for the backfill
+                "type": "datadog-query",
+                "query": "host:__host"
+              },
+              "rawTableOperationName": "my_rawlogs_sink",
+              "dedupTableOperationName": "my_deduplogs_sink",
+              "sinkOperationName": "sink",
+              "limit": 50000
+            }
+          ]
+        }
+      ]
+    }
+  }
+}
+```
+
+## Condition \[#rule-engine-conditions]
+
+Conditions describe the state of the environment. When a condition is triggered, some actions can be taken by Grepr and, those are described by the condition itself. A condition has a duration, and actions can be taken when the condition starts or for all messages while the condition is ongoing depending on the type of the action.
+
+The actions are described in the condition as action rules. They can be of the following types:
+
+* `Event Action Rule`: This takes actions on events that match a certain predicate while the condition is active.
+* `Job Action Rule`: This executes a set of associated job actions when a condition is first triggered.
+
+### Event action rule
+
+This is executed on events that match a certain predicate, for the entire duration that the associated condition is active. The `Event Action Rule` is configured by specifying a predicate for matching events and a set of actions to take on matched events.
+
+As an example, the UI configures the rule engine and conditions such that, when there's an abnormal event or an external API call hits Grepr, events that are related to the incident are tagged with a special tag that tells the log reducer to skip aggregating them.
+
+### Job action rule
+
+A set of job actions that are executed **once** per associated condition. This means, if an already active condition is extended by the (re-)firing of a trigger, the job actions will not be executed again.
+
+As an example, the UI sets up the rule engine to kick off a backfill job when a trigger fires.
+
+## Trigger \[#rule-engine-triggers]
+
+A trigger kicks off a one or more conditions. Triggers may continue to fire, and that would extend the activation time of the associated conditions. Each trigger has a unique identifier and is one of these types:
+
+* `Event Trigger`: This trigger is activated by a matching predicate on an event. The predicate is provided by the user as part of the rule engine configuration.
+* `External Trigger`: This trigger is activated by an external source, for example, an alert from an observability tool. These will allow users to feed external stimuli into the rule engine to take appropriate actions.
+* `Trace Sampling Trigger`: This trigger allows users to make sure that complete sets of log messages would be available in the observability tool for a sample set of traces. A trace can be a user ID, a request ID, an actual trace ID, or anything that the user wants to consider an "execution identifier". This trace ID can be an attribute or a tag.
+
+You can find the object model specification for the various trigger types in the [API specification](/apis/api-spec#tag/Triggers).
+
+### Variables
+
+Variables are defined as part of the trigger configuration. These are used to extract values from the event that fired the trigger. The extracted values could be used as context for the conditions that are activated by the trigger. For example, if the trigger is activated by an event with a `service` tag, the `service` tag value could be extracted and used in the conditions to perform actions on the events that have the same `service` tag value.
+
+It's a map from variable names to paths for variables to extract from a matching event. The way to reference an attribute is by using an `@` in the variable path. For example, `@syslog.appname` will extract the value of the attribute `syslog.appname` from the event. If `@` is not specified, the variable will be extracted from the tags of the event. For example, the path `app` will extract the value of the tag `app` from the event.
+
+The variable names must start with '__' and be unique.
+
+> `__timestamp` (and `__severity` for logs) is automatically extracted from the respective top level fields of the matching event and are available for use in conditions out of the box.
+
+> If the path provided does not exist for a variable, the path itself will be taken as a literal value for the variable.
+
+## Frequently Asked Questions
+
+### What is the main purpose of the Grepr rule engine?
+
+The rule engine dynamically affects log processing based on provided context and defined conditions. When an incident occurs or external events trigger rules, the engine can automatically stop log aggregation, tag events, backfill data, or take other configured actions.
+
+### What is a trigger in the rule engine and what types are available?
+
+A trigger activates one or more conditions. Three trigger types exist: Event Trigger (activated by matching predicates on events), External Trigger (activated by external sources like observability platform alerts), and Trace Sampling Trigger (ensures complete log sets are available for sampled traces).
+
+### What is the difference between event-triggered and externally-triggered rules?
+
+Event-triggered rules automatically fire based on log data matching specified predicates (e.g., service:my-service). External triggers allow you to manually invoke rules from external systems, enabling incident response workflows driven by your observability platform.
+
+### How do conditions relate to triggers in the rule engine?
+
+Conditions are activated by triggers and define what actions to take when those conditions are active. A trigger can activate multiple conditions, and conditions can have a defined duration that extends if the trigger continues to fire.
+
+### What is the difference between event action rules and job action rules?
+
+Event action rules execute on events matching a predicate for the entire duration the condition is active. Job action rules execute once per condition (not repeatedly). Event action rules are ideal for tagging; job action rules are ideal for backfill jobs.
+
+### How do I extract values from events to use in conditions?
+
+Use variables defined in the trigger configuration. Variables map from names to paths, using @ prefix for attributes (e.g., @syslog.appname) or no prefix for tags (e.g., app). The __timestamp and __severity variables are automatically extracted.
+
+### Can I use extracted variables from triggers in action predicates?
+
+Yes, variables extracted from trigger events can be used in condition action predicates. For example, if you extract __host from a triggering event, you can use host:__host in action predicates to match events with the same host value.
+
+### What happens if a variable path doesn't exist in an event?
+
+If the specified path doesn't exist, the path itself is taken as a literal value for the variable. This allows you to use static values in rules as a fallback.
+
+### How do tag-action modifications work in the rule engine?
+
+Tag-action modifications can ADD tags to events. You specify the tagKey, values to add, and the order in which the action executes. For example, adding a new-tag:\[new-value] identifies events processed by specific rules.
+
+### What is a backfill-job-action and when would I use it?
+
+A backfill-job-action executes a backfill job when a condition triggers. It's useful for replaying historical data from a specific time period (backfillTimespan) for events matching the backfill query, helping with incident investigation.

package/build/dist/docs-index/aead4753-3006-4713-a90f-1ed9a4eed150.json

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