agent's log parser broke on veeam multiline error codes and the triage failed

TL;DR

Veeam writes errors as a headline line followed by indented detail, inner exception and code lines, so a parser reading one line at a time shatters the record. Rewrite parsing around record boundaries: a new record starts at a timestamped or severity line, continuations attach to the current record, and error codes are extracted from the assembled record. Validate against a corpus of real failed job logs.

agent's log parser broke on veeam multiline error codes and the triage failed

Use this when

• Agent triage reports Veeam failures with missing or wrong error codes.
• Parser output shows detail lines treated as separate meaningless errors.
• Failures with nested exceptions are the ones misreported.

Not for this skill when

• The agent cannot parse Veeam timestamps and skips jobs. Timestamp handling, sibling problem.
• Logs are missing entirely because rotation removed them. Collection problem.

Steps

1. Collect sample logs from several failed Veeam jobs including nested errors. Verify: a representative test corpus exists
2. Document the record structure: start markers, continuation indentation, and where codes appear in the assembled record. Verify: the structure is written down from samples
3. Rewrite the parser to assemble records first and extract fields second. Verify: parser output on the corpus matches hand-labelled records
4. Add the corpus as regression tests so format surprises fail in testing, not production triage. Verify: tests run in the agent build
5. Run the parser on the last week of real logs and compare its triage with the console. Verify: reported errors match the product record

Variant phrasings

parse veeam multiline log records parser

The record phrasing.

agent missed error code continuation lines logs

The continuation variant.

veeam log format nested exception parsing

The nested wording.

Compatibility: Agents parsing Veeam Backup and Replication job logs and Windows event exports in text and XML forms, Python and TypeScript parsers.

Why it happens

Human-oriented logs optimise for reading, not parsing: related facts spread across wrapped lines because that scans well in a console. Line-oriented parsers written against tidy test logs shatter on this reality. Record-oriented parsing plus a real-world corpus is the standard robust approach for every vendor log, not just Veeam.

Edge cases / pitfalls

• Prefer product APIs or structured exports when they exist. Log parsing is the fallback, not the first choice.
• Keep raw log excerpts attached to parsed records. When parsing is wrong, the raw text is the appeal path.
• Vendor log formats drift between versions. Version your corpus by product release.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_snJMWH9AT2tkDLta1c-gLw