Мы используем файлы cookie для улучшения вашего опыта. Продолжая посещать этот сайт, вы соглашаетесь с использованием cookie.Политика конфиденциальности
Мониторинг Postfix в Prometheus и Grafana: postfix_exporter, графики и алерты — EvilMail Blog
Метрики Postfix в Prometheus и Grafana: очереди, задержки доставки и алерты, которые реально ловят инциденты
Blackbox-чек «порт 25 отвечает» не спасёт, когда в deferred висит 40k писем, а доставка ушла в минуты. Разбираем, как postfix_exporter достаёт глубину очередей и задержку доставки по стадиям из mail.log и сокета showq, строим графики в Grafana и пишем алерты с порогами, которые не будят дежурного из-за одного ретрая.
EvilMail Team26 июля 2026 г.14 мин чтения
3 часа ночи. Все blackbox-чеки зелёные: nc -zv mx1 25 отвечает, TLS-handshake проходит, аптайм-пробы показывают сплошную зелень за неделю. А в саппорте копятся тикеты: «письма приходят через 10–15 минут». Заходишь на сервер — postqueue -p | tail -1 показывает 41 273 сообщения в очереди. Принимающая сторона крупного провайдера включила throttling час назад, Postfix честно ретраит по своему backoff-расписанию, deferred растёт, а узнали вы об этом не из графика, а из злого клиента.
Проблема не в том, что не было мониторинга. Проблема в том, что мониторили не то. postfix_up и TCP-коннект на 25-й порт отвечают на вопрос «жив ли процесс», а не на вопрос «доставляется ли почта и как быстро». Настоящие сигналы здоровья MX — это глубина очередей и распределение задержки доставки по стадиям пайплайна. И то, и другое Postfix уже пишет в свои штатные источники — надо только снять.
Что мерить на самом деле: очередь и задержка, а не «процесс жив»
У Postfix четыре рабочие очереди, и рост каждой означает разное:
incoming — только что принятые письма ждут постановки в active. Рост здесь редок и обычно значит, что qmgr не справляется с темпом приёма.
active — то, что qmgr прямо сейчас пытается доставить. Ограничена (qmgr_message_active_limit, по умолчанию 20000). Держится высокой — значит, доставка в реальном времени упирается в лимиты или медленный next-hop.
deferred — письма, которые не удалось доставить с первого раза и которые ждут ретрая. Это ваш главный индикатор. Рост deferred = принимающая сторона greylist'ит, throttl'ит или лежит.
hold / maildrop / corrupt — hold обычно наполняется руками (postsuper -h) или политикой; внезапный рост hold — чей-то забытый -h ALL.
Второе, что прячется от blackbox, — задержка доставки. Причём смотреть надо не среднее (среднее размазывает хвост ретраев и врёт), а p95/p99. Одно письмо, которое ретраится 40 минут, в среднем растворится среди тысяч мгновенных, но именно оно — ваш инцидент. И задержку нужно раскладывать по стадиям. Postfix в каждой строке лога пишет delays=a/b/c/d, и это готовая диагностика: рост a (приём + DNSBL + milter), b (ожидание в очереди), c (DNS + TLS до next-hop) и d (передача данных) указывает на совершенно разные корневые причины.
Вот инциденты, которые видны только по этим метрикам и невидимы для аптайм-чека:
Забитый deferred из-за greylisting/throttling принимающей стороны — очередь растёт, процесс жив.
Всплеск before_queue_manager, когда тормозит DNSBL или milter — приём замедляется на входе.
Рост connection_setup при MTU/TLS-проблемах к апстриму — DNS резолвится, а handshake висит.
Наполнение hold-очереди после ручного postsuper -h — почта стоит, метрики приёма в норме.
Как postfix_exporter снимает данные: два источника
Стандарт де-факто — kumina/postfix_exporter. Слушает :9154, отдаёт /metrics и берёт данные из двух независимых источников.
Источник 1 — mail.log (или journald). Экспортёр парсит строки лога регэкспами: события cleanup, qmgr, smtp/lmtp, smtpd превращаются в счётчики и гистограммы. Именно отсюда берётся postfix_smtp_delivery_delay_seconds — экспортёр вытаскивает поле delays=a/b/c/d из каждой строки доставки.
Источник 2 — unix-сокет `/var/spool/postfix/public/showq`. Из него экспортёр читает бинарный снапшот очередей — тот же, что отдаёт postqueue -p, — и строит гистограмму размеров сообщений по каждой очереди. Отсюда postfix_showq_message_size_bytes_count{queue=...} — число писем в incoming/active/deferred/hold/maildrop прямо сейчас.
Режимы чтения логов взаимоисключающие: либо --postfix.logfile_path /var/log/mail.log, либо --systemd.enable для journald. И здесь же — типовая причина пустых метрик. Для чтения mail.log экспортёру нужна группа adm (или systemd-journal в journald-режиме). Для сокета showq — группа postdrop: сам сокет имеет режим 0660 root:postdrop. Если postfix_showq_* пустые, а postfix_up равен 1 — на 99% процесс экспортёра не в группе postdrop.
Установка и systemd-юнит
Берёте готовый релиз или собираете go build. Кладёте бинарь в /usr/local/bin/, заводите отдельного пользователя и пишете юнит:
SupplementaryGroups=adm postdrop systemd-journal — та самая строчка, из-за отсутствия которой люди неделями смотрят на полупустой дашборд. Если читаете файловый лог, а не journald — уберите --systemd.enable и добавьте --postfix.logfile_path=/var/log/mail.log.
Проверка сразу после systemctl enable --now postfix_exporter:
postfix_up 1 значит только, что экспортёр видит Postfix. Чтобы отличить «запустился, но логи не читает», сразу проверьте, что наполняются оба класса метрик:
Relabel вычищает порт из instance, чтобы на графиках было mx1.evilmail.pro, а не mx1.evilmail.pro:9154. scrape_interval: 15s достаточно: чтение сокета showq не бесплатное, а более частая дискретизация в 5s ничего полезного не покажет.
Главное правило работы с этими метриками: все счётчики сбрасываются при рестарте экспортёра, поэтому любой запрос по счётчикам строится через rate() или increase(), никогда по абсолютному значению. Исключение — postfix_showq_*: это gauge (снимок текущего состояния), их можно и нужно читать напрямую.
Ключевые метрики и что за ними стоит
`postfix_smtpd_messages_processed_total{sasl_method}` — входящий приём на smtpd. Лейбл sasl_method разделяет аутентифицированных отправителей от анонимных.
`postfix_smtp_delivery_delay_seconds_bucket{stage}` — гистограмма задержки доставки, stage ∈ {before_queue_manager, queue_manager, connection_setup, transmission}. Прямое соответствие полю delays= в логе. Ваш главный диагностический инструмент — по тому, какая стадия растёт, вы понимаете, куда бежать.
`postfix_showq_message_size_bytes_count{queue}` — число писем в очереди, queue ∈ {incoming, active, deferred, hold, maildrop}.
`postfix_qmgr_messages_inserted_size_bytes` / `postfix_qmgr_messages_removed_total` — темп постановки в очередь и вымывания из неё.
`postfix_cleanup_messages_rejected_total` — reject на этапе cleanup (обычно политики/размер/заголовки).
`postfix_smtpd_sasl_authentication_failures_total` — провалы SASL. Резкий рост = брутфорс или уже скомпрометированный аккаунт перебирает пароли.
postfix_lmtp_delivery_delay_seconds_*** — задержка доставки в Dovecot по LMTP, отдельно от исходящего smtp.
Графики в Grafana
Диаграмма ниже — ключ к чтению задержки. Она связывает поле лога delays=, лейбл stage в метрике и конкретное действие инженера.
Набор панелей с готовым PromQL:
promql
# Входящий rate (писем/с)
sum(rate(postfix_smtpd_messages_processed_total[5m]))
# Глубина deferred по инстансам — отдельным ярким графиком
sum(postfix_showq_message_size_bytes_count{queue="deferred"}) by (instance)
# p99 задержки доставки с разбивкой по стадиям
histogram_quantile(0.99,
sum(rate(postfix_smtp_delivery_delay_seconds_bucket[5m])) by (le, stage))
# Доля reject на cleanup
sum(rate(postfix_cleanup_messages_rejected_total[5m]))
# Провалы SASL
sum(rate(postfix_smtpd_sasl_authentication_failures_total[5m])) by (instance)
Отдельно стоит панель «дыхание сервера» — просто rate входящих сообщений. Здоровый MX всегда чем-то дышит; внезапный ровный ноль — dead-air, значит smtpd перестал принимать (упал listener, забился фильтр, кто-то поменял smtpd_client_connection_count_limit). Этот график ловит инциденты, которые не поднимают ни одну очередь, потому что письма просто не входят.
Community-дашборд для kumina/postfix_exporter существует, но stage-разбивку delivery_delay в нём обычно приходится добавлять руками — а она-то и есть самое ценное.
Алерты по объёму и задержкам
Пороги ниже — для transactional MX. Для bulk/newsletter-потока их надо ослаблять: там deferred в тысячи — норма жизни.
PostfixDeferredGrowing — for: 15m, а не мгновенно, потому что кратковременный всплеск deferred при недоступности одного получателя — норма. Устойчивые 1000+ пятнадцать минут подряд — уже системная проблема доставки.
PostfixDeliveryDelayHigh — берём именно stage="transmission": рост здесь значит медленный next-hop, а не ваши DNSBL. for: 10m отсекает единичный долгий ретрай.
PostfixDeadAir — окно [10m] и for: 10m защищают от ложняка на низкотрафиковом MX ночью; на транзакционном узле, который должен дышать круглосуточно, десять минут тишины — реальный инцидент.
PostfixSaslBruteforce — 5 провалов/с устойчиво пять минут — это уже не «клиент забыл пароль», а атака или скомпрометированный ящик, который стоит немедленно заблокировать.
Чеклист внедрения
Сокет showq доступен экспортёру — процесс в группе postdrop, postfix_showq_* не пустые.
postfix_up равен 1 и наполняются метрики приёма (postfix_smtpd_messages_processed_total).
Все четыре очереди видны в showq_* — incoming, active, deferred, hold.
Гистограмма delivery_delay наполняется по всем четырём stage, а не только по одному.
Все запросы по счётчикам через rate()/increase(), showq — как gauge напрямую.
Минимум пять алертов подключены к Alertmanager с осмысленными for:.
Дашборд импортирован и проверен на реальном всплеске: postsuper -r ALL для реквея или искусственный defer — вы должны увидеть, как поднимается deferred и вырастает нужная стадия задержки.
Blackbox-проба порта 25 остаётся полезной как самый внешний слой — она ловит сетевые падения. Но инцидент доставки почти всегда начинается тихо: очередь ползёт вверх, одна стадия задержки расширяет хвост, а процесс всё это время зелёный. Дашборд по этим метрикам даёт те самые 15–30 минут форы — увидеть график раньше, чем его увидит клиент.
