Договор о телеметрии

критично

<acct-file>
Всё, что парк способен измерить, описано здесь

Блок <acct-file> — граница между MTA и всем, что ниже по потоку, Хаб включительно. Он отвечает на пять вопросов, и других источников у этих ответов нет.

Вопрос Строка
какие события records — восемь видов
какие поля record-fields, плюс заголовки письма через header_ИМЯ
куда путь в теге, канал или http-webhook-url
как сменяются файлы move-to, move-interval, max-size, delete-after
что скрыть privacy-policy

🔴 Не выбранное поле не восстановит никакая обработка внизу. Оно даст не ошибку, а пустоту — и это худший вид потери: тихий. Ровно так же не выбранный вид записей — это событие, которого для аналитики не произошло.

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

Обе строки понимают отрицание — *,!поле и !имя — то есть конфигурацию можно писать как «всё, кроме», а не перечислением. Это заметно устойчивее к появлению новых полей в следующих версиях.

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

Телеметрия — вебхук на наш адрес: пять видов записей (d, b, rb, t, feedback-loop), у каждого стандартный набор полей, у доставок и отказов ещё время первой попытки, время в очереди и число повторов, у жалоб — заголовок Feedback-ID. Пачка раз в минуту, потолок 1 МБ. Это и есть источник всех панелей парка.

Файлы на узле — блок <acct-file /var/log/pmta/acct.csv>, к имени MTA дописывает дату: acct-2026-09-15-0000.csv. В них доставки и оба вида отказов (d, b, rb) с теми же добавочными полями, потолок 25 МБ и срок хранения неделю. Их читает модуль «Статистика учёта».

Перемещения у файлов нет: строку move-interval 5m, которая без move-to молча ничего не делала, убрали 29.08.2026. Новый файл начинается с новой датой в имени, а внутри суток — по достижении потолка размера.

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

Собственных значений у механизма нет: их задают строки блока.

Что настраивается Чем Умолчание
виды записей records d,b
поля record-fields все
формат расширение в пути CSV, .json даёт NDJSON
обезличивание privacy-policy не обезличивать
хранение delete-after 8 дней

Блоков может быть несколько, и это главный приём: разные вопросы — разные файлы.

Восемь видов записей, отрицание в обеих строках, зависимость формата от расширения и взаимодействие строк смены файлов — из руководства (§ 3.3.11, § 12.1). Вывод про невосстановимость и правило сверять набор полей на парке — наши.
Пример в конфигурации
# два блока учёта: телеметрия и страховка — разные вопросы, разные файлы
<acct-file /var/log/pmta/mtahub-webhook.json>
    records d, b, rb, t, feedback-loop    record-fields d  *
    http-webhook-url https://hub.example.com/api/telemetry/pmta/7
    http-webhook-max-interval 1m
</acct-file>

<acct-file /var/log/pmta/acct.csv>
    max-size 25M
    delete-after 7d
</acct-file>
Во втором блоке строки видов нет — действует умолчание d,b. Для страховочного файла этого хватает; если по файлу строят статистику, в него добавляют и rb.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Предполагают набор полей на узлах вместо сверки

наш опыт

Чем чреватоПриёмник ждёт определённый состав, а узел ничем не обязан его писать. Недостающее поле даёт внизу пустоту, а не ошибку, и обнаруживается через недели.
Как заметитьВ аналитике колонка есть, значений нет ни у одной записи с конкретного узла.
Как правильноСверять заголовок файла учёта на узлах при заведении и после каждого обновления конфигурации.

Настраивают учёт «по текущим потребностям»

наш опыт

Чем чреватоВопросы к данным появляются позже, а данные за прошлое не дописываются. Каждое сужение — это отложенная невозможность ответить.
Как заметитьНовый вопрос требует поля, которого нет в истории.
Как правильноБрать всё (*) и сужать только по измеренной причине — месту на диске или требованию к составу данных.

Сужают поток отбором в единственном блоке

§ 3.3.11.5

Чем чреватоОтфильтрованные записи не попадают никуда. В отличие от узкого набора полей, здесь теряются целые события.
Как заметитьВ статистике пропали целые направления отправки.
Как правильноДержать полный блок и вести отбор во втором.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Наследование
Наследования у механизма нет — наследуются директивы, которыми он включается, а все они живут внутри своего блока. Блоки друг о друге не знают: одно и то же событие может попасть в несколько файлов с разным набором полей и разной степенью обезличивания.
⇄

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

3 связи

Как проверить на узле
Главная проверка на парке — не «пишется ли учёт», а «те ли поля в нём». Смотрим заголовок файла:
head -1 "$(ls -t /var/log/pmta/acct-*.csv | head -1)"
Состав колонок надо сверить с тем, что ждёт приёмник. Расхождение даст внизу по потоку не ошибку, а пустые значения — и заметить это можно только так, глядя на сам файл.
В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Разобраться с доставляемостью · Собрать телеметрию
Важность
критично