Demo
Demo
База знаний PMTA›Блок Global›Директива§ 3.3.1.43

track-inbound-perf-stats

Global

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

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

🔴 Полезна она только вместе с <prometheus-listener>. Руководство говорит это прямо: величина никуда, кроме метрики pmta_smtp_request_duration_seconds, не попадает. В учёте её нет, в журнале тоже. Без слушателя строка считает в пустоту.

Метрика — сводка с квантилями 0,50, 0,90, 0,95 и 0,99, и метка direction различает приём от отправки. Эта строка открывает половину in, соседняя track-outbound-perf-stats — половину out.

Зачем это нужно. Задержка приёма — ранний признак насыщения: она растёт до того, как начнут копиться очереди и падать доставляемость. Подающая платформа, которая «стала медленно отправлять», часто упирается именно сюда.

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

🔎 В схеме место под это есть — колонка node_engines.metrics_port, — но она никем не заполняется. То есть путь был предусмотрен и не пройден.

Своя телеметрия у нас отвечает на другие вопросы: учёт говорит, что стало с письмом, а не сколько длился разговор. Задержка приёма — величина, которой у нас сейчас нет вовсе.

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

Включают только парой со слушателем:

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

Вторая половина — track-outbound-perf-stats: включают их обычно вместе, иначе метрика будет односторонней.

Умолчание false, определение сделки (от MAIL FROM до конца DATA) и оговорка «полезна только со слушателем метрик» — из руководства (§ 3.3.1.43, § 11.22). Толкование задержки как раннего признака насыщения — наше.
Пример в конфигурации
# обе половины метрики и слушатель, который их отдаёт
track-inbound-perf-stats truetrack-outbound-perf-stats true

<prometheus-listener 0/0:9090>
</prometheus-listener>
Без блока внизу обе строки считают в пустоту: величина попадает только в метрику.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Включают подсчёт, не настроив слушателя метрик

§ 3.3.1.43

Чем чреватоВеличина не попадает никуда: ни в учёт, ни в журнал. Строка работает вхолостую, и понять это можно только по отсутствию данных где бы то ни было.
Как заметитьСтрока включена, новых чисел нигде не появилось.
Как правильноДобавить блок <prometheus-listener> — иначе строка бесполезна.

Включают только одну половину

наш опыт

Чем чреватоМетрика получается односторонней: видно задержку приёма и не видно доставки, или наоборот. Сравнить их между собой — а именно это и отвечает на вопрос «где узкое место» — нельзя.
Как заметитьВ метрике только одно значение метки направления.
Как правильноВключать обе строки вместе.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
track-inbound-perf-stats <boolean>
Значения
yes | no | true | false
Умолчание
false § 3.3.1.43
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
Global
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Наследования нет: строка пишется в корне файла, раздел Global, и действует на все входящие сделки узла. Разделения по источникам у неё нет — метка метрики различает только направление.
⇄

Связанные директивы

2 связи

Без чего не работает

Отдача метрик узла в стандартном форматеЕдинственное место, куда попадает эта величина; без блока подсчёт идёт в пустоту. § 3.3.1.43

Работают в паре

track-outbound-perf-statsGlobalВторая половина той же метрики: одна про приём, другая про отправку. § 3.3.1.44

Сюда ссылаются

time-first-attempt-domains-file<prometheus-listener>Соседняя величина того же слушателя — задержка приёма, без разбивки по приёмникам. § 3.3.1.43

Как проверить на узле
Проверять надо у слушателя метрик — величина появляется только там:
curl -s http://NODE:9090/metrics | grep pmta_smtp_request_duration_seconds
Строки с меткой direction=”in” означают, что подсчёт работает. Их отсутствие при настроенном слушателе — что строка не включена.
◇

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

3 статьи

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

В Хабе
Цена ошибки
безопасно: неверное значение ничего не ломает
Сценарии
Собрать телеметрию
Соседние настройки блока Global:http-mgmt-porttrack-outbound-perf-statsdummy-smtp-update-statshttp-default-max-itemshttp-default-sort-orderВсе 108 директив блока →