[DOCS-13297] Remove filter query syntax sections from processor docs (#34744)

* fix mistake

* fix typos

* [DOCS-13297] Remove filter query syntax sections from processor docs

* Revert changes to install the worker and advanced worker configurations docs

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

---------

Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>

Author: maycmlee

content/en/observability_pipelines/processors/add_environment_variables.md

@@ -17,7 +17,7 @@ Use this processor to add an environment variable field name and value to the lo
 
 To set up this processor:
 
-1. Define a [filter query](#filter-query-syntax). Only logs that match the specified filter query are processed. All logs, regardless of whether they match the filter query, are sent to the next step in the pipeline.
+1. Define a filter query. Only logs that match the specified filter query are processed. All logs, regardless of whether they match the filter query, are sent to the next step in the pipeline. See [Search Syntax][1] for more information.
 1. Enter the field name for the environment variable.
 1. Enter the environment variable name.
 1. Click **Add Environment Variable** if you want to add another environment variable.
@@ -50,4 +50,4 @@ After you have added processors to your pipeline and clicked **Next: Install**,
 
 The allowlist is stored in the environment variable `DD_OP_PROCESSOR_ADD_ENV_VARS_ALLOWLIST`.
 
-{{% observability_pipelines/processors/filter_syntax %}}
+[1]: /observability_pipelines/search_syntax/logs/

content/en/observability_pipelines/processors/add_hostname.md

@@ -16,6 +16,6 @@ This processor adds a field with the name of the host that sent the log. For exa
 ## Setup
 
 To set up this processor:
-- Define a **filter query**. Only logs that match the specified [filter query](#filter-query-syntax) are processed. All logs, regardless of whether they do or do not match the filter query, are sent to the next step in the pipeline.
+- Define a **filter query**. Only logs that match the specified filter query are processed. All logs, regardless of whether they do or do not match the filter query, are sent to the next step in the pipeline. See [Search Syntax][1] for more information.
 
-{{% observability_pipelines/processors/filter_syntax %}}
+[1]: /observability_pipelines/search_syntax/logs/

content/en/observability_pipelines/processors/dedupe.md

@@ -17,7 +17,7 @@ The Deduplicate processor removes copies of data to reduce volume and noise. It
 
 To set up the Deduplicate processor:
 
-1. Define a **filter query**. Only logs that match the specified [filter query](#filter-query-syntax) are processed. Deduped logs and logs that do not match the filter query are sent to the next step in the pipeline.
+1. Define a **filter query**. Only logs that match the specified filter query are processed. Deduped logs and logs that do not match the filter query are sent to the next step in the pipeline. See [Search Syntax][1] for more information.
 1. In the **Type of deduplication** dropdown menu, select whether you want to `Match` on or `Ignore` the fields specified below.
     - If `Match` is selected, then after a log passes through, future logs that have the same values for all of the fields you specify below are removed.
     - If `Ignore` is selected, then after a log passes through, future logs that have the same values for all of their fields, *except* the ones you specify below, are removed.
@@ -57,4 +57,4 @@ For the following message structure:
 - Use `outer_key.inner_key` to refer to the key with the value `inner_value`.
 - Use `outer_key.inner_key.double_inner_key` to refer to the key with the value `double_inner_value`.
 
-{{% observability_pipelines/processors/filter_syntax %}}
+[1]: /observability_pipelines/search_syntax/logs/

content/en/observability_pipelines/processors/edit_fields.md

@@ -25,7 +25,7 @@ See the [Remap Reserved Attributes][1] guide on how to use the Edit Fields proce
 Use **add field** to append a new key-value field to your log.
 
 To set up the add field processor:
-1. Define a **filter query**. Only logs that match the specified [filter query](#filter-query-syntax) are processed. All logs, regardless of whether they do or do not match the filter query, are sent to the next step in the pipeline.
+1. Define a **filter query**. Only logs that match the specified filter query are processed. All logs, regardless of whether they do or do not match the filter query, are sent to the next step in the pipeline. See [Search Syntax][2] for more information.
 1. Enter the field and value you want to add. To specify a nested field for your key, use the [path notation](#path-notation-example-remap): `<OUTER_FIELD>.<INNER_FIELD>`. All values are stored as strings.
     **Note**: If the field you want to add already exists, the Worker throws an error and the existing field remains unchanged.
 
@@ -34,7 +34,7 @@ To set up the add field processor:
 Use **drop field** to drop a field from logging data that matches the filter you specify below. It can delete objects, so you can use the processor to drop nested keys.
 
 To set up the drop field processor:
-1. Define a **filter query**. Only logs that match the specified [filter query](#filter-query-syntax) are processed. All logs, regardless of whether they do or do not match the filter query, are sent to the next step in the pipeline.
+1. Define a **filter query**. Only logs that match the specified filter query are processed. All logs, regardless of whether they do or do not match the filter query, are sent to the next step in the pipeline. See [Search Syntax][2] for more information.
 1. Enter the key of the field you want to drop. To specify a nested field for your specified key, use the [path notation](#path-notation-example-remap): `<OUTER_FIELD>.<INNER_FIELD>`.
     **Note**: If your specified key does not exist, your log is unimpacted.
 
@@ -43,7 +43,7 @@ To set up the drop field processor:
 Use **rename field** to rename a field within your log.
 
 To set up the rename field processor:
-1. Define a **filter query**. Only logs that match the specified [filter query](#filter-query-syntax) are processed. All logs, regardless of whether they do or do not match the filter query, are sent to the next step in the pipeline.
+1. Define a **filter query**. Only logs that match the specified filter query are processed. All logs, regardless of whether they do or do not match the filter query, are sent to the next step in the pipeline. See [Search Syntax][2] for more information.
 1. Enter the name of the field you want to rename in the **Source field**. To specify a nested field for your key, use the [path notation](#path-notation-example-remap): `<OUTER_FIELD>.<INNER_FIELD>`. After it is renamed, your original field is deleted unless you enable the **Preserve source tag** checkbox described below.<br>**Note**: If the source key you specify doesn't exist, a default `null` value is applied to your target.
 1. In the **Target field**, enter the name you want the source field to be renamed to. To specify a nested field for your specified key, use the [path notation](#path-notation-example-remap): `<OUTER_FIELD>.<INNER_FIELD>`.<br>**Note**: If the target field you specify already exists, the Worker throws an error and does not overwrite the existing target field.
 1. Optionally, check the **Preserve source tag** box if you want to retain the original source field and duplicate the information from your source key to your specified target key. If this box is not checked, the source key is dropped after it is renamed.
@@ -70,8 +70,7 @@ To set up the rename field processor:
 - Use `outer_key.inner_key.double_inner_key` to see the key with the value `double_inner_value`.
 
 [1]: /observability_pipelines/guide/remap_reserved_attributes
-
-{{% observability_pipelines/processors/filter_syntax %}}
+[2]: /observability_pipelines/search_syntax/logs/
 
 ## Further reading
 

content/en/observability_pipelines/processors/enrichment_table.md

@@ -73,7 +73,7 @@ In Datadog's Snowflake integration documentation, see [Reference Tables][3] for
 To set up the Enrichment Table processor:
 
 1. Click **Add enrichment**.
-1. Define a **filter query**. Only logs that match the specified [filter query](#filter-query-syntax) are sent through the processor. **Note**: All logs, regardless of whether they match the filter query, are sent to the next step in the pipeline.
+1. Define a **filter query**. Only logs that match the specified filter query are sent through the processor. **Note**: All logs, regardless of whether they match the filter query, are sent to the next step in the pipeline. See [Search Syntax][8] for more information.
 1. In the **Set lookup mapping** section, select the type of lookup dataset you want to use.
   {{< tabs >}}
   {{% tab "Reference Table" %}}
@@ -197,12 +197,11 @@ To see metrics about your Enrichment Table processor using a Reference Table, ad
 `pipelines.reference_table_fetched_keys_total`
 : For each request sent to the Reference Tables API, this counter is incremented with the number of rows fetched in that request.
 
-{{% observability_pipelines/processors/filter_syntax %}}
-
 [1]: /reference_tables/?tab=cloudstorage
 [2]: /integrations/salesforce/#optional-enable-ingestion-of-reference-tables
 [3]: /integrations/snowflake-web/#reference-tables
 [4]: https://docs.datadoghq.com/reference_tables/?tab=cloudstorage#reference-table-limits
 [5]: /help/
 [6]: /integrations/databricks/?tab=useaserviceprincipalforoauth#reference-table-configuration
 [7]: /integrations/guide/servicenow-cmdb-enrichment-setup/#reference-tables
+[8]: /observability_pipelines/search_syntax/logs/

content/en/observability_pipelines/processors/filter.md

@@ -27,44 +27,13 @@ This processor sends all logs or metrics ({{< tooltip glossary="preview" case="t
 
 To set up the filter processor:
 
-- Define a **filter query**.
-  - Logs or metrics that match the [query](#filter-query-syntax) are sent to the next component.
+- Define a **filter query**.<br>**Notes**:
+  - Logs or metrics that match the query are sent to the next component.
   - Logs or metrics that don't match the query are dropped.
+  - For more information, see [Search Syntax for Logs][1] or [Search Syntax for Metrics][2].
 
-## Filter query syntax
-
-Each processor has a corresponding filter query in their fields. Processors only process logs or metrics that match their filter query.
-
-The following are filter query examples:
-
-{{< tabs >}}
-{{% tab "Logs" %}}
-
-- `NOT (status:debug)`: This filters for logs that do not have the status `DEBUG`.
-- `status:ok service:flask-web-app`: This filters for all logs with the status `OK` from your `flask-web-app` service.
-    - This query can also be written as: `status:ok AND service:flask-web-app`.
-- `host:COMP-A9JNGYK OR host:COMP-J58KAS`: This filter query only matches logs from the labeled hosts.
-- `user.status:inactive`: This filters for logs with the status `inactive` nested under the `user` attribute.
-- `http.status:[200 TO 299]` or `http.status:{300 TO 399}`: These two filters represent the syntax to query a range for `http.status`. Ranges can be used across any attribute.
-
-Learn more about writing log filter queries in [Log Search Syntax][1].
-
-[1]: /observability_pipelines/search_syntax/logs/
-
-{{% /tab %}}
-
-{{% tab "Metrics" %}}
-
-- `NOT system.cpu.user`: This filters for metrics that do not have the field `name:system.cpu.user`.
-- `system.cpu.user OR system.cpu.user.total`: This filter query only matches metrics that have either `name:system.cpu.user` or `name:system.cpu.user.total`.
-- `tags:(env\:prod OR env\:test)`: This filters for metrics with `env:prod` or `env:test` in `tags`.
-
-Learn more about writing metrics filter queries in [Metrics Search Syntax][1].
-
-[1]: /observability_pipelines/search_syntax/metrics/
-
-{{% /tab %}}
-{{< /tabs >}}
+[1]: /observability_pipelines/search_syntax/logs
+[2]: /observability_pipelines/search_syntax/metrics
 
 ## Further reading
 

content/en/observability_pipelines/processors/generate_metrics.md

@@ -26,7 +26,7 @@ Click **Manage Metrics** to create new metrics or edit existing metrics. This op
 
 ##### Add a metric
 
- 1. Enter a [filter query](#filter-query-syntax). Only logs that match the specified filter query are processed. All logs, regardless of whether they match the filter query, are sent to the next step in the pipeline. **Note**: Since a single processor can generate multiple metrics, you can define a different filter query for each metric.
+ 1. Enter a filter query. Only logs that match the specified filter query are processed. All logs, regardless of whether they match the filter query, are sent to the next step in the pipeline. See [Search Syntax][5] for more information. **Note**: Since a single processor can generate multiple metrics, you can define a different filter query for each metric.
 1. Enter a name for the metric.
 1. In the **Define parameters** section, select the metric type (count, gauge, or distribution). See the [Count metric example](#count-metric-example) and [Distribution metric example](#distribution-metric-example). Also see [Metrics Types](#metrics-types) for more information.
     - For gauge and distribution metric types, select a log field which has a numeric (or parseable numeric string) value that is used for the value of the generated metric.
@@ -89,5 +89,4 @@ To create a distribution metric that measures the average time it takes for an A
 [2]: /account_management/billing/custom_metrics/
 [3]: /metrics/types/
 [4]: /metrics/distributions/
-
-{{% observability_pipelines/processors/filter_syntax %}}
+[5]: /observability_pipelines/search_syntax/logs/

content/en/observability_pipelines/processors/grok_parser.md

@@ -32,7 +32,7 @@ See [Parsing][1] for more information on Datadog's Grok patterns.
 
 ## Setup
 
-To set up the grok parser, define a **filter query**. Only logs that match the specified [filter query](#filter-query-syntax) are processed. All logs, regardless of whether they match the filter query, are sent to the next step in the pipeline.
+To set up the grok parser, define a **filter query**. Only logs that match the specified filter query are processed. All logs, regardless of whether they match the filter query, are sent to the next step in the pipeline. See [Search Syntax][3] for more information.
 
 To test log samples for out-of-the-box rules:
 1. Click the **Preview Library Rules** button.
@@ -51,8 +51,7 @@ To add a custom parsing rule:
 
 [1]: /logs/log_configuration/parsing/
 [2]: /logs/log_configuration/parsing/?tab=matchers#using-helper-rules-to-reuse-common-patterns
-
-{{% observability_pipelines/processors/filter_syntax %}}
+[3]: /observability_pipelines/search_syntax/logs/
 
 ## Further reading
 

content/en/observability_pipelines/processors/parse_json.md

@@ -62,10 +62,10 @@ This output contains the `message` field with the parsed JSON:
 ## Setup
 
 To set up this processor:
-1. Define a **filter query**. Only logs that match the specified [filter query](#filter-query-syntax) are processed. All logs, regardless of whether they do or do not match the filter query, are sent to the next step in the pipeline.
+1. Define a **filter query**. Only logs that match the specified filter query are processed. All logs, regardless of whether they do or do not match the filter query, are sent to the next step in the pipeline. See [Search Syntax][1] for more information.
 2. Enter the name of the field you want to parse JSON on.<br>**Note**: The parsed JSON overwrites what was originally contained in the field.
 
-{{% observability_pipelines/processors/filter_syntax %}}
+[1]: /observability_pipelines/search_syntax/logs/
 
 ## Further reading
 

content/en/observability_pipelines/processors/parse_xml.md

@@ -44,7 +44,7 @@ The following image shows a Windows Event 4625 log in XML, next to the same log
 
 To set up this processor:
 
-1. Define a filter query. Only logs that match the specified filter query are processed. All logs, regardless of whether they match the filter query, are sent to the next step in the pipeline.
+1. Define a filter query. Only logs that match the specified filter query are processed. All logs, regardless of whether they match the filter query, are sent to the next step in the pipeline. See [Search Syntax][1] for more information.
 1. Enter the path to the log field on which you want to parse XML. Use the path notation `<OUTER_FIELD>.<INNER_FIELD>` to match subfields. See the [Path notation example](#path-notation-example-parse-xml) below.
 1. Optionally, in the `Enter text key` field, input the key name to use for the text node when XML attributes are appended. See the [text key example](#text-key-example). If the field is left empty, `value` is used as the key name.
 1. Optionally, select `Always use text key` if you want to store text inside an object using the text key even when no attributes exist.
@@ -138,7 +138,7 @@ Then it is converted to the JSON:
 }
 ```
 
-{{% observability_pipelines/processors/filter_syntax %}}
+[1]: /observability_pipelines/search_syntax/logs/
 
 ## Further reading