Your DLQ has 25,000 unread messages that built up over the last week. Walk through how you'd triage it.

A common approach: 1) Sample a small batch of DLQ records rather than reading everything; if errors.deadletterqueue.context.headers.enable was on, each record carries headers with the original topic, partition and offset, the connector name, task id, stage, and the exception class and message. 2) Group and count by exception class to find the dominant failure modes, since many records often share one root cause. 3) Inspect one representative record per exception class in detail to pin down the exact cause. 4) Fix at the source: correct the producer schema, change the transformation or converter, or repair the sink configuration, rather than just raising retry settings such as errors.retry.timeout. 5) Before replaying, test the fix on a sample, check for side effects such as duplicate downstream writes, cap the retries, and keep a way to abort the replay if it goes wrong.

Expected key concepts: DLQ, sample, exception class, root cause, fix at the source, replay, side effects, retry