Demo
Demo
База знаний PMTA›Механизм§ 11.22

Метрики узла в стандартном формате

Prometheus metrics exporter
Единственная поверхность, которую чужой мониторинг понимает сам

Третий путь наблюдения за узлом — и единственный, чей вывод готовая система мониторинга понимает без переводчика. Появился в PowerMTA 5.5.

Что отдаётся, по группам:

Группа Метрики Что открывает
трафик получатели, письма, байты, соединения спрос и его сезонность
насыщение глубина очереди в получателях и байтах, текущие соединения приближение к пределу
ошибки 4xx, 5xx, внутренние; отдельно очередные доля неудач
задержки длительность разговора, время до первой попытки ранние признаки беды

Метки различают направление и способ подачи. У трафика есть srcType: подача по SMTP, по API отправки, внутренняя (например, уведомления о недоставке), по Transmissions API и засеивание. То есть видно, каким путём пришли письма, — а этого не показывает ни монитор, ни учёт.

Это сводки, а не события. Вендор говорит прямо: набор рассчитан на здоровье системы в целом, и разбирать по нему отдельные письма не предполагается — для этого есть учёт и журнал.

Три метрики требуют отдельного включения: обе задержки разговора (track-inbound-perf-stats, track-outbound-perf-stats) и время до первой попытки (track-time-first-attempt). Остальные работают сразу с блоком.

Главная ловушка — ждать здесь ответа про конкретное письмо. Поверхность агрегатная по устройству. Она отвечает «сколько» и «как быстро в среднем», но не «что случилось с этим получателем» — на это отвечает учёт.
Что делает Хаб. Не пользуется: своя телеметрия приходит вебхуком учёта, а текущее состояние Хаб забирает опросом управляющего интерфейса.

🔎 В схеме место под это предусмотрено — колонка node_engines.metrics_port, — но её никто не заполняет: путь наметили и не прошли.

🔎 И это единственная поверхность узла, которой не нужен наш секрет. Управляющий интерфейс требует ключа, вебхук — токена, а метрики отдаются как есть. Клиенту, у которого свой мониторинг, её можно отдать одной строкой в конфигурации, ничего больше не открывая.

Рекомендуемые значения

Собственных значений у механизма нет — его включает блок, а три метрики открываются строками уровня узла:

Что нужно Чем включается
вся поверхность блок <prometheus-listener>
задержка приёма track-inbound-perf-stats
задержка отправки track-outbound-perf-stats
время до первой попытки track-time-first-attempt
разбивка последней по приёмникам time-first-attempt-domains-file
Состав метрик, метки, оценка накладных расходов и требования к включению отдельных величин — из руководства (§ 11.22). Замечание про единственную поверхность без нашего секрета — наше.
Пример в конфигурации
# блок отдаёт метрики; три строки добавляют к ним задержки
<prometheus-listener 0/0:9090></prometheus-listener>

track-inbound-perf-stats true
track-outbound-perf-stats true
track-time-first-attempt true
Порт надо закрыть межсетевым экраном так же, как управляющий: метрики рассказывают о нагрузке узла достаточно, чтобы это было интересно постороннему.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

Типичные ошибки и проблемы

что делают не так и чем это кончается3 ошибки▶

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

§ 11.22

Чем чреватоПоверхность агрегатная: счётчики, датчики и сводки. Судьбы конкретного получателя в ней нет и не будет.
Как заметитьИщут в метриках, дошло ли письмо конкретному адресату.
Как правильноСмотреть учёт — он именно про отдельные события.

Оставляют порт метрик открытым наружу

наш опыт

Чем чреватоМетрики рассказывают об объёмах, доле ошибок и глубине очереди — то есть о состоянии дел. Секрета они не требуют, а значит и не защищены ничем.
Как заметитьПорт слушателя отвечает с произвольной машины.
Как правильноЗакрыть межсетевым экраном, оставив доступ системе мониторинга.

Настраивают блок и ждут метрик задержек

§ 11.22

Чем чреватоТри величины требуют отдельного включения строками уровня узла. Без них соответствующие метрики остаются пустыми.
Как заметитьТрафик и очередь есть, задержек нет.
Как правильноВключить track-inbound-perf-stats, track-outbound-perf-stats и track-time-first-attempt.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Наследование
Наследования у механизма нет — наследуются директивы, которыми он включается. Блок на узле один, и метрики отдаются целиком: выбрать подмножество нельзя.
⇄

Связанные записи

4 связи

Зависит от

track-time-first-attemptGlobalОткрывает сводку времени до первой попытки; без неё эта метрика пуста. § 11.22

Чем можно заменить

Состояние узла целиком одним документомТот же срез текущего состояния, только своим форматом и без нашего ключа. § 11.22Отдача показателей по SNMPСоседняя поверхность чтения со своей моделью доступа и своим форматом. inference

Где это видно

Отдача показателей сборщикуКак именно устроена отдача: формат, типы метрик и их семантика. § 14

Как проверить на узле
Проверка прямая — забираем метрики так же, как их забирает мониторинг:
curl -s http://NODE:9090/metrics | head -30
В ответе строки вида pmta_traffic_recipients_total{direction=”out”,…}. Пусто или отказ соединения — блок не настроен либо порт закрыт. Метрики задержек появятся только при включённых строках подсчёта.
◇

Что ещё почитать

3 статьи

◇Пять способов очереди отдать письмоОчередь не обязана ходить по SMTP: она умеет писать в файл, запускать программу, стучаться по HTTP или выбрасывать.◇Как письмо попадает в MTAШесть описанных способов подачи: расширенный SMTP, четыре языковые обвязки и каталог, за которым узел следит на диске.◇Что узел рассказывает о себе и по каким каналамСемь поверхностей наблюдения: веб-монитор, консоль в четырёх форматах, журнал, учёт, поиск по учёту, метрики и выгрузка во внешнюю аналитику.

В Хабе
Цена ошибки
безопасно: неверное значение ничего не ломает
Сценарии
Подключить платформу отправки · Собрать телеметрию