> For the complete documentation index, see [llms.txt](https://docs.bindplane.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bindplane.com/integrations/processors/parse-with-grok.md).

# Parse with Grok

Applies a grok pattern to a source field and extracts the matched values into structured fields. Grok layers named patterns on top of regular expressions, so a single readable expression can break an unstructured log line into typed, named captures. The captures are merged into the target field (or written to it when the target is not a map).

### Supported Telemetry Types

| Logs | Metrics | Traces |
| ---- | ------- | ------ |
| ✓    | ✓       | ✓      |

Choose Telemetry Type picks one signal per processor instance. Add another instance to handle a second signal.

### Configuration

#### Basic Configuration

<figure><img src="/files/09VhJwPnIYqVqwShDNxo" alt="Bindplane docs - Parse with Grok - image 1"><figcaption></figcaption></figure>

**When to apply**

| Parameter             | Type               | Required | Default   | Description                                                                    |
| --------------------- | ------------------ | -------- | --------- | ------------------------------------------------------------------------------ |
| Choose Telemetry Type | Telemetry Selector | Yes      | Logs      | The signal this instance runs on: Logs, Metrics, or Traces (one at a time).    |
| Condition             | OTTL Condition     | No       | *(empty)* | Apply the grok pattern only to records that match. Empty runs on every record. |

**Source and target fields**

| Parameter         | Type                                    | Required | Default   | Description                                                                                                                          |
| ----------------- | --------------------------------------- | -------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| Source Field Type | Enum: Resource, Attribute, Body, Custom | Yes      | Body \*   | Where the source value is read from. **Body is logs-only.** Custom takes any OTTL path and gives access to the full record.          |
| Source Field      | OTTL Field                              | Yes \*\* | —         | The field holding the value to parse. Bracket notation for nested fields. For a Body source, leave empty to use the whole body.      |
| Target Field Type | Enum: Resource, Attribute, Body, Custom | Yes      | Body \*   | Where the parsed fields are written. **Body is logs-only.**                                                                          |
| Target Field      | OTTL Field                              | No       | *(empty)* | Destination for the parsed fields. Leave empty to merge the captures into the chosen target context (resource, attributes, or body). |

\* For Metrics and Traces, the field type options are Resource, Attribute, and Custom (no Body), and both default to Attribute.

\*\* For a Custom, Resource, or Attribute source the Source Field is required. For a Body source it is optional, and leaving it empty parses the whole body.

**Grok pattern**

| Parameter                  | Type        | Required | Default   | Description                                                                                                                                            |
| -------------------------- | ----------- | -------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Grok Pattern               | Code Blocks | Yes      | —         | The grok pattern to match against the source value. Named captures become the extracted fields.                                                        |
| Named Captures Only        | Boolean     | No       | true      | When enabled, only named captures are returned. Disable to include unnamed captures.                                                                   |
| Enable Custom Patterns     | Boolean     | No       | false     | Enable to define your own named grok patterns for use in the Grok Pattern above.                                                                       |
| Custom Pattern Definitions | Strings     | No       | *(empty)* | Custom pattern definitions in the form `PATTERN_NAME=PATTERN` (for example `LOGLINE=%{DATESTAMP} %{DATA}`). Applies when Enable Custom Patterns is on. |

### Grok pattern syntax

A grok pattern is a sequence of `%{SYNTAX:NAME}` references mixed with literal text. `SYNTAX` is the name of a predefined pattern (itself a regular expression), and `NAME` is the field the matched value is captured into. For example, `%{IP:client}` matches an IP address and stores it in a field named `client`.

Predefined patterns such as `IP`, `WORD`, `NUMBER`, `HTTPDATE`, and `TIMESTAMP_ISO8601` cover most common log shapes. You can also use a bare reference like `%{WORD}` with no name, in which case it only contributes a match when Named Captures Only is disabled. To match a value with a specific predefined pattern but no separate field, omit the colon and name.

Literal characters between references must match the input exactly, including spaces and punctuation. When the predefined patterns do not cover your format, turn on Enable Custom Patterns and define your own under Custom Pattern Definitions, then reference them by name in the Grok Pattern.

For the full catalog of predefined pattern names, see the grok pattern reference under Related Resources.

### Examples

#### Parse a common Apache access log line

This example parses a standard Apache combined access log line out of the log body into named fields. With Source Field Type and Target Field Type both set to Body and the Source Field left empty, the pattern runs against the whole body and the captures are merged back into the body.

Sample input (log body):

```
10.0.0.1 - frank [10/Oct/2026:13:55:36 -0700] "GET /index.html HTTP/1.1" 200 2326
```

Grok Pattern:

```
%{IPORHOST:client_ip} %{USER:ident} %{USER:auth} \[%{HTTPDATE:timestamp}\] "%{WORD:method} %{NOTSPACE:request} HTTP/%{NUMBER:http_version}" %{NUMBER:status} %{NUMBER:bytes}
```

Resulting fields merged into the body:

```
client_ip:   10.0.0.1
auth:        frank
timestamp:   10/Oct/2026:13:55:36 -0700
method:      GET
request:     /index.html
http_version: 1.1
status:      200
bytes:       2326
```

<figure><img src="/files/lgUZ7RKYSlfePJjFTZbJ" alt="Bindplane docs - Parse with Grok - image 2"><figcaption></figcaption></figure>

### Configuration Tips

* Leaving Target Field empty merges the named captures into the selected target context (body, attributes, or resource) instead of nesting them under a new field. Set a Target Field to keep the parsed map contained.
* Disable Named Captures Only only when you intentionally want unnamed captures included; otherwise unnamed groups add noise to the output.
* For repeated or shared formats, define a custom pattern once under Custom Pattern Definitions and reference it by name, rather than repeating a long expression in the Grok Pattern.

### Troubleshooting

#### No fields are extracted

Symptoms: the target field is unchanged after the processor runs.

Solutions:

1. Confirm the grok pattern matches the source value end to end, including literal spaces and punctuation between references.
2. Verify the Source Field actually holds the value you expect (check the Source Field Type and path).
3. Confirm the Condition evaluates true for the records you are targeting.

#### Custom pattern is not recognized

Symptoms: a `%{MYPATTERN:field}` reference produces no match.

Solutions:

1. Confirm Enable Custom Patterns is on.
2. Check the definition uses the `PATTERN_NAME=PATTERN` form and the name matches the reference exactly (names are case-sensitive).

### Standalone Processor

```yaml
apiVersion: bindplane.observiq.com/v1
kind: Processor
metadata:
  name: parse-with-grok
spec:
  type: parse_grok
  parameters:
    - name: telemetry_types
      value:
        - Logs
    - name: log_condition
      value: ""
    - name: log_source_field_type
      value: Body
    - name: log_body_source_field
      value: ""
    - name: log_target_field_type
      value: Body
    - name: log_body_target_field
      value: ""
    - name: log_grok_pattern
      value: '%{IPORHOST:client_ip} %{USER:ident} %{USER:auth} \[%{HTTPDATE:timestamp}\] "%{WORD:method} %{NOTSPACE:request} HTTP/%{NUMBER:http_version}" %{NUMBER:status} %{NUMBER:bytes}'
    - name: log_named_captures_only
      value: true
    - name: log_enable_custom_patterns
      value: false
```

### Related Resources

* [ExtractGrokPatterns — OTTL function reference](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/pkg/ottl/ottlfuncs/README.md#extractgrokpatterns)
* [Grok pattern reference (logstash-patterns-core)](https://github.com/logstash-plugins/logstash-patterns-core/tree/main/patterns)

### Bindplane Resources

These parsers extract structured fields from telemetry. Chain them to normalize and enrich your records:

* [Parse with Regex](/integrations/processors/parse-with-regex.md)
* [Parse JSON](/integrations/processors/parse-json.md)
* [Parse Key Value](/integrations/processors/parse-key-value.md)
* [Parse Timestamp](https://github.com/observIQ/bindplane-docs/blob/main/docs/integrations/processors/parse-timestamp.md)
* [Parse Severity](/integrations/processors/parse-severity.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.bindplane.com/integrations/processors/parse-with-grok.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
