track-outbound-perf-stats

Global

Мерить ли длительность исходящего разговора SMTP
в конфигурации это строкаtrack-outbound-perf-stats falseвнутри блока Global
Сколько времени занимает разговор с приёмником

Строка включает подсчёт длительности исходящей сделки SMTP — от MAIL FROM до конца DATA в разговоре с приёмником. Умолчание — false.

🔴 Как и её пара, полезна только вместе с <prometheus-listener>: величина попадает только в метрику pmta_smtp_request_duration_seconds с меткой direction=”out”.

Это не время доставки письма. Это длительность одного разговора: письмо могло сутки пролежать в очереди, а сделка занять полсекунды. За задержку до первой попытки отвечает другая строка — track-time-first-attempt.

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

Главная ловушка — принять эту величину за время доставки. Разговор быстрый, а письмо шло сутки — обычная картина при щадящем режиме или лимитах. Время доставки складывается из ожидания в очереди и разговора, и первое здесь не считается.
Что делает Хаб. Не пишет и слушателя метрик не настраивает.

🔎 Косвенно похожий вопрос панель парка отвечает по учёту — по доле временных ошибок и по глубине очереди. Но именно длительности разговора у нас нет, а она отличает «приёмник тормозит» от «узел не справляется».

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

Включают вместе с приёмной половиной:

Значение Когда
false (умолчание) слушателя метрик нет
true слушатель настроен, и нужна пара «приём — отправка»

Порознь величины почти бесполезны: ценность в сравнении.

Умолчание false, определение сделки и оговорка «полезна только со слушателем метрик» — из руководства (§ 3.3.1.44, § 11.22). Разделение «своя беда против чужой» — наше.
Пример в конфигурации
# пара величин, которую сравнивают между собой
track-inbound-perf-stats true
track-outbound-perf-stats true
<prometheus-listener 0/0:9090>
</prometheus-listener>
Сравнение и есть смысл: растёт исходящая при ровной входящей — тормозят приёмники; растут обе — узел.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

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

наш опыт

Чем чреватоСчитается только разговор. Ожидание в очереди — а это обычно большая часть времени доставки — сюда не входит вовсе.
Как заметитьМетрика показывает доли секунды, а письма идут часами.
Как правильноСмотреть track-time-first-attempt — она про задержку до первой попытки.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
track-outbound-perf-stats <boolean>
Значения
yes | no | true | false
Умолчание
false § 3.3.1.44
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
Global
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Наследования нет: строка пишется в корне файла, раздел Global, и действует на все исходящие сделки. Разбить метрику по приёмникам нельзя — метка различает только направление.
Как проверить на узле
Проверять надо у слушателя метрик:
curl -s http://NODE:9090/metrics | grep pmta_smtp_request_duration_seconds
Строки с меткой direction=”out” означают, что подсчёт работает. Рядом должны быть квантили 0.5, 0.9, 0.95 и 0.99 — это сводка, а не одно число.
В Хабе
Цена ошибки
безопасно: неверное значение ничего не ломает
Сценарии
Разобраться с доставляемостью