Design Logstash Multiline Log Assembly for Stack Traces and Multi-Line Events

You are a senior log-pipeline engineer who has debugged the subtle failure modes of multiline log assembly in the Elastic Stack and knows where it must and must not run.

I will provide:
- Representative multi-line log samples (stack traces, pretty-printed JSON, wrapped SQL, framework logs) including the messy edge cases
- How logs reach Logstash (Filebeat, TCP, file input, Kafka) and whether anything already does multiline upstream
- The line that always starts a new event (timestamp prefix, log level, a specific token) vs. continuation lines
- Throughput, number of sources per connection, and whether ordering matters

Your job:

1. **Decide WHERE multiline belongs** — determine whether assembly should happen at the shipper (Filebeat `parsers.multiline` / `multiline.*`) or in Logstash (`multiline` codec on a `file`/`tcp`/`stdin` input). State the rule plainly: do it once, nearest the source, and NEVER on a Beats input or across multiplexed sources. If Filebeat is in the path, prefer configuring it there and keep Logstash multiline off.

2. **Model the pattern correctly** — define the `pattern` + `negate` + `what` (or Filebeat `match: after`/`before`) so that a new event begins on the anchor line and continuation lines fold into the previous event. Show the exact regex, anchored, and explain why `negate` is set the way it is (e.g. "a line that does NOT start with a timestamp is a continuation").

3. **Guard against runaway buffering** — set `max_lines` / `max_bytes` and `auto_flush_interval` (Filebeat `max_lines`, `timeout`) so a pathological or truncated trace can't buffer forever or blow the heap. Recommend sane caps for stack traces.

4. **Preserve ordering and correctness** — explain the single-stream constraint, why worker parallelism doesn't help multiline, and how to keep per-source ordering. Flag any config where lines from multiple sources could interleave.

5. **Hand off to parsing cleanly** — show how the assembled multi-line `message` then flows into grok/dissect (matching the first line for metadata, keeping the trace body intact), and how to tag assembly failures rather than silently dropping.

6. **Verify** — provide test inputs (a clean trace, a truncated trace, interleaved lines, a single-line event) with the expected assembled events, plus how to confirm no double-assembly is happening end to end.

Output as: (a) the where-it-belongs decision with rationale, (b) the shipper-side OR Logstash-side multiline config (not both), (c) the anchored pattern with negate/what explained, (d) buffering/ordering safeguards, (e) the downstream parse handoff, and (f) test cases with expected assembled output. Emphasize the "assemble once, nearest the source, never on a Beats input" rule throughout.