Блок <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 дней |
Блоков может быть несколько, и это главный приём: разные вопросы — разные файлы.
# два блока учёта: телеметрия и страховка — разные вопросы, разные файлы <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>
что делают не так и чем это кончается3 ошибки▶
наш опыт
наш опыт
§ 3.3.11.5
3 связи
Доставлено — запись, по которой считают всёСамая частая запись потока: письмо доставлено получателю. § 3.3.11Что узел рассказывает о себе и по каким каналамОдна из трёх поверхностей наблюдения за узлом — та, из которой берётся история, а не текущее состояние. § 1.4
records<acct-file>Первая из двух строк, задающих, что вообще попадёт в учёт. § 3.3.11.11record-fields<acct-file>Вторая из двух строк, задающих, что попадёт в учёт. § 3.3.11.12privacy-policy<acct-file>Обезличивание применяется к записям этого потока перед тем, как они лягут на диск. § 3.3.11.16queue-filter<acct-file>Сужает поток записей по имени очереди ещё до того, как они лягут в файл. § 3.3.11.5map-header-to-field<acct-file>Подменяет содержимое стандартного поля в записях этого потока. § 3.3.11.10delete-after<acct-file>Сколько живут закрытые файлы этого потока. § 3.3.11.1
head -1 "$(ls -t /var/log/pmta/acct-*.csv | head -1)"
3 статьи
◇Что узел рассказывает о себе и по каким каналамСемь поверхностей наблюдения: веб-монитор, консоль в четырёх форматах, журнал, учёт, поиск по учёту, метрики и выгрузка во внешнюю аналитику.◇Как устроена запись учётаКак устроена запись учёта: вид записи в первом столбце, дальше поля, состав которых настраивается.◇Отдача показателей сборщикуОтдача показателей узла внешнему сборщику в его формате.