@grepr/cli 1.2.0 → 1.3.0-4e666db

package/build/dist/docs-index/4699de94-2eb2-41e2-ae03-a1b1246dd1e5.txt

@@ -1,40 +0,0 @@
-# BackfillJobAction
-
-**Type**: `object`
-
-## Properties
-
-- name: name (required)
-  type: string
-  description: The name of the backfill job.
-
-- name: order (optional)
-  type: integer
-  description: Action order. Lower is applied first.
-
-- name: backfillTimespan (optional)
-  type: string
-  description: The timespan for which to backfill data. This field is not required. If you do not specify it, you need to specify a duration in the trigger. For TraceSamplingTriggers, this can be specified in the traceDuration field. For others, you will need to specify a duration in the variables, e.g. __duration:PT1H
-
-- name: jobTags (required)
-  type: object
-  description: The tags added to the backfill job, for ease of search.
-
-- name: backfillQuery (required)
-  type: `backfillQuery`
-
-- name: datasetId (required)
-  type: string
-  description: The ID of the dataset to read data from
-
-- name: sinkOperations (required)
-  type: array of `Operation`
-  description: Specifies the sinks that should be used for the backfill job.
-
-- name: limit (optional)
-  type: integer
-  description: Maximum number of logs to backfill. Default and max is 500,000.
-
-- name: type (required)
-  type: enum: `backfill-job-action`
-  description: Backfills data from the raw logs to the configured sink. This action runs an asynch batch job to backfill data from the raw logs table to the configured sink. The back-filled data is also added to the processed logs table to ensure that the same log is not backfilled twice leading to duplicates. The context on what needs to be backfilled is provided by the 'backfillQuery' which will filter logs that will be backfilled.

package/build/dist/docs-index/4732af6b-3f8f-4c19-91c8-4d3fb455ae95.json

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

package/build/dist/docs-index/4732af6b-3f8f-4c19-91c8-4d3fb455ae95.txt

@@ -1,3 +0,0 @@
-# Any
-
-A value that can be a primitive (String or number), a list, or a map.

package/build/dist/docs-index/477f54df-ef22-4510-b92d-31b83bf28995.json

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

package/build/dist/docs-index/477f54df-ef22-4510-b92d-31b83bf28995.txt

@@ -1,32 +0,0 @@
-# TemplateException
-
-Template exception that can be one of several specific exception types
-
-**Type**: `object`
-
-## One Of
-
-This schema accepts one of the following types:
-
-### Option 1
-`TemplateQueryException`
-
-### Option 2
-`TemplateQueryActionRuleException`
-
-### Option 3
-`TemplateExternalTriggerException`
-
-### Option 4
-`TemplateIntegrationException`
-
-### Option 5
-`TemplateTraceSamplerException`
-
-## Properties
-
-- name: id (optional)
-  type: string
-
-- name: type (required)
-  type: string

package/build/dist/docs-index/47fd1ad1-32b6-4556-a8ba-1cc0670636e3.json

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

package/build/dist/docs-index/47fd1ad1-32b6-4556-a8ba-1cc0670636e3.txt

@@ -1,12 +0,0 @@
-# CompositeAttributesMergeStrategy
-
-**Type**: `object`
-
-## Properties
-
-- name: strategies (required)
-  type: array of `AttributesMergeStrategy`
-
-- name: type (required)
-  type: enum: `composite`
-  description: CompositeAttributesMergeStrategy: Applies multiple merge strategies to produce multiple output attributes with suffixed keys.

package/build/dist/docs-index/48493886-6378-48f3-8188-5c81d13470c3.json

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

package/build/dist/docs-index/48493886-6378-48f3-8188-5c81d13470c3.txt

@@ -1,51 +0,0 @@
-# ReducerLogsQuerySource
-
-**Type**: `object`
-
-## Properties
-
-- name: name (required)
-  type: string
-
-- name: start (required)
-  type: string
-  description: Start of time interval to query data for.
-
-- name: end (required)
-  type: string
-  description: End of time interval to query data for.
-
-- name: query (required)
-  type: `query`
-
-- name: variables (optional)
-  type: object
-  description: Variables that can be used to modify the query while parsed
-
-- name: offset (optional)
-  type: integer
-  description: Offset on the number of rows to process
-
-- name: limit (optional)
-  type: integer
-  description: The maximum number of rows to process
-
-- name: sortOrder (optional)
-  type: enum: `ASCENDING`, `DESCENDING`, `UNSORTED`
-  description: The order in which the rows should be sorted by
-
-- name: datasetId (required)
-  type: string
-  description: The ID of the dataset to read data from.
-
-- name: processedLogsTableName (optional)
-  type: string
-  description: The name of the table containing processed logs.
-
-- name: reductionInterval (required)
-  type: string
-  description: The interval used by the Log Reducer for the query. Uses ISO 8601 format for intervals.
-
-- name: type (required)
-  type: enum: `reducer-logs-iceberg-table-source`
-  description: Queries raw and processed logs from a reducer pipeline.

package/build/dist/docs-index/4a280b15-e086-47b9-be1b-66bdbc85472e.json

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

package/build/dist/docs-index/4a280b15-e086-47b9-be1b-66bdbc85472e.txt

@@ -1,68 +0,0 @@
----
-description: Learn about administrative functions in the Grepr platform, including user interfaces providing full management of users, teams, and roles.
----
-
-import { HiddenFAQ } from '@/components/HiddenFAQ'
-
-# Administer Grepr users
-
-The Grepr platform includes administrative functions that allow you to manage users, teams, and roles. You can add users, organize users into teams, assign roles, and control access to resources across the organization. These functions are accessible through the user-friendly Grepr UI and the REST API.
-
-## Manage users
-
-You can use the **Users** pane in the Grepr user management UI to manage users in your organization. You can view users, view and edit their roles, remove users, and invite new users.
-
-In the **Users** pane, you can also manage the roles assigned to each user.
-
-See [Manage users in the Grepr platform](/admin/manage-users).
-
-## Manage teams
-
-The **Teams** pane in the Grepr user management UI lets you create and manage teams in your organization, and assign users to them as team members or team leaders. You can also use teams to manage access to jobs, integrations, templates, and datasets.
-
-See [Manage teams in the Grepr platform](/admin/manage-teams).
-
-<HiddenFAQ
-  faqs={[
-    {
-      q: "What is the difference between organization-level roles and team roles in Grepr?",
-      a: "Organization-level roles like Admin and Member control global access to Grepr features. Team roles (Leader/Member) are scoped to specific teams and allow for more granular access control. A user can be a team Leader without being an organization-level Admin."
-    },
-    {
-      q: "How do I invite users to my Grepr organization?",
-      a: "In the Users pane of the user management UI, click 'Invite new users' and enter email addresses. You can optionally assign roles and team assignments to invited users before sending the invitation. Users receive an email invitation they must respond to join the organization."
-    },
-    {
-      q: "Can I manage users and teams through the REST API?",
-      a: "Yes, Grepr provides REST APIs for complete user and team management. You can use the Users API and Roles API endpoints documented in the OpenAPI specification to programmatically manage users, roles, and team memberships."
-    },
-    {
-      q: "What permissions do I need to access the user management UI?",
-      a: "You must have the view:users permission to access the user management UI. This permission is automatically granted to organization Admins and team Leaders."
-    },
-    {
-      q: "How do custom roles work in Grepr?",
-      a: "Custom roles allow you to define specific permissions for different resources (jobs, integrations, datasets, etc.). You can select which resources a custom role has access to and what permissions it grants (view, edit, create, delete, or all)."
-    },
-    {
-      q: "Can a user be assigned to multiple teams?",
-      a: "Yes, a user can be assigned to multiple teams with different roles in each team. For example, a user can be a Leader in one team and a Member in another team simultaneously."
-    },
-    {
-      q: "What happens when I remove a user from my organization?",
-      a: "When you remove a user, they are deleted from your organization and all their access is revoked immediately. They lose access to all organization-level resources and all team-scoped resources."
-    },
-    {
-      q: "How do I ensure proper access control when assigning users to teams?",
-      a: "Follow the principle of least privilege by granting users only the access they need. Use team membership to scope access to specific resources, and use custom roles for fine-grained permission control when built-in Admin and Member roles don't meet your requirements."
-    },
-    {
-      q: "What is the difference between editing a user and editing a custom role?",
-      a: "Editing a user allows you to update their name, email, and assign or change their organization-level roles and team memberships. Editing a custom role changes the permissions it grants, which affects all users assigned to that role."
-    },
-    {
-      q: "Can team Leaders manage team membership without being organization Admins?",
-      a: "Yes, team Leaders have the ability to manage team membership, including adding and removing members, without needing organization-level Admin privileges. This allows for delegation of team management responsibilities."
-    }
-  ]}
-/>

package/build/dist/docs-index/4aa3da44-5f43-4f77-9b85-294ececc79ed.json

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

package/build/dist/docs-index/4aa3da44-5f43-4f77-9b85-294ececc79ed.txt

@@ -1,13 +0,0 @@
-# TemplateLogSink
-
-Template log sink configuration
-
-**Type**: `object`
-
-## Properties
-
-- name: sink (optional)
-  type: `Operation`
-
-- name: filter (optional)
-  type: `LogsFilter`

package/build/dist/docs-index/4b763020-0c3c-4150-a6da-27a3b47d951a.json

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

package/build/dist/docs-index/4b763020-0c3c-4150-a6da-27a3b47d951a.txt

@@ -1,22 +0,0 @@
-# Delete an invitation
-
-**DELETE** `/v1/invitations/{id}`
-
-**Operation ID**: `deleteInvitation`
-**Summary**: Delete an invitation
-## Tags
-- Invitations
-## Parameters
-
-- **id** (required) - path
-  - Type: string
-
-## Responses
-
-### 200
-
-Invitation deleted successfully
-
-### 401
-
-Unauthorized

package/build/dist/docs-index/4c7f2b86-1ba8-463b-ba0f-741936d042ca.json

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

package/build/dist/docs-index/4c7f2b86-1ba8-463b-ba0f-741936d042ca.txt

@@ -1,25 +0,0 @@
-# GrokParseResponse
-
-**Type**: `object`
-
-## Properties
-
-- name: match (optional)
-  type: boolean
-  description: Whether a rule matched the log message.
-
-- name: matchingRuleName (optional)
-  type: string
-  description: Which rule matched the log message.
-
-- name: attributes (required)
-  type: object
-  description: JSON object of the matched attributes.
-
-- name: tags (required)
-  type: object
-  description: JSON Object of the matched tags.
-
-- name: topLevelFields (required)
-  type: object
-  description: JSON object of the top-level fields extracted from the Grok rule. Currently, only severity and eventTimestamp can be extracted as top-level fields.

package/build/dist/docs-index/4d42e52d-3086-4ee2-b35b-ec5cebf07620.json

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

package/build/dist/docs-index/4d42e52d-3086-4ee2-b35b-ec5cebf07620.txt

@@ -1,23 +0,0 @@
-# MetricAggSpec
-
-The metrics aggregation to apply to the source data.
-
-**Type**: `object`
-
-## Properties
-
-- name: groupByTags (optional)
-  type: array of string
-  description: The tags to group the results by. If unspecified, all series are grouped together. Only applicable when spaceAggregation is set.
-
-- name: timeGranularity (optional)
-  type: string
-  description: The time granularity to use for the query. Only applicable when timeAggregation is set.
-
-- name: timeAggregation (optional)
-  type: enum: `LATEST`, `SUM`, `AVG`, `MAX`
-  description: The time aggregation to use for the query. If this is set, timeGranularity must also be provided. If null, no time aggregation is done and the raw datapoints are returned.
-
-- name: spaceAggregation (optional)
-  type: enum: `LATEST`, `SUM`, `AVG`, `MAX`
-  description: The space aggregation to use for the query. If null, no grouping is done and the timeseries are returned with full tags.

package/build/dist/docs-index/4e3da4ff-c6a8-4263-853c-e52ed86c7233.json

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

package/build/dist/docs-index/4e3da4ff-c6a8-4263-853c-e52ed86c7233.txt

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

package/build/dist/docs-index/4ee6451e-283d-405a-a821-64ec1df6035e.json

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

package/build/dist/docs-index/4ee6451e-283d-405a-a821-64ec1df6035e.txt

@@ -1,5 +0,0 @@
-# TimestampReadingStrategy
-
-Strategy to read files created after a specific timestamp
-
-**Type**: `object`

package/build/dist/docs-index/4f1b07f7-4275-4a95-a1c2-7b3862d2e63d.json

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

package/build/dist/docs-index/4f1b07f7-4275-4a95-a1c2-7b3862d2e63d.txt

@@ -1,18 +0,0 @@
-# List all S3 Data Warehouse integrations
-
-**GET** `/v1/integrations/s3-data-warehouse`
-
-**Operation ID**: `list_2`
-**Summary**: List all S3 Data Warehouse integrations
-## Tags
-- External S3 Data Warehouse Integration
-## Responses
-
-### 200
-
-S3 Data Warehouse integrations retrieved successfully
-
-- **Content-Type**: `application/json` / `ItemsCollectionReadS3DataWarehouse`
-### 401
-
-Unauthorized

package/build/dist/docs-index/4f4cbfc3-ee2c-4ef1-b2aa-2c4a104f16a9.json

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

package/build/dist/docs-index/4f4cbfc3-ee2c-4ef1-b2aa-2c4a104f16a9.txt

@@ -1,77 +0,0 @@
----
-description: Search log data in the Grepr platform using query syntaxes similar to familiar query interfaces, such as the Datadog, New Relic, and Splunk query syntaxes.
----
-
-import { Callout } from 'nextra/components'
-import { HiddenFAQ } from '@/components/HiddenFAQ'
-
-# Query log data in the Grepr data lake
-
-Grepr provides multiple query interfaces to search and analyze log data stored in your Grepr data lake. You can use familiar query languages from popular observability platforms, making it easy to migrate existing queries or integrate with existing workflows. Each query interface supports different search patterns and filtering capabilities, enabling you to select the most suitable tool for your specific analysis needs.
-
-To use these query interfaces, you can use the Data Explorer in the Grepr UI, the Grepr CLI, or the REST API.
-
-To access the Data Explorer, from the Grepr UI home page, click **Logs** in the top navigation and select a dataset from the menu.
-
-To use the Grepr CLI or REST API, see [The Grepr CLI](/cli) or [Create and manage jobs with the Grepr REST API](/apis/job-creation-guide).
-
-## Search logs using a Datadog-like query syntax
-
-You can search and filter logs using Datadog's familiar query syntax. This interface supports full-text search across message fields, including wildcard matching, phrase searches, and field-specific queries, tag filtering with case-sensitive matching, attribute queries using the `@` symbol, and boolean operators for complex searches.
-
-See [Search logs using a Datadog-like syntax](/queries/datadog).
-
-## Search logs using a Splunk Processing Language (SPL)-like syntax
-
-You can run basic search operations and piped queries using a syntax similar to a subset of SPL. This interface is useful for users familiar with Splunk's search patterns who want to apply similar query logic to filter and analyze log data.
-
-See [Search log data using an SPL-like syntax](/queries/spl).
-
-## Search logs using the New Relic Lucene-like syntax
-
-You can search logs using a syntax similar to New Relic's Lucene-based syntax. Support for this syntax provides a familiar search experience for users of the New Relic Lucene syntax.
-
-See [Search logs using a New Relic Lucene-like syntax](/queries/new-relic).
-
-## Limitations
-
-- For some of the supported query interfaces, Grepr supports only a subset of the interface's functionality. To learn more about the limitations, see the documentation pages for each interface.
-
-<HiddenFAQ faqs={[
-  {
-    q: "What query syntaxes does Grepr support?",
-    a: "Grepr supports three primary query syntaxes: Datadog-like query syntax, Splunk Processing Language (SPL)-like syntax, and New Relic Lucene-like syntax. Each syntax is optimized for users familiar with those platforms and provides similar filtering and search capabilities."
-  },
-  {
-    q: "Can I use Datadog queries directly in Grepr?",
-    a: "Grepr supports a subset of Datadog query syntax designed to be compatible with familiar Datadog queries. While you can port many Datadog queries, some advanced features like fuzzy matching and proximity searches are not supported. See the Datadog query documentation for details on limitations."
-  },
-  {
-    q: "What are the differences between query syntaxes in Grepr?",
-    a: "Datadog syntax focuses on message searches, tag queries, and attribute filtering with boolean operators. SPL syntax uses piped commands similar to Splunk, allowing chained search stages. New Relic Lucene syntax provides field-based search with logical operators and comparison operators. Choose based on your familiarity and use case."
-  },
-  {
-    q: "Which query interface is best for full-text search?",
-    a: "The Datadog-like syntax is excellent for full-text message searches, supporting phrase searches, wildcard matching, and case-insensitive matching. For more structured field-based searching, New Relic's Lucene-like syntax with field:value syntax may be more efficient."
-  },
-  {
-    q: "How do I access the query interfaces?",
-    a: "You can use the query interfaces through three methods: the Data Explorer in the Grepr UI (click Logs in navigation and select a dataset), the Grepr CLI, or the REST API. The Data Explorer provides a visual interface for constructing and running queries."
-  },
-  {
-    q: "Can I combine query types in a single pipeline?",
-    a: "Each query interface is independent, so you use one syntax per query. However, you can use multiple query filters in a pipeline by chaining them in the job graph configuration. The REST API and pipelines support defining complex multi-stage filtering."
-  },
-  {
-    q: "What limitations should I be aware of?",
-    a: "Each query syntax supports only a subset of the original platform's functionality. Common limitations include no fuzzy search, no regular expressions, no proximity searches, and limited advanced commands. Check the specific query interface documentation for detailed limitation information."
-  },
-  {
-    q: "Which query syntax is fastest?",
-    a: "Performance depends on your data and query patterns. Generally, using specific tag and attribute searches is faster than broad message searches. All syntaxes benefit from minimizing time ranges and specifying service/host tags. Exact matches outperform wildcard searches."
-  },
-  {
-    q: "Can I search nested data with these query syntaxes?",
-    a: "Yes, all query syntaxes support searching nested attributes and tags using dot notation. For example, @metadata.request.user_id:12345 searches nested structures. Datadog syntax uses the @ prefix for attributes, SPL uses attributes.fieldname syntax, and Lucene-based syntax uses field:value format."
-  }
-]} />

package/build/dist/docs-index/5014770d-4b0d-4bad-b0a8-f1277a6a7be3.json

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

package/build/dist/docs-index/5014770d-4b0d-4bad-b0a8-f1277a6a7be3.txt

@@ -1,13 +0,0 @@
-# MessageNode
-
-**Type**: `object`
-
-## Properties
-
-- name: term (required)
-  type: string
-  description: The message term to match.
-
-- name: type (required)
-  type: enum: `message-node`
-  description: A node that represents a message term match in a parsed query.

package/build/dist/docs-index/5039fc20-3317-43d3-8829-64a4651ccc1c.json

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