Troubleshooting log boundary detection in Log module

[Kacper]

Troubleshooting log record boundary detection

Table of contents

1. Summary
2. Problem
3. Troubleshooting steps
4. Resolution
   • Multi-line entries split across multiple records
   • Time-only timestamps are causing incorrect splitting
   • Two different timestamp formats in the same log file
   • Mixed plain text and JSON entries are not separated correctly
   • Intermittent splitting of multi-line entries with delayed continuation lines
5. What's next

---

Summary

This article helps you troubleshoot situations where the Log module incorrectly splits incoming log content into log records, for example, stack traces appearing as separate entries instead of a single entry, or multi-line errors being grouped incorrectly. It applies to Log module deployed via OneAgent or Dynatrace Operator on both SaaS and Managed environments, and covers file-based logs and container stdout/stderr logs on Linux and Windows, including Kubernetes workloads.

Problem

You see one of the following in the Logs viewer:

• Stack traces or multi-line errors appear as multiple records instead of a single record.
• Entries that should be separate are merged into a single record.
• The same log pattern is sometimes merged correctly and sometimes split — behavior is inconsistent.
• Entries with non-standard timestamp formats are not recognized as record starts.

Is your scenario supported?

Use the table below to check whether your boundary detection scenario is supported. If it's listed as not supported, jump to the matching resolution section for guidance or a workaround.

Scenario	Support
Logs with default-recognized timestamp formats (no custom rules configured)	✅ Supported
Logs with custom (non-default) timestamp formats	✅ Supported
Multi-line entries whose continuation lines have no timestamp	✅ Supported
Forcing whitespace-prefixed lines to always be treated as continuations	✅ Supported (turn on Skip indented lines)
Logs with two different timestamp formats in the same file	✅ Supported (requires one rule per format)
Mixed plain text and JSON entries in the same log stream	✅ Supported (JSON lines are treated as plain text)
Entry boundary detection without timestamp detection	✅ Supported
Logs whose entries begin with a consistent text pattern (no timestamp)	✅ Supported
Timestamps with time only, no date component	❌ Not supported
Wildcard matching in entry boundary patterns (* is literal)	❌ Not supported
Single rule covering two unrelated timestamp formats	❌ Not supported
No timestamp on the first line of a multi-line entry	❌ Not supported (use entry boundary instead)
The same time format appears occasionally in continuation lines	❌ Not supported
Overlapping/ambiguous date formats (e.g. %d/%m/%Y and %m/%d/%Y)	❌ Not supported

Troubleshooting steps

The following diagnosis applies across several of the scenarios in the Resolution section.

1. Open the Log Module Self-Monitoring dashboard in Dynatrace. For dashboard setup and the full list of SFM events, see Log Module self-monitoring.
2. Filter by the affected log source and check for the following SFM events:
   • timestamp.no_pattern (warning) — Log Module found no recognized timestamp in the log content. Every line is treated as its own record with an auto-assigned observation timestamp.
   • timestamp.multiple_patterns (info) — Log Module detected more than one timestamp format simultaneously, which can cause inconsistent boundary placement.
3. Collect a representative sample of 5–10 raw log lines from the affected source. Identify all distinct timestamp formats present.
4. Match what you observe to one of the scenarios below.

Resolution

Multi-line entries split across multiple records

Symptoms

• Stack traces appear as multiple individual log records in Dynatrace rather than a single one.
• Error log entries with continuation lines (for example, XML body or HTTP response) are fragmented.
• Splitting is consistent — it always happens at the same structural boundary in the log.

Resolution

• If continuation lines consistently start with a specific prefix (for example, [err], Caused by:, at com.), configure an Entry boundary rule that matches the first line of each record rather than continuation lines.
• If the log format lacks a reliable record-start pattern, ask the application team to update the logging configuration to emit a full timestamp (including the date) at the start of each record.

---

Time-only timestamps are causing incorrect splitting

Symptoms

• Log entries whose timestamp contains only a time component (HH:MM:SS or HH:MM:SS.mmm) are split into multiple records.
• Each line of a multi-line entry appears as a separate record.

Cause

Time-only timestamps (with no date component) are not supported by Log Module — neither by default detection nor by custom rules.

Resolution

Choose one of the following options:

Preferred — emit a full timestamp

Update the application logging configuration to include the date in each timestamp, then configure a custom timestamp rule that matches the new format. For example, the strftime pattern for 2026-05-14 10:00:00 is %Y-%m-%d %H:%M:%S.

Alternative — use an entry boundary

Use Entry boundary to identify record starts by a text pattern that appears only on the first line of each entry — for example, a fixed prefix, a log level tag, or a structural marker.

1. Go to Settings → Collect and capture → Log Monitoring → Timestamp/splitting configuration.
2. Create a new rule.
3. Set Timestamp search limit to 0.
4. Fill in the Entry boundary field with your pattern.

---

Two different timestamp formats in the same log file

Symptoms

• A custom timestamp rule is configured and works for some log entries but not others.
• Some entries that should be multi-line are merged; others that should be merged are split.
• The rule appears to be ignored for a subset of entries.

Cause 

A single timestamp rule applies only to a single timestamp format. When a log file contains two distinct formats, lines of the uncovered format are not recognized — they're treated as continuations, or each becomes its own auto-timestamped record.

Important: Configuring any rule disables default timestamp detection for the matched source. A format that was previously auto-detected (such as ISO 8601 or RFC 3339) must be included in an explicit rule once any rule is configured.

Resolution

Create one rule per timestamp format:

1. Go to Settings > Collect and capture > Log Monitoring > Timestamp/splitting configuration.
2. Add a rule with the pattern for the first format.
3. Add a separate rule with the pattern for the second format.
4. Apply the same Matcher to both rules so they target the same log source.

Each format will then correctly trigger record boundaries for its matching lines.

---

Mixed plain text and JSON entries are not separated correctly

Symptoms

• A log file or container stream contains both plain-text log lines and JSON objects, but they are ingested together as a single record or incorrectly grouped.
• JSON log entries are sometimes reported individually and sometimes merged with surrounding plain text lines, depending on where in the file Log module began reading.
• A timestamp/splitting rule exists, but does not reliably separate the two entry types.

Cause

Log module does not natively distinguish between plain-text and JSON entry formats within the same log stream; JSON lines are treated as plain text. Without an explicit boundary signal, Log module can't determine where one entry ends and the next begins when the entry types alternate.

Resolution

Choose the approach that matches your log format.

Option A — Timestamp rule (preferred when each entry begins with a recognizable timestamp)

If each entry — both plain text and JSON — begins with a recognizable timestamp within the first 8192 bytes (the maximum value of Timestamp search limit), configure a timestamp rule for each format.

1. Go to Settings > Collect and capture > Log Monitoring > Timestamp/splitting configuration.
2. Add a rule that matches timestamp patterns in plain text entries.
3. Add a separate rule that matches JSON entries using the timestamp pattern. For example, for a JSON field containing the timestamp: "instant":"%Y-%m-%dT%H:%M:%S".
4. Apply the same Matcher to both rules to scope them to the same log source.

Option B — Entry boundary (use when entries lack timestamps or the timestamp is not reliably positioned)

Configure one entry boundary pattern per entry type. The pattern must match a text fragment that appears at the start of each entry.

1. Go to Settings > Collect and capture > Log Monitoring > Timestamp/splitting configuration.
2. Create a rule and set the Entry boundary to a text fragment that appears at the start of JSON entries, for example, {"instant":.
3. Add a second rule with Entry boundary matching the start of plain text entries, for example, /opt/out/ or [INFO].
4. Apply the same Matcher to both rules to scope them to the same log source.

Note: The * character in an entry boundary pattern is treated as a literal asterisk, not as a wildcard.

---

Intermittent splitting of multi-line entries with delayed continuation lines

Symptoms

• Stack traces or multi-line error entries are sometimes merged into a single record, and sometimes split into separate records — the behavior is inconsistent for the same log pattern.
• A timestamp rule is configured correctly, but splitting still occurs intermittently.
• The issue occurs more frequently under load or when the application writes log output slowly.

Cause (brief)

Log Module holds open log records for a configurable timeout (default: 60 seconds) while waiting for continuation lines. If continuation lines (such as a stack trace body) are written after this timeout — because of application buffering, slow I/O, or high system load — the record is flushed as-is, and the late lines become standalone entries.

Workaround

The timeout that controls how long Log module waits for continuation lines can be increased to give the agent more time to collect delayed lines.

This setting cannot be configured in the Dynatrace UI. Contact Dynatrace Support to have it applied in your environment.

Before requesting this change, consider the trade-offs:

• Ingest delay: A longer timeout increases ingest delay for the last log record in each processing batch. Records that are followed by additional lines within the timeout window are unaffected.
• Scope: The setting applies to an entire scope — tenant, Kubernetes cluster, host group, or host. It can't be restricted to a single log source, container, or namespace.

What's next

• For JSON parsing issues (wrong timestamp from JSON field, severity mapping), see Troubleshooting JSON log parsing.
• For missing logs (records not appearing at all), see Troubleshooting missing logs.
• For ingest delay, see Troubleshooting log ingest delay.