Global
Строка включает подсчёт длительности исходящей сделки SMTP — от MAIL FROM до конца DATA в разговоре с приёмником. Умолчание — false.
🔴 Как и её пара, полезна только вместе с <prometheus-listener>: величина попадает только в метрику pmta_smtp_request_duration_seconds с меткой direction=”out”.
Это не время доставки письма. Это длительность одного разговора: письмо могло сутки пролежать в очереди, а сделка занять полсекунды. За задержку до первой попытки отвечает другая строка — track-time-first-attempt.
Практический смысл — различить свою беду и чужую. Растущая задержка исходящих сделок при неизменной входящей означает, что медленно отвечают приёмники, а не что перегружен узел. Это разные лечения.
🔎 Косвенно похожий вопрос панель парка отвечает по учёту — по доле временных ошибок и по глубине очереди. Но именно длительности разговора у нас нет, а она отличает «приёмник тормозит» от «узел не справляется».
Включают вместе с приёмной половиной:
| Значение | Когда |
|---|---|
| false (умолчание) | слушателя метрик нет |
| true | слушатель настроен, и нужна пара «приём — отправка» |
Порознь величины почти бесполезны: ценность в сравнении.
# пара величин, которую сравнивают между собой track-inbound-perf-stats true track-outbound-perf-stats true <prometheus-listener 0/0:9090> </prometheus-listener>
что делают не так и чем это кончается1 ошибка▶
наш опыт
2 связи
curl -s http://NODE:9090/metrics | grep pmta_smtp_request_duration_seconds
3 статьи
◇Что узел рассказывает о себе и по каким каналамСемь поверхностей наблюдения: веб-монитор, консоль в четырёх форматах, журнал, учёт, поиск по учёту, метрики и выгрузка во внешнюю аналитику.◇Сторож, который перезапускает MTAПрисматривает за MTA и после падения поднимает его сам, отправляя отчёт о падении на адрес ответственного.◇Как складывается политика для приёмникаНастройки собираются от самого общего образца к самому точному; порядок блоков в файле не значит ничего.