## 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.

```text
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