What does a minimum-viable DLQ configuration need, and why does each setting matter?

At minimum: errors.tolerance=all, so a bad record is skipped and reported instead of failing the task (the default, none, fails the task on any error); a DLQ topic set with errors.deadletterqueue.topic.name (blank by default, which means nothing is recorded in a DLQ); and errors.deadletterqueue.context.headers.enable=true (default false), so each DLQ record carries headers with the error context, such as the original topic, partition and offset and the exception class and message. If the DLQ topic does not exist, Connect creates it using errors.deadletterqueue.topic.replication.factor (default 3). Optionally set errors.log.enable=true to also write each error to the Connect log; errors.log.include.messages=true adds details of the failed record but may expose sensitive information, which is why it is off by default. DLQ settings apply to sink connectors. Without the headers, working out why a record failed later is much harder.

Expected key concepts: errors.tolerance, errors.deadletterqueue.topic.name, errors.deadletterqueue.context.headers.enable, errors.deadletterqueue.topic.replication.factor, errors.log.enable, errors.log.include.messages, DLQ, sink connectors