> 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-severity.md). # Parse Severity Maps the severity values found in your logs onto standard levels and sets both `severity_text` and `severity_number` accordingly. You point it at the field holding the severity value and list which source values map to each standard level (TRACE, DEBUG, INFO, WARN, ERROR, FATAL), so logs from different sources end up with a consistent severity. ### Supported Telemetry Types | Logs | Metrics | Traces | | ---- | ------- | ------ | | ✓ | | | This processor operates on logs only. It reads the configured severity field and sets the record's `severity_text` and `severity_number`. ### Configuration #### Basic Configuration
Bindplane docs - Parse Severity Fields - image 1
**Selection** | Parameter | Type | Required | Default | Description | | -------------- | ------------------------------- | -------- | --------- | ---------------------------------------------------------------------------------------------------------------------- | | Condition | OTTL Condition | No | *(empty)* | An OTTL condition that must evaluate to true for the processor to apply. Empty applies to all logs. | | Match | Enum: Resource, Attribute, Body | Yes | Body | Where the severity value is read from: the log body, a resource attribute, or a log attribute. | | Severity Field | OTTL Field | Yes | — | The field containing the severity value. Its context (body, attribute, or resource) follows the Match selection above. | **Severity mappings** Each level takes a list of case-insensitive values that should be mapped to that standard level. A record whose severity field matches one of these values has its `severity_text` set to the level name and its `severity_number` set to the matching standard number. | Parameter | Type | Required | Default | Description | | --------- | ------- | -------- | ------- | -------------------------------------------------------------------- | | TRACE | Strings | No | `trace` | The case-insensitive values that should be mapped to TRACE severity. | | DEBUG | Strings | No | `debug` | The case-insensitive values that should be mapped to DEBUG severity. | | INFO | Strings | No | `info` | The case-insensitive values that should be mapped to INFO severity. | | WARN | Strings | No | `warn` | The case-insensitive values that should be mapped to WARN severity. | | ERROR | Strings | No | `error` | The case-insensitive values that should be mapped to ERROR severity. | | FATAL | Strings | No | `fatal` | The case-insensitive values that should be mapped to FATAL severity. | ### Examples #### Normalize a non-standard `level` field A source emits logs whose severity lives in a `level` body field and uses abbreviations and long-form words that don't match the standard levels: ```json { "message": "An error occurred during processing", "level": "err" } ``` Configure the processor to read `level` from the body and add the source-specific values to each level's mapping list: * Match: `Body` * Severity Field: `level` * ERROR: `error`, `err` * WARN: `warn`, `warning` * INFO: `info`, `information` * DEBUG: `debug`, `debugging` * FATAL: `fatal`, `critical` When the record above is processed, `err` matches the ERROR list, so the record's severity is normalized: ``` severity_text: error severity_number: 17 ``` The original `level` field is left in place. The processor sets the record's standard severity fields rather than rewriting the source field. ### Configuration Tips * Beyond plain string matching, a mapping value can be an HTTP status code range written as `1xx`, `2xx`, `3xx`, `4xx`, or `5xx`. For example, putting `5xx` in the ERROR list maps any 5xx status to ERROR. * A mapping value can also be a numeric range written as `8-12`. Any number in that range (such as 9) maps to the level the range is assigned to. * Matching is case-insensitive, so `Error`, `ERROR`, and `error` are treated the same. ### Troubleshooting #### Severity is not being set Symptoms: records pass through with their original `severity_text` and `severity_number` unchanged. Solutions: 1. Confirm Match points at the right location (Body, Attribute, or Resource) and that Severity Field names the actual field holding the value. 2. Verify the source value appears in one of the mapping lists. The defaults only cover the literal level names (`trace`, `debug`, `info`, `warn`, `error`, `fatal`); add your source's values to the appropriate list. 3. If a Condition is set, confirm it evaluates true for the records you expect to change. ### Standalone Processor ```yaml apiVersion: bindplane.observiq.com/v1 kind: Processor metadata: name: parse-severity spec: type: parse_severity_v2 parameters: - name: log_condition value: "" - name: match value: Body - name: body_severity_field value: level - name: trace_mappings value: - trace - name: debug_mappings value: - debug - debugging - name: info_mappings value: - info - information - name: warn_mappings value: - warn - warning - name: error_mappings value: - error - err - name: fatal_mappings value: - fatal - critical ``` ### Related Resources * [OTTL Log Context](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/pkg/ottl/contexts/ottllog/README.md) * [OTTL Booleans](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/pkg/ottl/LANGUAGE.md#booleans) ### Bindplane Resources * [Parse JSON](/integrations/processors/parse-json.md) * [Parse Timestamp](https://github.com/observIQ/bindplane-docs/blob/main/docs/integrations/processors/parse-timestamp.md) * [Parse Key Value](/integrations/processors/parse-key-value.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-severity.md?ask=&goal= ``` `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.