@grepr/cli 1.13.0-2632478 → 1.14.3-a181b29

package/build/dist/docs-index/3a314999-5e4a-4469-be5c-27311bff0ae2.txt

@@ -1,244 +0,0 @@
-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/3a513d77-f5df-46c3-b8e1-48259e63f508.json

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

package/build/dist/docs-index/3a513d77-f5df-46c3-b8e1-48259e63f508.txt

@@ -1,13 +0,0 @@
-# AttributeKeyTermNode
-
-**Type**: `object`
-
-## Properties
-
-- name: attribute (required)
-  type: string
-  description: The string that is matched against the attribute key.
-
-- name: type (required)
-  type: enum: `attribute-key-term-node`
-  description: A node that represents an attribute key in a parsed query.

package/build/dist/docs-index/3a9816df-cef9-400c-a8c8-d1642d12d377.json

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

package/build/dist/docs-index/3a9816df-cef9-400c-a8c8-d1642d12d377.txt

@@ -1,17 +0,0 @@
-# GreprPipeLogSink
-
-Writes log events into a Grepr pipe integration.
-
-**Type**: `object`
-
-## Properties
-
-- name: integrationId (required)
-  type: string
-  description: Destination Grepr pipe integration in the pipeline's organization.
-
-- name: name (required)
-  type: string
-
-- name: type (required)
-  type: enum: `grepr-pipe-log-sink`

package/build/dist/docs-index/3a9fbc1b-4ff0-4a42-8afa-26b05a2b6be5.json

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

package/build/dist/docs-index/3a9fbc1b-4ff0-4a42-8afa-26b05a2b6be5.txt

@@ -1,23 +0,0 @@
-# Get an invitation by id
-
-**GET** `/v1/invitations/{id}`
-
-**Operation ID**: `getInvitation`
-**Summary**: Get an invitation by id
-## Tags
-- Invitations
-## Parameters
-
-- **id** (required) - path
-  - Type: string
-
-## Responses
-
-### 200
-
-Invitation retrieved successfully
-
-- **Content-Type**: `application/json` / `ReadInvitation`
-### 401
-
-Unauthorized

package/build/dist/docs-index/3aaf03be-1d5c-4607-97f0-aefef73e3a37.json

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

package/build/dist/docs-index/3aaf03be-1d5c-4607-97f0-aefef73e3a37.txt

@@ -1,33 +0,0 @@
-# Get service account details
-
-**GET** `/v1/service-accounts/{id}`
-
-**Operation ID**: `getServiceAccount`
-**Summary**: Get service account details
-Gets the details of a specific service account
-
-## Tags
-- Service Accounts
-## Parameters
-
-- **id** (required) - path
-  - Type: string
-
-## Responses
-
-### 200
-
-Service account retrieved successfully
-
-- **Content-Type**: `application/json` / `ServiceAccountRead`
-### 401
-
-Unauthorized
-
-### 403
-
-Forbidden
-
-### 404
-
-Service account not found

package/build/dist/docs-index/3b1c5d2e-2a93-4f77-af53-53fd438e41bb.json

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

package/build/dist/docs-index/3b1c5d2e-2a93-4f77-af53-53fd438e41bb.txt

@@ -1,138 +0,0 @@
-Understand the data processing models, data models, and abstractions used by Grepr jobs, the types of Grepr jobs, processing modes for jobs, and the jobs lifecycle.
-
-# The Grepr processing and data models
-
-At its core, Grepr is powered by a robust data processing engine that executes *jobs*. These jobs process individual units of data, called *events*.
-
-## Log event model
-
-Grepr uses a data model that makes it easy for you to conceptualize. Log events in Grepr support both structured and unstructured data. The unstructured part is stored in a top-level field called `message` while all structured data is under `attributes`. Additional labels or tags that can be used to identify the source of data and do quick filtering is under `tags`.
-
-Grepr pipeline operators operate on this data model. When using the UI, most of the details of the model are abstracted away. When using the API, you need to understand the model well to build a well-functioning pipeline.
-
-Each log event has the following properties:
-
-* **`id`**: A globally unique id that identifies the log event.
-* **`receivedTimestamp`**: Timestamp when Grepr received the event.
-* **`eventTimestamp`**: Timestamp when the event occurred, usually parsed from the event itself.
-* **`tags`**: A set of key-value pairs that can be used to filter and route events. Some of the commonly used tags are `host`, `service`, `environment`, etc. This is a map from a string key to a set of string values.
-* **`attributes`**: Structured data and fields that are associated with the event. These could be sent with the event from the source or extracted by Grepr from the message.
-* **`message`**: The log message itself.
-* **`severity`**: The severity of the log message. This is an integer, following the OpenTelemetry convention of 1-4 for `TRACE`, 5-8 for `DEBUG`, 9-12 for `INFO`, 13-16 for `WARN`, 17-20 for `ERROR`, and 21-24 for `FATAL`. Severity is usually sent along with the message, but may be parsed from the event too.
-
-An example log event in JSON would look like:
-
-```json
-{
-  "id": "0H19GZK97FTKS",
-  "eventTimestamp": "2024-08-21T04:21:14.062Z",
-  "receivedTimestamp": "2024-08-21T04:21:14.188Z",
-  "severity": 9,
-  "message": "State backend is set to heap memory",
-  "tags": {
-    "app": "greprdev-0gvrs39hhft9q",
-    "kube_ownerref_kind": "deployment",
-    "source": "grepr-query",
-    "organizationId": "greprdev",
-    "service": "grepr-query",
-    "pod_phase": "running",
-    "host": "ip-10-12-4-129.ec2.internal",
-    "image_tag": "0.1.0-3421150",
-    "container_id": "b743c4b78b8ec25c6c73ea03de443ebe19acf760d293dc4145bd31170768a216"
-  },
-  "attributes": {
-    "process": {
-      "thread": {
-        "name": "thread-0"
-      }
-    },
-    "ecs": {
-      "version": "1.2.0"
-    },
-    "timestamp": 1724214074114,
-    "status": "info"
-  }
-}
-```
-
-## Grepr job model \[#grepr-job-model]
-
-All processing within Grepr is a *job*. Each job has a name, a desired state, a current state, and a job graph that describes the data sources, sinks, and the transformations on the data between the sources and sinks. These jobs can:
-
-* Ingest data continuously from various kinds of agents.
-* Execute queries on the Grepr data lake and return the result to the user.
-* Backfill data from the Grepr data lake back to observability vendors.
-
-### The job graph \[#grepr-job-graph]
-
-Each job is a directed acyclic graph (DAG), consisting of vertices and edges. Vertices can be sources, sinks, or transforms. We often refer to vertices in the graph as operators as well. The Grepr UI abstracts away much of the complexity of job management into an app-like experience, so learning the details of these operators and how they work are not necessary.
-
-Each operator may have 0 or more inputs and outputs. Sinks have no outputs while sources have no inputs. All transforms have at least 1 input and 1 output. Many operators will require an integration to work, such as the Iceberg sink or Datadog source.
-
-### Job execution \[#grepr-job-execution]
-
-Jobs have two properties that describe how they are executed: `Execution` and `Processing`.
-
-#### Execution
-
-Jobs have two execution modes: `SYNCHRONOUS` and `ASYNCHRONOUS`. Synchronous jobs are executed immediately and their result is streamed back to the caller. Asynchronous jobs are submitted and run in the background. The results of an asynchronous job end up in a preconfigured sink.
-
-#### Processing
-
-Jobs have two processing modes: `STREAMING` and `BATCH`. Streaming jobs execute continuously on the data as it arrives. They will continue running until they are stopped. Batch jobs have a bounded amount of data that arrives from the sources, which they will read and process, and then they will complete.
-
-When we mention "pipeline" in the docs, we mean `ASYNCHRONOUS` `STREAMING` jobs that will continuously receive data from a source, process it, and then deliver it to one or more sinks. Queries on the other hand are usually `SYNCHRONOUS` `BATCH` jobs that will return a result to the caller, although they can be `ASYNCHRONOUS` `BATCH` jobs too, such as backfill jobs.
-
-### Job lifecycle
-
-Jobs also have a lifecycle. The lifecycle of batch and streaming jobs are different. Batch jobs are submitted, processed, and then completed. Streaming jobs, on the other hand, have a long lifetime and will be running until they are stopped. However, they might need to be reconfigured, upgraded, stopped, and restarted for various reasons over their lifetimes, so their lifecycles are more complex.
-
-A user will specify the desired state for the job, and Grepr will try to make the current state of the job match the desired state. Grepr will automatically start, stop, reconfigure, and restart jobs as needed.
-
-### Autoscaling
-
-Streaming jobs automatically scale up and down to handle an increase or decrease in load and align execution cost with need. Batch jobs automatically execute at an optimal level of parallelism to reduce latency without sacrificing efficiency.
-
-During scale-up or scale-down periods for streaming jobs, there may be a few seconds of data processing delay, during which the pipeline is switching from the old deployment to the new deployment. At the same time, there may be an increase in data lag when there's an increase in load until the pipeline scales up to handle the increase. We aim to keep this lag to less than 5 minutes of delay in the worst case.
-
-## Frequently Asked Questions
-
-### What is a log event in Grepr?
-
-A log event in Grepr is a data unit containing unstructured message data and structured attributes. Each log event has a unique id, receivedTimestamp (when Grepr received it), eventTimestamp (when the event occurred), tags for filtering and routing, attributes for structured data fields, the message itself, and a severity level following OpenTelemetry conventions.
-
-### How are log events structured in Grepr?
-
-Log events support both structured and unstructured data. The unstructured message is stored in a top-level field called 'message', while all structured data is under 'attributes'. Labels or tags that identify the data source and enable quick filtering are stored under 'tags'. This model makes it easy to process logs whether they come in structured or unstructured form.
-
-### What are the different components of a log event?
-
-A log event includes: id (unique identifier), receivedTimestamp (when Grepr received it), eventTimestamp (when it occurred), tags (key-value pairs for filtering), attributes (structured data fields), message (the log text), and severity (following OpenTelemetry 1-24 scale). Each component serves a specific purpose in processing and analyzing the log.
-
-### What is a Grepr job?
-
-A Grepr job is a unit of processing work with a name, desired state, current state, and a job graph describing data sources, sinks, and transformations. Jobs can ingest data continuously from agents, execute queries on the data lake, or backfill data from the data lake to observability vendors. All processing within Grepr is implemented as jobs.
-
-### What is a job graph?
-
-A job graph is a directed acyclic graph (DAG) consisting of vertices and edges. Vertices can be sources (no inputs), sinks (no outputs), or transforms (at least 1 input and 1 output). The job graph describes the data flow from sources through transformations to sinks. The Grepr UI abstracts away the complexity of job graphs into an app-like experience.
-
-### What is the difference between streaming and batch processing?
-
-Streaming jobs execute continuously on data as it arrives and run until stopped, making them ideal for ongoing pipeline operations. Batch jobs have bounded input data from sources, process it, and then complete. Pipelines are typically asynchronous streaming jobs, while queries are usually synchronous batch jobs that return results to the caller.
-
-### What are execution modes in Grepr?
-
-Jobs have two execution modes: Synchronous jobs execute immediately and stream results back to the caller, while asynchronous jobs are submitted and run in the background with results delivered to a preconfigured sink. The choice of execution mode depends on whether you need immediate results or background processing.
-
-### How does job autoscaling work?
-
-Streaming jobs automatically scale up and down to handle increases or decreases in load and align execution cost with need. Batch jobs automatically execute at optimal parallelism levels to reduce latency without sacrificing efficiency. During scaling transitions, there may be a few seconds of processing delay, with a worst-case data lag target of less than 5 minutes.
-
-### What is the lifecycle of a Grepr job?
-
-Jobs have a lifecycle where you specify the desired state and Grepr works to match the current state to it. Batch jobs are submitted, processed, and complete. Streaming jobs have longer lifespans and may be reconfigured, upgraded, stopped, and restarted. Grepr automatically manages job state transitions and handles the complexity of job lifecycle management.
-
-### How does severity work in the Grepr data model?
-
-Severity is an integer following OpenTelemetry conventions: 1-4 for TRACE, 5-8 for DEBUG, 9-12 for INFO, 13-16 for WARN, 17-20 for ERROR, and 21-24 for FATAL. Severity is usually sent with the message from the source but may also be parsed from the event itself during processing.

package/build/dist/docs-index/3baa80b1-8c2d-4602-a3c7-55ee6334ca1e.json

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

package/build/dist/docs-index/3baa80b1-8c2d-4602-a3c7-55ee6334ca1e.txt

@@ -1,33 +0,0 @@
-# Reject a pending agent suggestion
-
-**POST** `/v1/agent-suggestions/{id}/reject`
-
-**Operation ID**: `reject`
-**Summary**: Reject a pending agent suggestion
-Marks a pending suggestion REJECTED, recording the reviewer. Returns 409 when the suggestion was already resolved by another reviewer.
-
-## Tags
-- Agent Suggestions
-## Parameters
-
-- **id** (required) - path
-  - Type: string
-
-## Responses
-
-### 200
-
-Suggestion rejected successfully
-
-- **Content-Type**: `application/json` / `AgentSuggestion`
-### 401
-
-Unauthorized
-
-### 404
-
-Suggestion not found
-
-### 409
-
-Suggestion is no longer pending

package/build/dist/docs-index/3bdebeb6-edbe-4b01-bd66-d9f86538b705.json

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

package/build/dist/docs-index/3bdebeb6-edbe-4b01-bd66-d9f86538b705.txt

@@ -1,14 +0,0 @@
-# PublicUpdate
-
-**Type**: `object`
-
-## Properties
-
-- name: accessConfig (optional)
-  type: `AccessConfig`
-
-- name: comments (optional)
-  type: string
-
-- name: plan (required)
-  type: `Plan`

package/build/dist/docs-index/3c0e3900-a079-4331-8b17-76e8ede3efd1.json

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

package/build/dist/docs-index/3c0e3900-a079-4331-8b17-76e8ede3efd1.txt

@@ -1,34 +0,0 @@
-# Create a new custom role
-
-**POST** `/v1/roles`
-
-**Operation ID**: `createRole`
-**Summary**: Create a new custom role
-Creates a new custom role with specified permissions
-
-## Tags
-- Roles
-## Request Body
-
-**Content-Type**: `application/json`
-
-**Schema**: `CreateRole`
-
-## Responses
-
-### 201
-
-Role created successfully
-
-- **Content-Type**: `application/json` / `Role`
-### 400
-
-Invalid request data
-
-### 403
-
-Insufficient permissions
-
-### 409
-
-Role name already exists

package/build/dist/docs-index/3c1d3365-49dc-414e-80ad-658861a6ca30.json

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

package/build/dist/docs-index/3c1d3365-49dc-414e-80ad-658861a6ca30.txt

@@ -1,37 +0,0 @@
-# Update a template
-
-**PUT** `/v1/templates/{id}`
-
-**Operation ID**: `updateTemplate`
-**Summary**: Update a template
-Updates a template by ID. The previous version is tombstoned.
-
-## Tags
-- Templates
-## Parameters
-
-- **id** (required) - path
-  - Type: string
-
-## Request Body
-
-The updated template.
-
-**Content-Type**: `application/json`
-
-**Schema**: `Template`
-
-## Responses
-
-### 200
-
-Template updated successfully
-
-- **Content-Type**: `application/json` / `Template`
-### 400
-
-Template not found
-
-### 401
-
-Unauthorized

package/build/dist/docs-index/3c8abc71-b46d-434c-93f6-4609d738a64f.json

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

package/build/dist/docs-index/3c8abc71-b46d-434c-93f6-4609d738a64f.txt

@@ -1,5 +0,0 @@
-# JsonNode
-
-A partial templateInputs object to deep-merge into the pipeline's current inputs. Objects merge recursively, and an array of named objects (like input.parsers) merges by entry name, so entries you omit are kept. Scalars and arrays of non-objects replace whole.
-
-**Type**: `object`

package/build/dist/docs-index/3cd151d1-fa30-4123-91ec-2cbc07ca67f7.json

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

package/build/dist/docs-index/3cd151d1-fa30-4123-91ec-2cbc07ca67f7.txt

@@ -1,11 +0,0 @@
-# AgentRecentHealth
-
-**Type**: `object`
-
-## Properties
-
-- name: completed (optional)
-  type: integer
-
-- name: failed (optional)
-  type: integer

package/build/dist/docs-index/3cd9278e-68ff-481a-b5d5-dc03576fc315.json

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