Troubleshooting JSON parsing in Log module

Kacper · ‎02 Jun 2026

Summary

This article helps you troubleshoot common issues with JSON log ingestion in Log module (deployed via OneAgent or Dynatrace Operator). It covers mixed plain-text and JSON log files, incorrect timestamp extraction, and incorrect severity mapping. It applies to SaaS and Managed environments on Linux and Windows.

Problem

Log Module supports JSON log ingestion, but parsing does not always behave as expected. Common symptoms include:

A log file contains both plain-text and JSON entries, and the JSON entries are reported individually in some places and merged with plain-text entries in others.
A JSON log entry is ingested with the wrong timestamp, for example, a created_at or eventtime value is used instead of the entry's actual log time.
A log entry uses a custom JSON field for its timestamp, but Log module doesn't pick it up.
Severity (log level) values in ingested logs don't match the values written by the application, for example, a severity field set to STATS appears in Dynatrace as SEVERE.

Resolution

Mixed plain-text and JSON entries in the same log file

Symptoms

A log file or container stream contains both plain-text log lines and JSON objects.
JSON entries are sometimes reported individually and sometimes merged with surrounding plain-text lines, depending on where in the file Log module began reading.
Behavior is inconsistent between agent restarts or rotations.

Cause

Log Module does not support log files that mix plain-text and JSON entries without explicit guidance on where each entry begins. This is a known limitation.

Resolution

Configure the Log entry boundary setting so Log module knows where one entry ends and the next begins. You'll typically need one boundary pattern per entry type (one matching JSON entries, one matching plain-text entries).

For step-by-step configuration, see Troubleshooting log record boundary detection > Mixed plain text and JSON entries not separated correctly.

Timestamp extracted from the wrong field

Symptoms

A JSON log entry is ingested with a timestamp that doesn't match its actual log time.
The misleading timestamp value matches a field elsewhere in the JSON payload (for example, eventtime, created_at, period_start).
The log line contains plain-text content before the JSON object (a "prefix").

Cause (brief)

When JSON parsing is turned on, Log module looks for the timestamp value in a predefined set of supported JSON keys. For the full list of supported keys, see Ingest JSON and TXT logs. The same rules apply to OneAgent log ingestion.

When a plain-text prefix exists before the JSON object, the timestamp found in the prefix takes priority over any timestamp inside the JSON object. Plain-text content after the closing } (a "suffix") is not parsed, it's copied as-is into the log content.

Resolution

If the wrong timestamp is being picked from a prefix, adjust the application's log format so the prefix either contains the intended timestamp or contains no date-like string.
If the wrong timestamp is being pulled from the JSON object, reorder the JSON so a supported timestamp key appears before any misleading fields.
If neither option is possible, see Troubleshooting missing logs > Entries dropped — timestamp out of bounds for additional workarounds, including disabling JSON parsing or defining an explicit timestamp pattern.

Timestamp in a non-standard JSON key

Symptoms

The log entry contains a clearly recognizable timestamp inside the JSON payload, but Log module assigns a different (or auto-observed) timestamp.
The JSON key holding the timestamp is not on the list of supported timestamp keys.

Resolution

When JSON parsing is turned on, Log module only looks for timestamps in the predefined set of supported keys. A timestamp in a non-standard key is ignored.

To extract the timestamp from a non-standard key:

Turn off JSON parsing for this log source. Log Module will then scan the raw log line for a timestamp using configured patterns, allowing you to anchor on the non-standard field. Note: With JSON parsing turned off, JSON fields are no longer automatically extracted as log attributes; the line is ingested as a raw string.
Alternatively, ask the application team whether the field can be renamed to one of the supported keys.

Unexpected severity/log level values

Symptoms

Ingested logs show severity values that don't match those emitted by the application.
The application's severity values are non-standard but happen to start with the same letter as a known severity level, for example, STATS mapped to SEVERE, or WAITING mapped to WARN.

Cause (brief)

When JSON parsing is turned on, Log module applies a permissive severity mapping that matches values in recognized severity keys based on their first letter. Non-standard values that share a first letter with a known log level can be mapped incorrectly. For the full list of severity value mappings, see Log data transformation for OneAgent-ingested JSON logs.

When JSON parsing is disabled, severity mapping is stricter, and this ambiguity does not apply.

Resolution

Inspect the affected log entries and check whether the severity/level field contains values that begin with the same letter as a standard severity (for example, values starting with S, W, I, or E).
Adjust the application's log format so severity values use unambiguous strings, ideally, the standard severity names (INFO, WARN, ERROR, DEBUG, TRACE, FATAL).
If the application can't be changed, consider disabling JSON parsing for this log source to apply the stricter severity mapping. Note: this loses automatic JSON field extraction.

What's next

For broader boundary issues (multi-line entries split incorrectly, entries merged), see Troubleshooting log record boundary detection.
For missing logs (records not appearing at all, including timestamp-out-of-bounds drops), see Troubleshooting missing logs.
For ingest delay, see Troubleshooting log ingest delay.