> 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-json.md).

# Parse JSON

Parses a serialized JSON string from a field on your telemetry and writes the resulting structured data to a field you choose. Use it when a log, metric, or trace carries embedded JSON (for example a string attribute holding `{"action":"login","status":"success"}`) and you want addressable fields instead of one opaque string.

### 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/VZYC0XduImisirclfHs4" alt="Bindplane docs - Parse JSON - image 1"><figcaption></figcaption></figure>

**Selection**

| 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)* | Parse only the records that match. Empty parses every record. A guard like `attributes["eventDetails"] != nil` skips records without the JSON field. |

**Source and target fields**

| Parameter         | Type                                    | Required | Default   | Description                                                                                                                                                  |
| ----------------- | --------------------------------------- | -------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Source Field Type | Enum: Resource, Attribute, Body, Custom | Yes      | Attribute | Where the JSON string 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 JSON string. Use bracket notation for nested fields (e.g. `parent["child"]`). For a Body source, leave empty to parse the entire body. |
| Target Field Type | Enum: Resource, Attribute, Body, Custom | Yes      | Attribute | Where the parsed data is written. **Body is logs-only.**                                                                                                     |
| Target Field      | OTTL Field                              | No \*    | —         | Destination for the parsed data. Leave empty to merge the parsed JSON into the target field type's root (resource, attributes, or body).                     |

\* Source Field is required for Resource, Attribute, and Custom source types. For a **Body** source it is optional, and leaving it empty parses the whole body. Target Field is optional for Resource, Attribute, and Body targets (empty merges into the root); for a **Custom** target it is required.

**Body is available for Logs only.** For Metrics and Traces the field type options are Resource, Attribute, and Custom.

### Examples

#### Parse a JSON string out of a log attribute

A log carries additional event detail as a serialized JSON string in the `eventDetails` attribute:

```json
{
  "level": "info",
  "eventDetails": "{\"action\": \"login\", \"status\": \"success\"}"
}
```

Configure the processor to read that attribute and write the structured result to a new `parsedEventDetails` attribute:

* Choose Telemetry Type: `Logs`
* Condition: `attributes["eventDetails"] != nil`
* Source Field Type: `Attribute`
* Source Field: `eventDetails`
* Target Field Type: `Attribute`
* Target Field: `parsedEventDetails`

After processing, the parsed object is addressable as structured fields:

```json
{
  "level": "info",
  "eventDetails": "{\"action\": \"login\", \"status\": \"success\"}",
  "parsedEventDetails": {
    "action": "login",
    "status": "success"
  }
}
```

You can now filter and route on `parsedEventDetails["action"]` and `parsedEventDetails["status"]`.

### Configuration Tips

* Leave the Target Field empty to merge the parsed keys directly into the target root (the attributes map, the resource attributes, or the body) instead of nesting them under a new field.
* When the target already holds a map, parsed keys are merged in (upsert); when it does not, the target is replaced with the parsed object. Point the target at an empty or new field if you want to keep the original value intact.
* The source value must be a valid JSON string. The processor runs in `ignore` error mode, so a record whose source is not parseable JSON passes through unchanged rather than failing the batch.

### Troubleshooting

#### The parsed field is empty or unchanged

Symptoms: the target field is not populated with structured data after the processor runs.

Solutions:

1. Confirm the source field actually contains a JSON string (not already a map, and not malformed JSON).
2. Verify the Source Field path is correct, using bracket notation for nested fields.
3. Check that the Condition evaluates true for the records you expect to parse.

### Standalone Processor

```yaml
apiVersion: bindplane.observiq.com/v1
kind: Processor
metadata:
  name: parse-json
spec:
  type: parse_json
  parameters:
    - name: telemetry_types
      value:
        - Logs
    - name: log_condition
      value: attributes["eventDetails"] != nil
    - name: log_source_field_type
      value: Attribute
    - name: log_attribute_source_field
      value: eventDetails
    - name: log_target_field_type
      value: Attribute
    - name: log_attribute_target_field
      value: parsedEventDetails
```

### Related Resources

* [ParseJSON — OTTL function reference](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/pkg/ottl/ottlfuncs/README.md#parsejson)

### Bindplane Resources

These parsing and reshaping processors are designed to work together. Chain them to extract, parse, and restructure telemetry:

* [Parse Simplified XML](/integrations/processors/parse-simplified-xml.md)
* [Get XML](/integrations/processors/get-xml.md)
* [Slice to Map](/integrations/processors/slice-to-map.md)
* [Parse Severity](/integrations/processors/parse-severity.md)
* [Parse Timestamp](https://github.com/observIQ/bindplane-docs/blob/main/docs/integrations/processors/parse-timestamp.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-json.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.