@grepr/cli 1.11.5-733ab4d → 1.11.5-7cd07ac

package/build/dist/docs-index/0eb96d17-de14-45f0-9f2d-ae951e11f3fb.txt

@@ -1,111 +0,0 @@
-Process data in Grepr pipelines using built-in tools for parsing, filtering, enrichment, and transformation of log events.
-
-# Transform data in a Grepr pipeline
-
-A Grepr transform is a processing step that modifies, enriches, or restructures data as it flows through a pipeline. As records move through a pipeline, transforms allow you to parse structured and semi-structured data, filter records, and use a familiar SQL interface to perform more complex transformation of records as they move through a pipeline. Transforms are configured as pipeline steps that process data sequentially. Each transform receives input data, applies its logic, and passes the result to the next step in the pipeline.
-
-Most transforms are available in the Grepr pipelines UI. Some transforms are available only in the Grepr REST API or provide more capabilities when used with the API, such as [filters](#filter) and [branching the processing of records](#message-routing) based on query matches.
-
-The following sections describe the transforms available in Grepr pipelines.
-
-## Transform semi-structured records with the Grok parser \[#grok-parser]
-
-The Grok transform parses unstructured text using pattern matching with regular expressions and named capture groups. Use this transform to extract fields from log lines, error messages, and other text-based data where you need to identify specific patterns and convert them to structured fields.
-
-See [Grok parser](/transforms/grok).
-
-## Convert JSON messages into structured objects \[#json-parser]
-
-The JSON parser transforms JSON strings into structured JSON objects. This transform handles nested objects, arrays, and various data types, making it useful for processing API responses, configuration data, and structured log entries.
-
-See [Transform JSON strings into JSON objects](/transforms/json-parsing).
-
-## Restructure JSON objects with a remapper \[#remapper]
-
-The remapper transform moves or copies attributes to top-level fields or to tags in a JSON object. You can also use rename rules to move attribute values from one path to another within the same event. In the pipelines UI, a remapper with customizable default attributes is automatically added to a pipeline.
-
-See [Remap JSON attribute fields to top-level log event fields](/transforms/remapper).
-
-## Transform records with SQL \[#sql-transform]
-
-The SQL transform allows you to use ANSI standard SQL queries to filter, transform, and enrich data records. The SQL transform provides a familiar SQL interface to perform a number of data processing and transformation tasks.
-
-You can use the SQL transform in the Grepr UI or REST API. In the UI, the SQL transform is available when you configure filters.
-
-To learn about using the SQL transform in the Grepr API, see the [SQL Operation specification](/apis/api-spec#schema/SQLOperation).
-
-For a complete reference and examples, see [Transform events with SQL](/transforms/sql-transform).
-
-## Filter records based on conditions \[#filter]
-
-The Filter transform includes or excludes data records based on specified conditions. You can create filters using familiar query interfaces, such as SQL, as well as Datadog and New Relic log query-like syntaxes.
-
-In the Grepr pipelines UI, filters are located in predefined locations in the pipeline. To learn how to configure filters, see [Filter events in a Grepr pipeline](/transforms/filter-events).
-
-To have more flexibility for where filters are included in a pipeline, use the REST API. See [LogsFilter](/apis/api-spec#schema/LogsFilter).
-
-## Reduce log volumes with dynamic aggregation \[#reducer]
-
-The Grepr log reducer uses clustering algorithms to identify patterns in your log data and aggregate similar log messages. The output of this aggregation includes summaries and samples of similar messages. The log reducer is a core step in a log reduction pipeline, where it runs before processed log events are sent to your configured sinks. By sending summaries of similar messages rather than multiple events with redundant information, Grepr significantly reduces the volume of shipped logs and your observability costs. The log reduction pipeline also persists the complete set of raw logs to a low-cost data lake, enabling you to analyze and troubleshoot issues when necessary.
-
-To learn more about how Grepr reduces log volumes with dynamic aggregation, see [Reduce noise and improve the usability of your logs with the log reducer](/transforms/reducer).
-
-To learn how to create a log reduction pipeline, see [Tutorial: Build your first Grepr pipeline](/tutorials/first-pipeline).
-
-To learn how to use the resulting summarized log events in your observability platform along with raw logs stored in Grepr, see [Troubleshoot incidents with Grepr-processed data and your observability tool](/tutorials/troubleshooting-example).
-
-## Transform and enrich log messages with the REST API \[#log-transform-action]
-
-You can use the LogTransformAction in the REST API to specify actions that transform log messages, such as adding or removing attributes and tags. See [LogTransformAction](/apis/api-spec#schema/LogTransformAction).
-
-## Route the processing of messages based on query matches \[#message-routing]
-
-You can route log messages to be processed by different pipelines based on query matches. Because the pipelines UI doesn't support branching, Grepr recommends creating multiple pipelines that ingest data using the same source, and then use filters to route data to the correct pipeline.
-
-You can also use the REST API to create more complex pipeline configurations. See [LogsBranch](/apis/api-spec#schema/LogsBranch).
-
-## Frequently Asked Questions
-
-### What transforms are available in Grepr pipelines?
-
-Grepr provides several transform types: Grok parser for parsing unstructured text with pattern matching, JSON parser for converting JSON strings into structured objects, remapper for restructuring JSON fields and attributes, SQL transform for complex filtering and enrichment using SQL queries, and Filter transform for conditional record processing. Most transforms are available in the UI, while some advanced options are available via REST API.
-
-### When should I use the Grok parser transform?
-
-Use the Grok parser when you need to extract structured data from unstructured text logs. It's ideal for parsing error messages, application logs, system logs, and other text-based data where you need to identify specific patterns and convert them into structured fields using regular expressions and named capture groups.
-
-### When should I use the JSON parser transform?
-
-Use the JSON parser when your log messages contain JSON strings that need to be converted into structured JSON objects. This is useful for processing API responses, configuration data, and structured log entries. The JSON parser handles nested objects, arrays, and various data types automatically.
-
-### What is the remapper transform and when is it used?
-
-The remapper transform moves or copies attributes to top-level fields or to tags in a JSON object. It's useful for standardizing log event structure by moving well-known fields like message, severity, and host from nested attributes to top-level fields. You can configure whether the source attribute is preserved or removed after remapping. The remapper also supports rename rules for moving attribute values from one path to another. The remapper is automatically added to pipelines in the UI with customizable default attributes.
-
-### When should I use the SQL transform?
-
-Use the SQL transform when you need complex filtering, transformation, or enrichment of log records. SQL provides a familiar interface for advanced operations like conditional logic, string manipulation, aggregations, and joining data. It's available in the UI for filters and via REST API for more flexibility.
-
-### Can I combine multiple transforms in a pipeline?
-
-Yes, transforms are configured as sequential pipeline steps. Each transform receives input from the previous step, applies its logic, and passes the result to the next step. This allows you to create complex data processing workflows by combining parsing (Grok), restructuring (remapper), and filtering/enrichment (SQL) transforms.
-
-### What is the Filter transform used for?
-
-The Filter transform includes or excludes data records based on specified conditions. You can use filters with SQL, Datadog, and New Relic-like query syntaxes. In the UI, filters are located in predefined pipeline positions, while the REST API provides more flexibility for filter placement.
-
-### Can I use the REST API for more advanced transform options?
-
-Yes, the REST API provides access to advanced transform options not available in the UI. For example, you can use LogTransformAction to add or remove attributes and tags, LogsBranch for complex message routing based on query matches, and more flexible filter placement. See the API specification for complete details on transform capabilities.
-
-### How do I choose between Grok and SQL transforms?
-
-Use Grok when you need pattern-based parsing of unstructured text to extract specific fields. Use SQL when you need complex conditional logic, calculations, string transformations, or filtering. Grok is specialized for text parsing, while SQL is more general-purpose for data manipulation and enrichment.
-
-### How does Grepr reduce log volumes and observability costs?
-
-Grepr uses clustering algorithms to identify patterns in log data and aggregates similar log messages. Instead of sending multiple redundant log events, Grepr sends summaries and samples of similar messages to your observability platform. This significantly reduces the volume of shipped logs while retaining the ability to analyze and troubleshoot issues. Raw logs are retained in a low-cost data lake for future reference.
-
-### What happens if a transform fails on a record?
-
-Transform behavior depends on the specific transform type and configuration. Parsing errors (like Grok or JSON parsing) typically skip records or add error attributes depending on your configuration. SQL transforms filter out records that don't match conditions. Review transform-specific documentation for error handling details.

package/build/dist/docs-index/0ef35089-3d0b-4f32-835c-e1d4de5447af.txt

@@ -1,43 +0,0 @@
-# Submit a webhook event
-
-**POST** `/v1/integrations/webhooks/{id}/events`
-
-**Operation ID**: `postEvent`
-**Summary**: Submit a webhook event
-Accepts one JSON event from the sending system and starts an investigation on each target agent of the integration. The org is taken from the Grepr API key and the integration id from the path. Returns 202 with the started investigation ids. Retries after a 5xx may start duplicate investigations.
-
-## Tags
-- Webhook Events
-## Parameters
-
-- **id** (required) - path
-  - The webhook integration id.
-  - Type: string
-
-## Request Body
-
-**Content-Type**: `application/json`
-
-**Schema**: string
-
-## Responses
-
-### 202
-
-Investigation(s) started
-
-### 400
-
-Body is not valid JSON
-
-### 401
-
-API key is invalid
-
-### 404
-
-No such webhook integration
-
-### 413
-
-Body exceeds the size limit

package/build/dist/docs-index/16247fe0-c745-41f8-99c9-ece2b6cc8601.txt

@@ -1,20 +0,0 @@
-# Archive an organization skill
-
-**DELETE** `/v1/skills/{id}`
-
-**Operation ID**: `archive`
-**Summary**: Archive an organization skill
-## Parameters
-
-- **id** (required) - path
-  - Type: string
-- **expectedRevision** (required) - query
-  - Type: integer
-
-## Responses
-
-### default
-
-default response
-
-- **Content-Type**: `application/json` / No schema defined

package/build/dist/docs-index/3a595f7f-0045-4194-8943-e5d3c7b84f3c.txt

@@ -1,29 +0,0 @@
-# Read the status of a query job.
-
-**POST** `/v1/jobs/query/read`
-
-**Operation ID**: `read`
-**Summary**: Read the status of a query job.
-Read the status of a query job using the token received when the job was submitted or was last queried. The response contains the job details including the status, result paths, etc., and a new token that can be used to further query for the job details should anything change. Once the job is finished, any more calls to this endpoint before expiry will yield the same result.
-
-## Tags
-- Query Jobs
-## Request Body
-
-**Content-Type**: `application/json`
-
-**Schema**: `QueryJobToken`
-
-## Responses
-
-### 200
-
-Query job status read successfully. The response contains the job details.
-
-### 401
-
-Unauthorized
-
-### 404
-
-Job details corresponding to the token were not found. They probably expired.

package/build/dist/docs-index/467d2646-2e87-4203-bad3-e5f95de0cd52.txt

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

package/build/dist/docs-index/46d1e9f1-0498-4b23-82b4-5ad2d4b1862e.txt

@@ -1,26 +0,0 @@
-# Read
-
-**Type**: `object`
-
-## Properties
-
-- name: accessConfig (required)
-  type: `AccessConfig`
-
-- name: constraints (required)
-  type: `ReadOrgConstraints`
-
-- name: featureFlags (optional)
-  type: array of enum: `DATADOG_BROWSER_LOGS_INTEGRATION`, `METRICS_SOURCE`, `S3_LOGS_FILE_SOURCE`, `PIPELINE_TEMPLATES`, `AI_WORKFLOWS`, `SEARCH_ICEBERG_SOURCE`, `QUERY_JOBS`, `AUTH0_SSO_CONNECTION`, `TRINO_QUERY_ENGINE`, `UNKNOWN`
-
-- name: name (required)
-  type: string
-
-- name: plan (required)
-  type: `Plan`
-
-- name: ssoConnectionEnabled (optional)
-  type: boolean
-
-- name: ssoRequestedAt (optional)
-  type: string

package/build/dist/docs-index/4a9fe1db-f7bc-4c38-ba3e-3fa6af06545a.txt

@@ -1,14 +0,0 @@
-# QueryJobToken
-
-Token issued for a submitted query job. This is used to retrieve the job details and results.
-
-**Type**: `object`
-
-## Properties
-
-- name: jobInfo (required)
-  type: `QueryJobInfo`
-
-- name: sessionToken (required)
-  type: string
-  description: Token to verify the user's session.

package/build/dist/docs-index/4ab5b068-5815-4e16-a622-8adb464ff9e2.txt

@@ -1,33 +0,0 @@
-# Get integration exception impacts for a pipeline
-
-**GET** `/v1/pipelines/{pipelineId}/exceptions/integrations/{integrationId}/impacts`
-
-**Operation ID**: `getIntegrationExceptionImpacts`
-**Summary**: Get integration exception impacts for a pipeline
-Returns the per-exception impact percentages the runtime auto-sync threshold filter would compare against for this pipeline/integration pair. The pipeline's sink dataset scopes the lookup; exceptions without an estimation row are absent from the response.
-
-## Tags
-- Pipeline Exceptions
-## Parameters
-
-- **pipelineId** (required) - path
-  - Pipeline ID providing the dataset scope
-  - Type: string
-- **integrationId** (required) - path
-  - Integration whose exceptions to look up impacts for
-  - Type: string
-
-## Responses
-
-### 200
-
-Impact percentages retrieved
-
-- **Content-Type**: `application/json` / object
-### 401
-
-Unauthorized
-
-### 404
-
-Not Found - Pipeline not found.

package/build/dist/docs-index/50c9f83d-d0d3-4548-9b4c-7293a39e1deb.txt

@@ -1,16 +0,0 @@
-# JobID
-
-The Flink job ID for the query job.
-
-**Type**: `object`
-
-## Properties
-
-- name: bytes (optional)
-  type: string
-
-- name: lowerPart (optional)
-  type: integer
-
-- name: upperPart (optional)
-  type: integer

package/build/dist/docs-index/695db501-fe8f-4208-a1a1-def51944c43e.txt

@@ -1,21 +0,0 @@
-# query_1
-
-**POST** `/v1/metrics/query`
-
-**Operation ID**: `query_1`
-**Summary**: No summary provided.
-## Tags
-- Status Metrics
-## Request Body
-
-**Content-Type**: `application/x-www-form-urlencoded`
-
-**Schema**: object
-
-## Responses
-
-### default
-
-default response
-
-- **Content-Type**: `application/json` / `QueryResult`

package/build/dist/docs-index/6b32b2bd-61ed-4a70-a356-1f09b1a364f0.txt

@@ -1,143 +0,0 @@
-A reference for the permission types in the Grepr platform, and which permissions are assigned to different roles.
-
-# Permissions in the Grepr platform
-
-This page is a reference to the permissions available in the Grepr platform. These permissions are assigned to users based on the user's role:
-
-* Organization-level roles: Admin, Member, and Reader
-* Team-level roles: Leader and Member
-
-A user can be assigned both an organization-level role and a team-level role. For example, an organization Member can also be a team Leader, giving them view access organization-wide and edit access to their team's resources.
-
-You can also create custom roles with a specific subset of Grepr platform permissions. To learn more about roles, including custom roles, see [Manage users in the Grepr platform](/admin/manage-users).
-
-At both the organization and team levels, there are three types of permissions:
-
-* View: Grants read-only access to specified resources.
-* Edit: Grants edit permissions over specified resources, including creating, editing, and deleting those resources.
-* Write: Grants permission to send data through an integration when the integration is used as a sink in a job, such as a backfill job that writes data to a vendor integration. Edit permission on an integration controls the integration's configuration. Write permission on an integration controls whether you can send data through it.
-
-Resources in the Grepr platform include your organization, vendor, and storage integrations, datasets, templates, users, teams, and jobs.
-
-The following sections provide more details on permissions in the Grepr platform and the permissions for each role type.
-
-## Available permissions in the Grepr platform
-
-This table lists all available permissions for organization and team-level roles:
-
-| Permission | Resource | Scope |
-| --- | --- | --- |
-| Edit | Organization settings | Organization |
-| View | Organization settings | Organization or Team |
-| Edit | Integrations | Organization or Team |
-| View | Integrations | Organization or Team |
-| Write | Integrations | Organization or Team |
-| Edit | Jobs | Organization or Team |
-| View | Jobs | Organization or Team |
-| Edit | Users | Organization |
-| View | Users | Organization or Team |
-| Edit | Teams | Organization or Team |
-| View | Teams | Organization or Team |
-| Edit | Templates | Organization or Team |
-| View | Templates | Organization or Team |
-| Edit | Datasets | Organization or Team |
-| View | Datasets | Organization or Team |
-
-## Permissions by role
-
-The following are the permissions granted to each role type in the Grepr platform:
-
-* Organization Admins have full control over all resources in the organization, including all team-scoped resources, and can write to any vendor integration.
-* Organization Members have view-only permissions to all resources in the organization, and have write permission on all vendor integrations so they can run backfill jobs.
-* Organization Readers have view-only permissions to all resources in the organization. Readers can query logs, but cannot create or edit any resources and cannot run backfill jobs that send data to a vendor integration.
-* Team Leaders have edit permissions for all resources scoped to their specific team or teams. This includes permissions to create and edit jobs, integrations, templates, and datasets assigned to the team, and to write to integrations assigned to the team. Team Leaders can also view all organization resources but only edit resources scoped to their team or teams.
-* Team Members have view-only permissions to resources scoped to their specific team or teams, plus write permission on integrations assigned to the team so they can run backfill jobs. A team Member can view resources assigned to the team and query logs, but does not have permission to create or edit resources, such as jobs, integrations, templates, or datasets, assigned to the team.
-* Teams can be granted access to resources, such as integrations, datasets, or templates, scoped at the organization level. When a team is granted access to a resource, team Leaders have edit permissions on the resource, and team Members have view-only permissions. However, to create or edit a job, such as a pipeline, a team Leader must have view permissions on all the integrations and datasets used by the job, and write permission on every vendor integration the job uses as a sink. For example, if a job is assigned to the `DevOps` team, but the team hasn't been granted access to an integration used in the job, a `DevOps` team Leader cannot edit or run the job.
-* To create a dataset, you must have edit permission on the integration the dataset belongs to.
-
-For each resource in the Grepr platform, this table shows the specific permissions granted to each role type at both the organization and team levels:
-
-| Permission | Resource | Access Scope | Organization Admin | Organization Member | Organization Reader | Team Leader | Team Member |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| View | Organization Settings | Organization | ✅ | ✅ | ✅ | ✅ | ✅ |
-| Edit | Organization Settings | Organization | ✅ | ❌ | ❌ | ❌ | ❌ |
-| View | Users | Organization | ✅ | ✅ | ✅ | ✅ | ❌ |
-| Edit | Users | Organization | ✅ | ❌ | ❌ | ❌ | ❌ |
-| View | Teams | Organization | ✅ | ✅ | ✅ | ✅ | ❌ |
-| Edit | Teams | Organization | ✅ | ❌ | ❌ | ❌ | ❌ |
-| View | Integrations | Organization | ✅ | ✅ | ✅ | ❌ | ❌ |
-| Edit | Integrations | Organization | ✅ | ❌ | ❌ | ❌ | ❌ |
-| Write | Integrations | Organization | ✅ | ✅ | ❌ | ❌ | ❌ |
-| View | Datasets | Organization | ✅ | ✅ | ✅ | ❌ | ❌ |
-| Edit | Datasets | Organization | ✅ | ❌ | ❌ | ❌ | ❌ |
-| View | Jobs | Organization | ✅ | ✅ | ✅ | ❌ | ❌ |
-| Edit | Jobs | Organization | ✅ | ❌ | ❌ | ❌ | ❌ |
-| View | Templates | Organization | ✅ | ✅ | ✅ | ✅ | ❌ |
-| Edit | Templates | Organization | ✅ | ❌ | ❌ | ❌ | ❌ |
-| View | Teams | Team | ✅ | ✅ | ✅ | ✅ | ✅ |
-| Edit | Teams | Team | ✅ | ❌ | ❌ | ✅ | ❌ |
-| View | Integrations | Team | ✅ | ✅ | ✅ | ✅ | ✅ |
-| Edit | Integrations | Team | ✅ | ❌ | ❌ | ✅ | ❌ |
-| Write | Integrations | Team | ✅ | ✅ | ❌ | ✅ | ✅ |
-| View | Datasets | Team | ✅ | ✅ | ✅ | ✅ | ✅ |
-| Edit | Datasets | Team | ✅ | ❌ | ❌ | ✅ | ❌ |
-| View | Jobs | Team | ✅ | ✅ | ✅ | ✅ | ✅ |
-| Edit | Jobs | Team | ✅ | ❌ | ❌ | ✅ | ❌ |
-| View | Templates | Team | ✅ | ✅ | ✅ | ✅ | ✅ |
-| Edit | Templates | Team | ✅ | ❌ | ❌ | ✅ | ❌ |
-
-## Organization roles vs. team roles
-
-This table describes the difference between organization-level and team-level roles. Users can have both types of roles:
-
-\| | Organization roles | Team roles | | :-------- | :----------------------------------------------------- | :------------------------------------------ | | Scope | Entire organization | A specific team | | Types | Admin, Member, Reader, or Custom Roles | Leader or Member | | Examples | - Admin: Full access to all resources and settings.\
-\- Member: View organization resources and run backfill jobs.\
-\- Reader: View organization resources and query logs only; no backfills to vendor integrations.\
-\- Custom role, such as "Developer": Specific permissions like "view all jobs, edit templates". | - Leader: Manage team members, create team-scoped integrations.\
-\- Member: View team resources and run backfill jobs to team integrations. |
-
-## Frequently Asked Questions
-
-### What are the main permission types in Grepr?
-
-The main permission types are View (grants read-only access to specified resources), Edit (grants permissions to create, edit, and delete specified resources), and Write (grants permission to send data through an integration when the integration is used as a sink in a job, such as a backfill). These permissions are assigned based on user roles at both organization and team levels.
-
-### What are organization-level roles?
-
-Organization-level roles control access across the entire organization. The standard roles are Admin (full control over all resources), Member (view access plus permission to run backfill jobs), and Reader (view-only access; no backfills to vendor integrations). You can also create custom roles with specific subsets of permissions tailored to your organization's needs.
-
-### What are team-level roles?
-
-Team-level roles control access to resources within a specific team. There are two team roles: Leader (edit permissions for team-scoped resources and view permissions for organization resources) and Member (view-only permissions for team resources). A user can be assigned to multiple teams with different roles.
-
-### Can a user have both organization and team roles?
-
-Yes, users can have both organization-level and team-level roles simultaneously. For example, a user can be an organization Member for organization-wide access while also being a Team Leader for a specific team, granting them edit access to that team's resources.
-
-### What resources can be controlled with Grepr permissions?
-
-Grepr permissions can control access to: organization settings, integrations (observability and storage), jobs, users, teams, templates, and datasets. Each resource can have view or edit permissions assigned at organization or team scope.
-
-### What permissions does an Organization Admin have?
-
-Organization Admins have full control over all resources in the organization, including all team-scoped resources. They can create, edit, and delete any resource, manage users, configure organization settings, and manage all integrations and datasets.
-
-### What permissions does an Organization Member have?
-
-Organization Members have view permissions to all resources in the organization, plus write permission on integrations so they can run backfill jobs. They can view integrations, datasets, jobs, users, and teams and write data through any vendor integration, but cannot create, edit, or delete any resources at the organization level.
-
-### What permissions does an Organization Reader have?
-
-Organization Readers have view-only permissions to all resources in the organization and can query logs. Readers cannot create, edit, or delete any resources, and cannot run backfill jobs that send data to a vendor integration. Use the Reader role for users who need to investigate data without incurring vendor write costs.
-
-### What permissions does a Team Leader have?
-
-Team Leaders have edit permissions for all resources scoped to their specific team(s), including creating and editing jobs, integrations, templates, and datasets. They can also view all organization resources but can only edit resources scoped to their team. Team Leaders can also manage team members.
-
-### What permissions does a Team Member have?
-
-Team Members have view permissions to resources scoped to their team, plus write permission on integrations assigned to the team so they can run backfill jobs. They can view jobs, integrations, templates, and datasets assigned to the team, query logs, and run backfills to team integrations, but cannot create or edit any resources.
-
-### What is a custom role in Grepr?
-
-Custom roles allow you to create roles with a specific subset of Grepr platform permissions tailored to your organization's needs. Instead of using standard roles, you can create custom roles like 'Developer' with permissions such as 'view all jobs' and 'edit templates' to match your team's responsibilities and access requirements.

package/build/dist/docs-index/6caf3824-26a0-46fc-a15a-00eed6051f9f.txt

@@ -1,91 +0,0 @@
-Reduce log volume using Grepr's intelligent pattern detection, clustering, and sampling for cost-effective observability at scale.
-
-# Reduce noise and improve the usability of your logs with the log reducer
-
-Grepr's log reducer uses clustering algorithms and real-time pattern discovery to identify repeated messages in high-volume log streams and aggregate those messages into summarized events. These summarized events reduce the volume of redundant, low-value log events while retaining full context for less common and often higher-value events.
-
-The log reducer is a core step in a Grepr log reduction pipeline, where it runs after log events have been processed by the parsing, filtering, and transformation steps and before they are sent to your configured sinks. By sending summarized events rather than the full set of logs to your observability vendor, Grepr significantly reduces the volume of shipped logs and your observability costs.
-
-Messages that do not match any pattern pass through unmodified. You can also configure *exceptions* for specific messages or patterns that must bypass the reducer and be forwarded unmodified to your observability platform. See [Bypass aggregation of important messages with exceptions](/transforms/reducer/exceptions).
-
-Log reduction pipelines also persist your unaggregated raw logs in a Grepr data lake, ensuring you maintain full access to your log data while dramatically reducing storage and processing costs. The data lake allows you to query and analyze your raw logs, for example, when an incident occurs or alerts are raised that require access to the full set of logs for troubleshooting or debugging. See [The Grepr data lake](/grepr-platform/data-lake).
-
-When you create a log reduction pipeline, a reducer is added with default settings suitable for many log processing flows. When needed, you can change the configuration settings to meet your requirements. You can modify reducer settings in the UI or through the Grepr REST API. To configure the reducer in the UI, see [Configure the log reducer in a Grepr pipeline](/transforms/reducer/configuration). For API documentation, see the [LogReducer API specification](/apis/api-spec#schema/LogReducer).
-
-## How log reduction works
-
-The log reducer divides incoming log events into fixed-duration, tumbling windows and produces summaries separately for each window. The reducer creates the summarized events through a multi-step process, including transformations to:
-
-* Normalize fields to help group values that represent the same entity but might differ slightly in format or content.
-* Structure messages to optimize grouping.
-* Group messages using similarity metrics.
-* Output a configurable number of raw sample messages per pattern before summarizing additional matches.
-* Create and output a concise summary of aggregated messages that match an identified pattern along with a configurable sample of raw messages. The summarized events include metadata that provides important context about the aggregated messages and preserves important fields. See [Summary message metadata](#summary-metadata).
-* Add a tag to all output events to indicate whether the type of message it contains is a sample, summary, passthrough, or exception. See [Message types](#message-types).
-
-If the reducer cannot find a matching pattern for a message, the message passes through unmodified. Reasons that the reducer cannot find a pattern include:
-
-* The clustering process is unable to extract patterns from messages.
-* The log message field is empty or null.
-* The message matches a configured exception rule that prevents it from being reduced.
-
-To learn more about the transformations the reducer applies to messages and how to modify its default behavior, see [Configure the log reducer in a Grepr pipeline](/transforms/reducer/configuration).
-
-## Example: Summarizing repeated and low-value messages
-
-The following image shows an example of a message that's logged repeatedly but provides little to no value because the service it reports on is intentionally left non-running.
-
-The log reducer identifies the pattern in this message and summarizes it into a single message indicating how many times the original message was logged. The summary also includes other metadata about the pattern and the messages that matched it. Important fields from the original messages are included in the summary. The reducer then outputs this summarized message and a sample of the raw messages.
-
-Viewing the summary message shows the added metadata, such as the number of times the message was logged and the start and end times of the messages that were summarized.
-
-## Summary message metadata \[#summary-metadata]
-
-When the reducer generates a summary message for a pattern, it adds the following metadata fields to the output event that provide important context about the aggregated messages. This metadata allows you to understand the pattern's characteristics and the messages it represents, and to link back to the original raw messages if needed.
-
-| Field | Description |
-| --- | --- |
-| `grepr.patternId` | Unique identifier for the pattern. Use this to find related messages. |
-| `grepr.rawLogsUrl` | A direct link to view all raw messages for this pattern in the Grepr data lake. |
-| `grepr.repeatCount` | The number of input messages included in the summary. This can be useful for metrics and [rewriting queries](/transforms/reducer/exceptions#rewrite-queries). |
-| `grepr.receivedTimestamp` | Milliseconds since the Unix epoch when the summary was emitted by Grepr. |
-| `grepr.firstTimeTimestamp` | Milliseconds since the Unix epoch of the first message in this summary. |
-| `grepr.lastTimeTimestamp` | Milliseconds since the Unix epoch of the last message in this summary. |
-
-## Message types \[#message-types]
-
-After processing, each record is assigned a message type, and the `grepr.messagetype` tag is added to output events with one of the following values:
-
-| Value | Description |
-| --- | --- |
-| `sample` | The message is a sample of the original log messages that matched a specific pattern. Sample messages are sent through unmodified until the deduplication threshold is reached. |
-| `summary` | The message summarizes multiple source log messages that matched a specific pattern. Summary messages are generated at the end of each aggregation window for patterns that have exceeded the deduplication threshold. |
-| `passthrough` | The message did not match any existing patterns and was sent through unmodified. |
-| `exception` | The message matched an exception rule and was sent through unmodified. |
-
-## Next steps
-
-* To modify the reducer's default settings to provide further control over how messages are processed, see [Configure the log reducer in a Grepr pipeline](/transforms/reducer/configuration).
-* If you have important messages that must be forwarded to your observability platform without aggregation, configure *exceptions* to ensure these messages skip the reducer step and are forwarded unchanged. See [Bypass aggregation of important messages with exceptions](/transforms/reducer/exceptions).
-
-## Frequently Asked Questions
-
-### What is log reduction in Grepr?
-
-Log reduction is Grepr's process of identifying patterns in high-volume log streams and aggregating similar messages into concise summaries. This reduces the volume of logs shipped to your observability vendor while preserving access to the underlying raw messages through the Grepr data lake.
-
-### How does Grepr identify log patterns?
-
-The reducer applies a multi-step process to each log message. It normalizes variable values such as timestamps, IDs, and IP addresses, structures the message to optimize grouping, and groups messages into patterns using similarity metrics. For each pattern, the reducer forwards a configurable number of raw sample messages before it summarizes additional matches into a single summary event.
-
-### What does the grepr.messagetype tag indicate?
-
-The grepr.messagetype tag records how a message was processed. The value 'sample' means the message was forwarded before the deduplication threshold was reached, 'summary' means the message is a summary of aggregated messages, 'passthrough' means the message did not match any pattern, and 'exception' means the message matched a configured exception.
-
-### What information does a summary message include?
-
-Each summary message includes grepr.patternId for pattern identification, grepr.repeatCount for the count of input messages aggregated, grepr.firstTimeTimestamp and grepr.lastTimeTimestamp for the first and last message timestamps in the summary, grepr.receivedTimestamp for when the summary was emitted, and grepr.rawLogsUrl for a direct link to the raw messages in the Grepr data lake.
-
-### Why might a message pass through without being aggregated?
-
-A message passes through unmodified when the clustering process can't find a pattern that matches it, when the log message field is empty or null, or when the message matches a configured exception rule that prevents aggregation.