@grepr/cli 1.2.0 → 1.3.0-4e666db

package/build/dist/docs-index/1913bd37-ff5d-4fd3-8e6b-3e8f2dfbb208.txt

@@ -1,15 +0,0 @@
-# getUserPermissions
-
-**GET** `/v1/me/permissions`
-
-**Operation ID**: `getUserPermissions`
-**Summary**: No summary provided.
-## Tags
-- Users
-## Responses
-
-### default
-
-default response
-
-- **Content-Type**: `application/json` / `UserPermissionsResponse`

package/build/dist/docs-index/19e2c643-e1f3-4369-8865-545723ccac55.json

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

package/build/dist/docs-index/19e2c643-e1f3-4369-8865-545723ccac55.txt

@@ -1,32 +0,0 @@
-# Create a SumoLogic integration
-
-**POST** `/v1/integrations/sumo`
-
-**Operation ID**: `create_6`
-**Summary**: Create a SumoLogic integration
-Creates an integration to connect to SumoLogic.
-
-## Tags
-- Sumo Logic Integration
-## Request Body
-
-**Content-Type**: `application/json`
-
-**Schema**: `WriteSumo`
-
-## Responses
-
-### 200
-
-Integration created successfully
-
-- **Content-Type**: `application/json` / `ReadSumo`
-### 401
-
-Unauthorized
-
-### 409
-
-Integration already exists.
-
-- **Content-Type**: `application/json` / `ReadSumo`

package/build/dist/docs-index/1b47b126-a474-40a5-8edd-dd9dbb6e3719.json

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

package/build/dist/docs-index/1b47b126-a474-40a5-8edd-dd9dbb6e3719.txt

@@ -1,16 +0,0 @@
-# NewRelicLogAgentSource
-
-**Type**: `object`
-
-## Properties
-
-- name: name (required)
-  type: string
-
-- name: integrationId (required)
-  type: string
-  description: The integration id for the observability vendor.
-
-- name: type (required)
-  type: enum: `newrelic-log-agent-source`
-  description: Reads log events from Grepr's New Relic collection agent. This is used to pre-process logs before being sent to New Relic.

package/build/dist/docs-index/1dbb391f-2ad7-4573-aad0-4abbbf346a45.json

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

package/build/dist/docs-index/1dbb391f-2ad7-4573-aad0-4abbbf346a45.txt

@@ -1,8 +0,0 @@
-# Data
-
-**Type**: `object`
-
-## Properties
-
-- name: resultType (required)
-  type: string

package/build/dist/docs-index/1e26ed3c-b708-4b99-84c9-c720d5e8e4a2.json

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

package/build/dist/docs-index/1e26ed3c-b708-4b99-84c9-c720d5e8e4a2.txt

@@ -1,14 +0,0 @@
-# ParseResult
-
-**Type**: `object`
-
-## Properties
-
-- name: parseable (optional)
-  type: boolean
-
-- name: eventPredicateFn (optional)
-  type: string
-
-- name: errorMessage (optional)
-  type: string

package/build/dist/docs-index/1ec6b4bc-2dc6-4f1b-b83f-82980de3dbf0.json

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

package/build/dist/docs-index/1ec6b4bc-2dc6-4f1b-b83f-82980de3dbf0.txt

@@ -1,9 +0,0 @@
-# SumAttributesMergeStrategy
-
-**Type**: `object`
-
-## Properties
-
-- name: type (required)
-  type: enum: `sum`
-  description: SumAttributesMergeStrategy: Sums numeric attribute values.

package/build/dist/docs-index/1f7519bd-cc29-4fbb-9b18-ce1209691e6c.json

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

package/build/dist/docs-index/1f7519bd-cc29-4fbb-9b18-ce1209691e6c.txt

@@ -1,29 +0,0 @@
-# Get a S3 Data Warehouse integration
-
-**GET** `/v1/integrations/s3-data-warehouse/{id}`
-
-**Operation ID**: `get_2`
-**Summary**: Get a S3 Data Warehouse integration
-Gets an external S3 Data Warehouse integration
-
-## Tags
-- External S3 Data Warehouse Integration
-## Parameters
-
-- **id** (required) - path
-  - Type: string
-
-## Responses
-
-### 200
-
-S3 Data Warehouse integration retrieved successfully
-
-- **Content-Type**: `application/json` / `ReadS3DataWarehouse`
-### 401
-
-Unauthorized
-
-### 404
-
-S3 Data Warehouse integration not found

package/build/dist/docs-index/1fa04a27-7edb-4f17-979f-d2d07e5ea6d3.json

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

package/build/dist/docs-index/1fa04a27-7edb-4f17-979f-d2d07e5ea6d3.txt

@@ -1,15 +0,0 @@
-# PreserveAllAttributesMergeStrategy
-
-**Type**: `object`
-
-## Properties
-
-- name: unique (optional)
-  type: boolean
-
-- name: limit (optional)
-  type: integer
-
-- name: type (required)
-  type: enum: `preserve`
-  description: PreserveAllAttributesMergeStrategy: Collects all incoming values/objects into a collection. If an incoming value is a collection, its elements are unpacked and added individually. The 'limit' field defines when an attribute size will trigger a cluster overflow emission. The 'unique' flag determines if the collection behaves like a Set or a List.

package/build/dist/docs-index/1ff03dea-5918-419f-b1bc-a80d26139523.json

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

package/build/dist/docs-index/1ff03dea-5918-419f-b1bc-a80d26139523.txt

@@ -1,8 +0,0 @@
-# ItemsCollectionReadDataWarehouse
-
-**Type**: `object`
-
-## Properties
-
-- name: items (optional)
-  type: array of `ReadDataWarehouse`

package/build/dist/docs-index/21343226-f92a-4c2f-9393-8e08ec70a1ea.json

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

package/build/dist/docs-index/21343226-f92a-4c2f-9393-8e08ec70a1ea.txt

@@ -1,12 +0,0 @@
-# VariantSynchronousSink
-
-**Type**: `object`
-
-## Properties
-
-- name: name (required)
-  type: string
-
-- name: type (required)
-  type: enum: `variant-sync-sink`
-  description: Sink for returning arbitrary JSON results to the caller.

package/build/dist/docs-index/21d670fa-eff4-4545-8be7-a900d35500c0.json

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

package/build/dist/docs-index/21d670fa-eff4-4545-8be7-a900d35500c0.txt

@@ -1,231 +0,0 @@
----
-description: Use Grok patterns to extract fields from unstructured log data and use those fields to enrich log events with structured attributes.
----
-
-import { HiddenFAQ } from '@/components/HiddenFAQ'
-
-# Parse log messages to enrich log events with the Grok parser
-
-You can use the Grok parser in the Grepr platform to parse and extract fields from semi-structured log messages, and then add those extracted fields as attributes, tags, or top-level fields in output log events. You can use the Grok parser in your pipelines to:
-
-- Extract message context into trackable tags and attributes that can be referenced during incident investigations.
-- Extract specific fields and add them as attributes or tags to ensure those fields are available in summarized events instead of being aggregated and masked by the reducer.
-- Parse timestamps from log messages and set them as the event timestamp for tasks such as a time-series analysis.
-- Convert unstructured text into structured fields that can be queried and analyzed efficiently.
-
-To use the Grok parser, you define one or more Grok _rules_ that specify how to parse log messages. Each rule consists of a name, a Grok pattern that describes what to look for in the log message, and optionally the fields to extract and how to transform those fields. See [Grok rules overview](#grok-rules).
-
-You can add one or more Grok parsers to your pipelines in the Grepr UI or the REST API. To use Grok in the UI, see [Configure the Grok parser in the pipelines UI](#configure-grok-in-ui).
-
-To use Grok in the REST API, you define a [GrokParser object](/apis/api-spec#schema/GrokParser) and add it as a vertex in a Grepr job graph. See [Create and manage jobs with the Grepr REST API](/apis/job-creation-guide)
-
-## Grok rules overview [#grok-rules]
-
-The syntax for a Grok rule is:
-
-```bash
-%{MATCHER:EXTRACTOR:TRANSFORMER}
-```
-
-- The matcher describes what to look for when parsing. For example, `word` for alphanumeric characters or `integer` for integer numbers.
-- The extractor names the destination for the parsed text. Extractors are optional when you define a Grok rule.
-- A transformer, also referred to as a _filter_, converts the extracted values before adding to the output event. For example, convert a JSON string into a JSON object. Transformers are also optional when you define a Grok rule.
-
-The following Grok rule:
-- Matches a string of alphanumeric characters and extracts it as the `user` field.
-- Matches the next string of alphanumeric characters and extracts it as a tag named `lastname` by prepending `tags` to the destination.
-- Matches a date in `MM/dd/yyyy` format, extracts it as the `date` field, and converts it to a timestamp.
-- Matches an IPv4 address and extracts it as the `ip` field.
-
-```bash
-MyParsingRule %{word:user} %{word:tags.lastname} connected on %{date("MM/dd/yyyy"):date} from %{ipv4:ip}
-```
-
-Applying this rule to the log message:
-
-```text
-john smith connected on 11/08/2017 from 127.0.0.1
-```
-
-Results in the following enriched log event:
-
-```json
-{
-  "message": "john smith connected on 11/08/2017 from 127.0.0.1",
-  "attributes": {
-    "user": "john",
-    "date": 1510099200000,
-    "ip": "127.0.0.1"
-  },
-  "tags": [
-    "lastname:smith"
-  ]
-}
-```
-
-All extracted fields are added to the attributes of the output log event, with the following exceptions:
-
-- If you prefix the extractor with `tags.`, the extracted field is added to the tags of the log event.
-- If the extractor is `severity`, the extracted field is used to set a top-level `severity` field in the output log event.
-- If the extractor is `eventTimestamp`, the extracted field is used to set a top-level `timestamp` field in the output log event.
-
-For example:
-
-```bash
-%{word:user}              # Adds to attributes: {"user": "john"}
-%{word:tags.environment}  # Adds to tags: ["environment:production"]
-%{word:severity}          # Sets log severity level
-%{integer:eventTimestamp} # Sets log event timestamp in milliseconds
-```
-
-### Create multiple parsing rules [#grok-multiple-rules]
-
-You can define multiple Grok parsing rules, each with a unique name. The parser tries each rule in order until it finds a match. This approach is useful when different types of log events might require different parsing patterns.
-
-Example with multiple rules:
-
-```bash
-LoginRule %{word:user} logged in from %{ipv4:ip}
-LogoutRule %{word:user} logged out at %{date("HH:mm:ss"):time}
-ErrorRule ERROR: %{data:error_message}
-```
-
-You can also define helper rules that act as reusable components in your main parsing rules. Helper rules don't parse log messages directly but provide building blocks for your main rules.
-
-Using the previous Grok rule as an example:
-
-```bash
-MyParsingRule %{word:user} %{word:tags.lastname} connected on %{date("MM/dd/yyyy"):date} from %{ipv4:ip}
-```
-
-The following shows how this rule can be rewritten using helper rules:
-
-```bash
-MyParsingRule %{user} %{connection} %{ip_address}
-
-# Helper rules
-user %{word:user} %{word:tags.lastname}
-connection connected on %{date("MM/dd/yyyy"):date}
-ip_address from %{ipv4:ip}
-```
-
-## Supported matchers [#grok-supported-matchers]
-
-The Grepr Grok parser supports all matchers from [Logstash](https://github.com/logstash-plugins/logstash-patterns-core/blob/main/patterns/ecs-v1/grok-patterns) plus additional Datadog-compatible matchers.
-
-For a reference to all supported Logstash matchers, including descriptions and examples, see [The Grepr Grok parser: Logstash matchers](/transforms/grok/logstash-matchers).
-
-For a reference to all supported Datadog-compatible matchers, including descriptions and examples, see [The Grepr Grok parser: Datadog-compatible matchers](/transforms/grok/datadog-matchers).
-
-## Supported transformers [#grok-supported-transformers]
-
-For a reference to all supported Grok transformers, including descriptions and examples, see [The Grepr Grok parser: Supported transformers](/transforms/grok/transformers).
-
-## Configure the Grok parser in the pipelines UI [#configure-grok-in-ui]
-
-You can configure Grok parser rules in the Grepr UI when creating or editing a pipeline. To add a rule for the Grok parser:
-
-1. On the details page for your pipeline, in the left-hand navigation menu, click **Grok Parser** to open the **Grok Parsing Rules** pane.
-
-   ![The Grok parsing rules pane.](/images/pipelines/grok-pane.png)
-
-1. Click **Add** to open the **Grok Parser** dialog.
-1. In the **Message** field, enter a sample log message that you want to parse.
-1. (Optional) To add more sample log messages, click **+ Add** and enter additional log messages.
-1. In the **Parsing rules** text box, enter your Grok parsing rules. Each rule must be on a separate line. As you type, the parser validates your rules against the log samples you provided. The validation results appear in the **Extracted attributes using Matching rule** field.
-
-   ![The Grok parser dialog with a rule, a sample event, and validation results.](/images/pipelines/grok-dialog-single-rule.png)
-
-1. (Optional) To filter which log events the parser processes:
-   1. In the **Query language** menu, select a query syntax.
-   1. In the **Filter which logs to parse with a query** field, enter your filter query. Only logs that match the query are parsed. If you leave this field empty, all logs are parsed. To learn about supported query syntaxes, see [Query log data in the Grepr data lake](/queries).
-1. (Optional) To configure advanced settings, click **Advanced Settings**.
-
-   - By default, the Grok parser extracts data from the `message` field in the input log events. To instead specify an attribute containing the message or other unstructured text, enter the attribute name in the **Extract from** field.
-   - To configure Grok patterns that can be referenced in multiple parsing rules, enter them in the **Helper Rules** text box. Enter each pattern on a separate line.
-
-   ![The Grok parser dialog with helper rules.](/images/pipelines/grok-dialog-helper-rules.png)
-
-1. After you've reviewed and validated the results in **Extracted attributes using Matching rule:**, **Extracted Tags:**, and **Extracted top-level fields:**, click **Save**.
-1. To add another Grok parser rule, click **Add**.
-
-## Best practices [#grok-parser-best-practices]
-
-Follow these best practices when using the Grok parser:
-
-- **Test with real log samples**: Always validate your parsing rules with actual log messages from your system before deploying to production. Use the log samples feature in the Grok Parser dialog to test your patterns.
-
-- **Start with simple patterns**: Build complex patterns incrementally. Start with a simple rule that matches the most important fields, then add more fields as needed.
-
-- **Use helper rules for reusable patterns**: If you have complex patterns that appear multiple times, define them as helper rules. This approach makes your parsing rules more maintainable and easier to read.
-
-- **Be specific with matchers**: Use the most specific matcher possible. For example, use `ipv4` instead of `data` when matching IP addresses. Specific matchers provide better validation and type conversion.
-
-- **Use a filter to specify which logs to parse**: When only a subset of log messages requires parsing, you can limit which log events are processed with the **Filter which logs to parse with a query** field in the pipelines UI or the `GrokParser.predicate` object in the REST API. Avoiding unnecessary parsing attempts improves performance and reduces cost.
-
-- **Use appropriate transformers**: Apply transformers to convert extracted values to the correct type. For example, use `::integer` for numeric fields that should be integers, not strings.
-
-- **Order rules from specific to general**: When defining multiple parsing rules, place more specific patterns first. The parser tries each rule in order and uses the first match.
-
-- **Avoid greedy matchers at the start**: The `data` matcher is greedy and matches everything. Avoid using it at the beginning of a pattern, as it may match more than intended.
-
-- **Extract timestamps**: If your logs contain timestamps, extract them using the `date` matcher and set them as `eventTimestamp` for accurate time-series analysis.
-
-- **Extract severity levels**: Extract log severity levels (INFO, WARN, ERROR) and set them as the `severity` field to enable filtering and alerting based on log level.
-
-## Limitations [#grok-parser-limitations]
-
-The Grok parser has the following limitations:
-
-- **Performance impact**: Complex Grok patterns with many rules can impact processing performance. Test your patterns with representative log volumes to ensure acceptable performance.
-
-- **Regex complexity**: Very complex regular expressions in `regex()` matchers can be slow to evaluate. Keep regex patterns as simple as possible.
-
-- **No backtracking**: Once a parsing rule matches a log message, the parser doesn't try other rules. Ensure your rules are ordered correctly.
-
-- **Character encoding**: The Grok parser expects UTF-8 encoded log messages. Other character encodings may cause parsing errors.
-
-- **Timezone handling**: When using the `date` matcher without a timezone parameter, the parser assumes UTC. Always specify the timezone if your logs use a different timezone.
-
-<HiddenFAQ faqs={[
-  {
-    q: "What is the Grok parser and what does it do?",
-    a: "The Grok parser is a Grepr component that extracts structured fields from unstructured log messages using pattern matching. It parses log messages into named fields and adds those fields as attributes, tags, or top-level fields in output log events, enabling better querying and analysis."
-  },
-  {
-    q: "What is a Grok pattern and how do I create one?",
-    a: "A Grok pattern is a named rule that describes what to extract from a log message using the syntax %{MATCHER:EXTRACTOR:TRANSFORMER}. The matcher describes what to look for, the extractor names the destination field, and the transformer optionally converts the value. For example, %{word:username} matches a word and stores it in the username field."
-  },
-  {
-    q: "When should I use the Grok parser?",
-    a: "Use the Grok parser to extract specific fields from semi-structured logs, enrich logs with structured attributes, extract timestamps for time-series analysis, convert unstructured text to structured fields, or ensure important fields are available in summarized events instead of being masked by the Log Reducer."
-  },
-  {
-    q: "What matchers does Grepr's Grok parser support?",
-    a: "Grepr supports all matchers from Logstash including word, integer, ipv4, date, data, and many others. It also supports Datadog-compatible matchers for compatibility with Datadog-formatted logs. See the Grok parser matcher reference documentation for a complete list."
-  },
-  {
-    q: "How do I extract and set a timestamp field?",
-    a: "Use the date matcher with the eventTimestamp extractor. For example, %{date(\"yyyy-MM-dd HH:mm:ss\"):eventTimestamp} will extract a timestamp and set it as the top-level timestamp field in the output log event for accurate time-series analysis."
-  },
-  {
-    q: "How do I add extracted fields as tags instead of attributes?",
-    a: "Prefix the extractor with 'tags.' in your Grok rule. For example, %{word:tags.environment} extracts a word and adds it as a tag in the format 'environment:value' instead of adding it to attributes."
-  },
-  {
-    q: "What is a Grok transformer and when do I need one?",
-    a: "A transformer, or filter, converts extracted values before adding them to the output event. For example, use ::integer to convert a string to an integer, ::json to parse a JSON string, or a custom transformer to apply complex transformations."
-  },
-  {
-    q: "How do I create multiple Grok parsing rules?",
-    a: "Define multiple rules with unique names in the Grok parser dialog, each on a separate line. The parser tries each rule in order until it finds a match. Order rules from specific to general patterns for best results."
-  },
-  {
-    q: "What are Grok helper rules?",
-    a: "Helper rules are reusable Grok patterns that act as building blocks in your main parsing rules. They don't directly parse logs but provide a way to define complex patterns once and reference them in multiple main rules, improving maintainability."
-  },
-  {
-    q: "How do I test and validate my Grok patterns?",
-    a: "In the Grok Parser dialog, enter sample log messages in the Message field and your parsing rules in the Parsing rules text box. The parser validates rules in real-time and shows results in the Extracted attributes field. Test with multiple real log samples before deploying to production."
-  }
-]} />

package/build/dist/docs-index/2206102e-baac-44c8-9877-c0515d274c06.json

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

package/build/dist/docs-index/2206102e-baac-44c8-9877-c0515d274c06.txt

@@ -1,114 +0,0 @@
----
-description: Connect Grepr to observability platforms and storage systems for data ingestion, processing, and output in your pipelines.
----
-
-import { HiddenFAQ } from '@/components/HiddenFAQ'
-
-# Configure integration with observability platforms and cloud storage
-
-To support data ingestion and data output for your Grepr pipelines, you need to connect Grepr to external observability platforms and storage systems. To support these connections, the Grepr platform uses _integrations_. A Grepr integration provides the configuration details to connect to an external system, enabling data exchange between Grepr and that system.
-
-After configuring an integration, you can use it in your Grepr pipelines to create _sources_ to ingest data from agents and collectors, such as FluentD or the OpenTelemetry collector, and _sinks_ to send data to an observability platform or storage.
-
-## Integration types
-
-The Grepr platform includes two integration types:
-
-- Observability platform integrations: Connections to monitoring, logging, and APM platforms, such as Datadog, Splunk, New Relic, and Sumo Logic.
-- Cloud storage integrations: Connections to cloud storage. The Grepr data lake uses cloud storage to store your raw data and metadata.
-
-## Supported platforms and storage integrations
-
-The Grepr platform includes the following integrations. For details on configuring and using an integration, refer to the linked documentation page. For a complete list of supported integrations, supported functionality, and details on vendor-specific capabilities with some integrations, see [Grepr supported integrations and regions](/integrations/support-matrix).
-
-### Datadog
-
-The Datadog integration supports connecting to Datadog and sourcing data from several Datadog-compatible collectors.
-
-See [Configure Datadog connections for integration with Grepr](/integrations/datadog).
-
-### Splunk
-
-The Splunk integration provides connectivity to Splunk through Splunk's HTTP Event Collector (HEC) or S2S over HTTP. This integration supports reading data from Splunk collectors and writing data to Splunk indexes.
-
-See [Configure Splunk connections for integration with Grepr](/integrations/splunk).
-
-### New Relic
-
-The New Relic integration connects to New Relic's observability platform. Use this integration to create sources that retrieve log data from New Relic collectors and sinks that send processed data to New Relic for monitoring and analysis.
-
-See [Configure New Relic connections for integration with Grepr](/integrations/new-relic).
-
-### Sumo Logic
-
-The Sumo Logic integration connects to Sumo Logic's cloud-based log management and monitoring platform using a Sumo Logic HTTP Source. You can use the integration to create sources that ingest data from Sumo Logic collectors and sinks that send processed data to Sumo Logic.
-
-See [Configure connections to Sumo Logic with Grepr integrations](/integrations/sumo-logic).
-
-### Grafana Cloud
-
-Grepr's OpenTelemetry integration can be configured to connect with Grafana Cloud using the OpenTelemetry Protocol (OTLP). Use an OpenTelemetry integration to create sources that ingest data from OTLP-compatible collectors and sinks that send processed log data to Grafana Cloud.
-
-See [Configure connections to Grafana Cloud with Grepr integrations](/integrations/grafana).
-
-### Google Cloud Platform (GCP)
-
-The GCP integration as a source enables you to stream logs from Google Cloud services to Grepr for processing and analysis, then forward the processed logs to any Grepr-supported sink integration, such as Datadog, Splunk, or New Relic.
-
-See [Google Cloud Platform observability with Grepr](/integrations/gcp).
-
-### Cloud storage
-
-The Grepr data lake uses Amazon S3 to store, manage, and support querying the raw data from your Grepr pipelines. Depending on your requirements, you can choose from two S3 integrations: a Grepr-hosted integration, which uses a Grepr-managed S3 bucket, and an integration that uses an S3 bucket in your account. Both integrations provide secure, managed, and efficient storage for your data, along with an optimized query interface.
-
-To configure the Grepr-hosted integration, you only need to assign a name for the integration, and the Grepr platform deploys and manages the S3 bucket.
-
-Using the integration with your own S3 bucket requires that you deploy and configure an S3 bucket in your AWS account, but it provides more control over your data. See [Host a Grepr data lake with the Amazon S3 integration](/integrations/aws-s3).
-
-## Limitations
-
-- Grepr might drop incoming data from external integration sources with timestamps older than 48 hours.
-- Grepr might split log events over 1MB, causing them to lose their original structured format. Each split event includes a common `grepr.splitOriginId` attribute if you need to reconstruct the original message.
-
-<HiddenFAQ faqs={[
-  {
-    q: "What is a Grepr integration?",
-    a: "A Grepr integration provides the configuration details needed to connect Grepr to an external system, such as an observability platform or cloud storage. Integrations enable data exchange between Grepr and external systems, allowing you to create sources for data ingestion and sinks for data output in your pipelines."
-  },
-  {
-    q: "What types of integrations does Grepr support?",
-    a: "Grepr supports two integration types: observability platform integrations (connections to monitoring, logging, and APM platforms like Datadog, Splunk, New Relic, and Sumo Logic) and cloud storage integrations (connections to cloud storage for the Grepr data lake)."
-  },
-  {
-    q: "What is a source in a Grepr pipeline?",
-    a: "A source in a Grepr pipeline is an operator that ingests data from an external system or agent. Sources use integrations to connect to observability platforms or collectors like FluentD or OpenTelemetry to pull data into Grepr for processing."
-  },
-  {
-    q: "What is a sink in a Grepr pipeline?",
-    a: "A sink in a Grepr pipeline is an operator that outputs processed data to an external system. Sinks use integrations to send Grepr-processed logs to observability platforms, data lakes, or other storage systems based on your pipeline configuration."
-  },
-  {
-    q: "Can I use multiple integrations in a single pipeline?",
-    a: "Yes, you can configure pipelines with multiple sources to ingest data from different platforms and multiple sinks to send processed data to different destinations. This flexibility allows you to build complex multi-source, multi-destination data processing workflows."
-  },
-  {
-    q: "Which observability platforms does Grepr support?",
-    a: "Grepr supports integrations with Datadog, Splunk, New Relic, Sumo Logic, Grafana Cloud, and Google Cloud Platform (GCP). Each integration enables different source and sink capabilities depending on the platform's features and capabilities."
-  },
-  {
-    q: "How do I configure a Grepr integration?",
-    a: "To configure an integration, you need to provide connection details specific to your external system, such as API keys, tokens, endpoints, or credentials. The specific steps vary by integration type. Detailed instructions for each integration are available in the platform-specific documentation pages."
-  },
-  {
-    q: "What is the Grepr data lake integration?",
-    a: "The Grepr data lake uses Amazon S3 to store raw log data. You can configure either a Grepr-hosted integration (using a Grepr-managed S3 bucket) where you only provide a name, or an integration with your own AWS account (requiring you to configure and manage the S3 bucket yourself for more control)."
-  },
-  {
-    q: "What happens to logs older than 48 hours from external sources?",
-    a: "Grepr might drop incoming data from external integration sources with timestamps older than 48 hours. This limitation helps optimize storage and processing while allowing you to retain raw logs in the data lake for longer-term analysis."
-  },
-  {
-    q: "What happens when a log event is larger than 1MB?",
-    a: "If a log event exceeds 1MB, Grepr might split it into smaller events, which can cause them to lose their original structured format. Each split event includes a common 'grepr.splitOriginId' attribute that you can use to reconstruct the original message from its component parts."
-  }
-]} />

package/build/dist/docs-index/2244adb4-42b0-43c9-9906-456a4e2671e4.json

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

package/build/dist/docs-index/2244adb4-42b0-43c9-9906-456a4e2671e4.txt

@@ -1,15 +0,0 @@
-# SamplingConfig
-
-Determines how often samples should be emitted
-
-**Type**: `object`
-
-## One Of
-
-This schema accepts one of the following types:
-
-### Option 1
-`ConstantSampling`
-
-### Option 2
-`WindowBasedLogarithmicSampling`

package/build/dist/docs-index/242fffbb-321d-49c0-a8d8-1621140ed0bc.json

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

package/build/dist/docs-index/242fffbb-321d-49c0-a8d8-1621140ed0bc.txt

@@ -1,38 +0,0 @@
-# CloudTrailLogsFileSource
-
-**Type**: `object`
-
-## Properties
-
-- name: name (required)
-  type: string
-
-- name: s3IntegrationId (required)
-  type: string
-  description: Integration ID for the S3 bucket where Grepr will be reading data. This corresponds to the 's3-data-warehouse' integration type.
-
-- name: pathPrefix (optional)
-  type: string
-  description: The s3 path under the provided bucket to monitor. Optional.In the case of CloudTrail logs, this is the path to the AWSLogs/ directory.
-
-- name: streamingPollInterval (optional)
-  type: string
-  description: The interval at which Grepr will check for new files in the S3 bucket. This is only applicable in streaming mode.
-
-- name: fileReadingStrategy (optional)
-  type: `FileReadingStrategy`
-
-- name: format (optional)
-  type: `JsonFileFormat`
-
-- name: accountIds (required)
-  type: array of string
-  description: The list of account IDs from which to read logs.
-
-- name: regions (optional)
-  type: array of enum: `US_EAST_1`, `US_EAST_2`, `US_WEST_1`, `US_WEST_2`, `AF_SOUTH_1`, `AP_EAST_1`, `AP_SOUTH_1`, `AP_SOUTH_2`, `AP_SOUTHEAST_1`, `AP_SOUTHEAST_2`, `AP_SOUTHEAST_3`, `AP_SOUTHEAST_4`, `AP_NORTHEAST_1`, `AP_NORTHEAST_2`, `AP_NORTHEAST_3`, `CA_CENTRAL_1`, `CN_NORTH_1`, `CN_NORTHWEST_1`, `EU_CENTRAL_1`, `EU_CENTRAL_2`, `EU_WEST_1`, `EU_WEST_2`, `EU_WEST_3`, `EU_NORTH_1`, `EU_SOUTH_1`, `EU_SOUTH_2`, `IL_CENTRAL_1`, `ME_CENTRAL_1`, `ME_SOUTH_1`, `SA_EAST_1`
-  description: The list of regions from which to read logs from. If empty or null, reads logs from all regions.
-
-- name: type (required)
-  type: enum: `cloudtrail-file-source`
-  description: Reads logs from an S3 bucket at a CloudTrail path. Only reads logs in folders at or after the specified start time. The path prefix is optional.  Each record will need to be mapped to the Grepr data model before being usable.

package/build/dist/docs-index/2452ff58-9f0c-48b8-ac90-9041be03a528.json

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