Dead Letter Queue никто не обрабатывает: как настроить возврат сообщений

DLQ сохраняет сообщения, которые основной consumer не смог обработать, но сама по себе не решает проблему. Если очередь никто не анализирует, там месяцами копятся заявки, платежные события или уведомления. Массовый replay без исправления причины возвращает poison messages в цикл и создает дополнительную нагрузку.

Сначала остановите автоматический бесконечный replay, сохраните метрики и возьмите небольшую выборку сообщений. Разделите временные ошибки, постоянные ошибки данных и дефекты кода. Повторяйте только после исправления и с сохранением исходного message ID.

Что проверить в первую очередь

Начните с воспроизводимого сценария: зафиксируйте время сбоя, идентификатор объекта, версию приложения или конфигурации и последнее известное рабочее состояние. Не меняйте несколько параметров одновременно. Один контролируемый шаг должен подтверждать или исключать одну гипотезу, иначе временное исчезновение симптома легко принять за исправление. Перед работой с данными и настройками подготовьте резервную копию и понятный способ отката.

• Проверьте глубину DLQ, возраст самого старого сообщения и скорость поступления.
• Сгруппируйте ошибки по типу, consumer version, routing key и источнику.
• Уточните количество предыдущих попыток и причину dead-lettering.
• Проверьте, нет ли персональных данных и секретов в payload и логах.

Почему возникает проблема

Внешний симптом часто появляется не в том компоненте, где возникла первичная ошибка. Интерфейс может показывать неверное состояние из-за backend, очереди, кеша, прав доступа или внешнего API. Полезно проследить данные от источника до результата и найти первую точку расхождения. Это надежнее, чем исправлять последнее сообщение об ошибке или бесконечно перезапускать сервис.

• Consumer отклоняет новый формат события без backward compatibility.
• Временная недоступность зависимости исчерпывает слишком короткий retry.
• Одно poison message блокирует упорядоченную partition.
• TTL или max-length направляет нормальные сообщения в DLQ без ошибки приложения.
• Никто не назначен владельцем алерта и процедуры replay.

Пошаговая диагностика

Диагностику проводите на тестовой записи или отдельном окружении. В журналах скрывайте токены, пароли, персональные данные и содержимое документов. Для каждого шага сохраняйте измеримый результат: код ответа, версию записи, идентификатор события, состояние процесса, контрольную сумму или время выполнения. Сравнение одной и той же операции до и после изменения помогает отделить причину от совпадения.

• Экспортируйте безопасную выборку с headers, timestamp и error reason.
• Воспроизведите обработку в staging той же версией consumer.
• Проверьте схему, обязательные поля и доступность связанных сущностей.
• Сравните broker policy, TTL, max retries и consumer ack/nack.
• Посчитайте бизнес-влияние: какие операции не завершились.

Как разделить retry, quarantine и ручной разбор

Не все ошибки нужно повторять одинаково. Сетевой timeout часто проходит позже, некорректный payload требует исправления данных, а неизвестная версия события — обновления consumer.

• Transient errors идут в ограниченный exponential backoff retry.
• Permanent validation errors попадают в quarantine с понятной причиной.
• Poison messages не должны бесконечно возвращаться в основную очередь.
• Replay сохраняет original message ID и добавляет audit metadata.
• Успех подтверждается бизнес-результатом и idempotency, а не только ACK.

Как исправить проблему

Разбейте исправление на небольшие обратимые изменения. Сначала устраните подтвержденную причину, затем повторите исходный сценарий и проверьте соседние функции. Массовое обновление данных запускайте на ограниченной выборке с отчетом и только после сверки расширяйте на весь объем. Не отключайте авторизацию, валидацию, шифрование или проверку сертификатов ради быстрого исчезновения ошибки.

• Исправьте основной consumer или данные для подтвержденной группы ошибок.
• Создайте отдельный replay tool с фильтром, лимитом скорости и dry-run.
• Добавьте idempotency key и проверку уже выполненного результата.
• Настройте алерт по возрасту и количеству DLQ, а не только по размеру основной очереди.
• Назначьте владельца и runbook для каждой dead-letter reason.

Безопасный порядок внедрения

• Сохраните затрагиваемые данные, конфигурацию и текущие журналы, заранее проверив реальный способ восстановления.
• Повторите проблему на тестовом объекте без реальных списаний, рассылок и необратимых изменений клиентских данных.
• Зафиксируйте изменение в системе контроля версий или журнале работ вместе с причиной и планом отката.
• Проведите тест на нормальном сценарии, ошибочном вводе, повторном запросе, параллельной операции и временной недоступности зависимости.
• После выпуска наблюдайте логи, метрики и полный пользовательский путь, а не только один успешный запрос.

Как проверить результат

Разовый успешный тест недостаточен. Повторите операцию, проверьте крайние значения, одновременные действия и восстановление после перезапуска или временного сбоя. Для важного сценария сохраните автоматический тест либо короткий регрессионный чек-лист. Итог должен подтверждаться не только интерфейсом, но и состоянием базы, очереди, внешнего сервиса и журналом действий.

• Тестовое временно ошибочное сообщение успешно проходит retry.
• Некорректное сообщение остается в quarantine с понятным диагнозом.
• Replay одной и той же записи не дублирует бизнес-операцию.
• Глубина DLQ уменьшается, а скорость новых поступлений возвращается к норме.

Типичные ошибки при исправлении

• Перенаправить всю DLQ обратно в main queue одной командой.
• Удалять сообщения после просмотра, не сохраняя причину и бизнес-результат.
• Повторять permanent validation error как сетевой сбой.
• Считать ACK доказательством записи в целевой системе.

Как предотвратить повторение

Профилактика строится вокруг явных контрактов, повторяемых релизов и наблюдаемости. Система должна не только работать сейчас, но и позволять быстро увидеть нарушение правила при следующем обновлении, росте нагрузки или сбое внешнего сервиса. Проверки полезно автоматизировать там, где ошибка уже привела к потерям времени, данных или заявок.

• Версионируйте схемы событий и тестируйте совместимость consumers.
• Внедрите idempotency для всех операций с внешним эффектом.
• Контролируйте DLQ age, reason и rate отдельными метриками.
• Регулярно проводите пробный replay в staging и актуализируйте runbook.

Что подготовить для технического разбора

• Описание ожидаемого и фактического поведения с точной последовательностью действий.
• Время проблемы, идентификатор тестового объекта и версии затронутых компонентов.
• Фрагменты журналов до и после ошибки без секретов и персональных данных.
• Перечень последних изменений и уже выполненных проверок.
• Безопасный доступ к тестовой среде либо способ воспроизвести сбой без влияния на клиентов.

Частые вопросы

Можно ли автоматически возвращать все сообщения из DLQ?

Нет, если причины не классифицированы. Автоматически повторяют только подтвержденные временные ошибки с лимитом и защитой от цикла.

Как не создать дубли при replay?

Используйте стабильный message/operation ID и проверяйте сохраненный бизнес-результат до повторного эффекта.

Когда нужна помощь специалиста

Если DLQ растет и сообщения не возвращаются в обработку, я могу классифицировать ошибки, исправить consumer, создать безопасный replay и настроить retries, idempotency и мониторинг очереди.