Как я мониторю очередь Postfix и отличаю задержку доставки от обычной нагрузки

Почему размер очереди ещё не означает задержку

Я начинаю не с порога, а с поведения очереди во времени. После рассылки уведомлений или восстановления канала Postfix закономерно принимает пачку сообщений: число растёт, затем уменьшается, а старейшее письмо остаётся молодым. Иная картина — объём почти не меняется либо увеличивается, возраст хвоста ползёт вверх, и повторяется один класс временных отказов. Поэтому событие строю как сочетание наклона, длительности, возраста и причины. Короткая active-очередь обычно показывает текущую работу доставщиков. deferred хранит сообщения после временно неудачных попыток, а hold означает административно удержанные записи, которые сами по расписанию не уйдут. Смешивать эти состояния в один счётчик опасно: одинаковое итоговое число описывает три разных операционных решения.

Какие снимки я получаю штатными средствами Postfix

Для ручной сверки использую postqueue -p и совместимую команду mailq: они показывают идентификатор, размер, время постановки и причину последней неудачи. В автоматический результат полный вывод не попадает. Распределение по возрасту удобно смотреть через qshape, отдельно для deferred и при необходимости active: временные корзины быстро обнаруживают хвост, который пережил обычный пик. qshape может отсутствовать в установленном пакете или отличаться способом вызова между версиями. Тогда wrapper не разбирает декоративное выравнивание колонок как вечный контракт, а применяет проверенный для данной версии read-only разбор postqueue с тестовыми образцами. mailq оставляю независимой диагностической сверкой. Любая ошибка парсинга становится отдельным признаком качества сбора, а не нулевой очередью.

Возраст deferred важнее абсолютного количества

Самый полезный показатель хвоста — возраст старейшего deferred message. Wrapper вычисляет его из времени постановки, возвращает секунды и не отдаёт queue ID. Рядом храню количество сообщений по возрастным корзинам и скорость изменения каждого состояния. Условие проблемы возникает, когда старейшая запись продолжает стареть, deferred не разгружается и журнал подтверждает повторяемую причину. Напротив, большое число свежих писем при устойчивом уменьшении и успешных доставках отражает пропускную работу. Для hold я использую отдельное уведомление: возраст там не доказывает сетевую задержку, поскольку удержание могло быть осознанным. Так нет универсального числа писем, которое объявляется аварией на любом сервере; границы времени сопоставляются с локальным профилем потока и ожидаемым окном доставки.

Как журнал объясняет delivery status и error code

Счётчик отвечает на вопрос «сколько», но причина находится в mail log. По временному окну и queue ID я связываю запись очереди с результатом доставки, затем оставляю только нормализованные поля: delivery status, например sent, deferred или bounced, код ответа и класс причины. Адреса, домены получателей, message-id и текст письма отбрасываются до передачи значения агенту. Код 4xx обычно означает временный ответ, однако его смысл уточняет сопровождающая строка; 5xx чаще окончательный, но также требует чтения политики удалённой стороны. Событие Zabbix получает агрегат вроде «внешний MX: временное ограничение» и количество повторов, а не исходную строку. Это сохраняет диагностическую связь и гарантирует, что адреса и получатели не окажутся в истории, имени триггера или уведомлении.

Развилка между MX, DNS, TLS, SASL и ограничением скорости

Одинаковый deferred требует разных проверок. Ошибка соединения с внешним MX ведёт к маршруту, доступности порта и ответу конкретного узла. Сбой DNS проявляется при поиске MX или адреса и проверяется через настроенные для сервера резолверы. TLS отделяю по этапу рукопожатия, цепочке сертификатов и согласованию протокола; это не равнозначно недоступному порту. SASL относится к аутентификации на relay и требует проверки выбранного механизма и доступа Postfix к секрету без вывода самого секрета. Rate limiting получателя обычно виден как временный ответ с просьбой замедлиться, поэтому агрессивный flush только продлит ограничение. Я группирую ошибки по этим ветвям, но сохраняю числовой SMTP-код: свободный текст меняется, тогда как код и стадия дают устойчивую опору для корреляции.

Отдельная проверка службы и queue manager

До исследования удалённой стороны убеждаюсь, что Postfix действительно обрабатывает очередь. Контролирую состояние системной службы, результат штатной проверки статуса и признаки работающего queue manager. Остановленный либо постоянно перезапускающийся qmgr создаёт старение без новых попыток, поэтому отсутствие свежих delivery status в журнале становится важным дополнением. При этом активный master-процесс ещё не доказывает исправность всей цепочки: мог не запускаться транспорт, закончиться доступ к каталогу очереди или возникнуть локальная ошибка конфигурации. В мониторинг передаю раздельные логические признаки «служба доступна», «queue manager наблюдается», «новые попытки доставки присутствуют». Такое разделение не позволяет маскировать локальную остановку общим сообщением про внешний MX и сокращает путь от события к проверяемому компоненту.

Read-only wrapper и минимальные права агента

Для Zabbix agent я создаю узкий wrapper с фиксированными действиями: посчитать состояния, получить возраст старейшего deferred, сформировать возрастные корзины и агрегировать уже разрешённые классы ошибок. Он не принимает произвольные аргументы, не вызывает shell, не меняет очередь и возвращает строгий числовой либо JSON-результат. Если чтение postqueue требует повышения прав, правило sudo разрешает только конкретный wrapper или конкретную команду с неизменяемыми аргументами, без редактора, подстановок и универсального запуска от root. Файл принадлежит администратору и недоступен агенту для записи. UserParameter ссылается на этот путь; обработка ошибок различает недоступность команды, пустую очередь и невалидный вывод. Перед включением я проверяю команду именно от пользователя агента. Официальное описание UserParameters помогает сверить синтаксис и ограничения на конкретной версии Zabbix.

Контролируемая проверка, откат и практический контакт

Проверку провожу на непроизводительном маршруте или заранее согласованном тестовом адресе. Отправляю одно маркированное сообщение, наблюдаю его переход, появление обезличенного класса результата и изменение возрастной корзины; рабочую очередь принудительно не повторяю. Для ветки временного отказа использую только безопасно управляемый тестовый получатель, чтобы не воздействовать на чужой MX. До начала записываю исходные права, UserParameter и путь wrapper. Откат понятен: отключить новый item, вернуть прежний конфигурационный фрагмент, удалить узкое sudo-правило и убедиться, что агент больше не вызывает сбор; почтовые сообщения тестового контура обрабатываются по заранее согласованному правилу. После проверки сравниваю Zabbix с postqueue и журналом. Если нужен такой разбор вашей очереди без раскрытия корреспондентов, я, Семёнов Евгений Сергеевич, доступен через IT Fresh: Telegram @ITfresh_Boss, +7 903 729-62-41.

Отвергнутые альтернативы

• Тревога по одному фиксированному числу писемОдинаковая длина очереди может означать штатный краткий пик или устойчивую недоставку; выводу нужны динамика, возраст и класс ответов.
• Принудительно повторять всю очередь при каждом ростеМассовая повторная доставка увеличивает нагрузку, нарушает естественный backoff и не исправляет DNS, TLS либо ограничения внешнего MX.
• Считать любой deferred локальной неисправностью PostfixВременный отказ часто возвращает получатель, его фильтр или канал; сначала нужен точный ответ попытки и его контекст в журнале.
• Передавать строки очереди в событие ZabbixВывод команд содержит почтовые адреса и идентификаторы; для мониторинга достаточно чисел, возраста и нормализованного класса ошибки.
• Дать агенту неограниченный sudo или shellПроверка только читает подготовленные агрегаты, поэтому широкие административные полномочия не соответствуют задаче и увеличивают риск.

Конфигурация и сбор

Только read-only доступ к агрегатам очереди Postfix, разрешённым строкам mail log и состоянию службы. Zabbix agent не получает содержимое писем, адреса, очередь на изменение, интерактивный shell или общие административные команды.

• Снять отдельные количества active, deferred и hold через фиксированный wrapper и сопоставить их с ручным postqueue -p.
• Получить возраст старейшего deferred и распределение qshape; при отсутствии qshape применить проверенный разбор вывода конкретной версии.
• Агрегировать delivery status и SMTP error code из mail log по временному окну, удалив адреса и идентификаторы до возврата результата.
• Проверить состояние службы, queue manager и свежесть попыток доставки от имени пользователя Zabbix agent.

Контролируемая проверка и свидетельство

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

Фрагмент рабочего регламента

• Сравнить postqueue -p и mailq, зафиксировав только агрегаты active, deferred и hold.
• Проверить qshape и возраст старейшего deferred без копирования адресов или queue ID в рабочую запись.
• Связать статус с mail log локально и выбрать причину: внешний MX, DNS, TLS, SASL либо rate limiting получателя.
• Подтвердить состояние службы и queue manager, затем проверить результат wrapper от пользователя агента.

Откат

Сохраняются исходные конфигурация UserParameter, права wrapper и sudo-правило. Для отката item отключается, прежний фрагмент возвращается, точечное разрешение удаляется, конфигурация агента перечитывается штатным способом и подтверждается прекращение вызовов. Очередь Postfix при этом не очищается и принудительно не запускается.

Ограничения вывода

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