Файл, программа или эндпоинт — и файл под каждым из трёх

критично

accounting destinations
Под каждым способом лежит файл

Записи учёта можно писать в файл, отдавать программе через канал или отправлять на эндпоинт по HTTP. Третий способ и есть вебхук, и устроен он не так, как кажется.

Вебхук — не поток, а пачки поверх файлов. Записи копятся в файле по указанному в блоке пути, файл уходит запросом POST и удаляется только после успешной отправки. Успех — ответ 2xx и ничего больше; всё остальное вызывает повтор через небольшую задержку.

Значит, недоступный приёмник даёт накопление, а не потерю. Это хорошая новость ровно до того момента, пока не сработает нижний порог свободного места на диске и MTA не начнёт удалять старые файлы учёта. Вот против чего надо проектировать: не против потери при отказе, а против диска.

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

У канала есть отдельная опасность, названная вендором. Если запись в программу не удалась, узел бросает попытки до перезагрузки конфигурации или таймаута, и вендор советует держать рядом обычный файл, чтобы данные пережили сломанный канал.

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

Что мы за это платим: приёмник должен быть доступен. Он у нас отвечает быстро намеренно — проверяет токен, кладёт тело в кэш, ставит задачу, — потому что MTA ждёт 2xx и держит соединение.

Файловый учёт рядом с вебхуком мы держим — отдельным блоком <acct-file /var/log/pmta/acct.csv> в том же шаблоне. Это ровно та страховка, которую советует вендор: пока приёмник не обкатан, есть с чем сверить.

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

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

Способ Чем включается Что под низом
файл путь в теге <acct-file> он сам
эндпоинт http-webhook-url файл по тому же пути, удаляется после отправки
программа канал в теге блока файл рядом — по совету вендора

Расширение пути решает формат: .json — NDJSON, остальное — CSV.

Три способа, промежуточные файлы, условие успеха 2xx, повтор при любом другом ответе и опасность канала — из руководства (§ 12.1.1). Вывод про диск как общую точку отказа и совет держать файл рядом на время обкатки — наши.
Пример в конфигурации
# два способа одновременно — так делают переход
<acct-file /var/log/pmta/acct.csv>
    records d, b, t
</acct-file>

<acct-file /var/log/pmta/webhook.json>
    records d, b, t
    http-webhook-url https://hub.example.com/api/telemetry/pmta/7</acct-file>
Первый блок пишет файл, второй отправляет пачки. Пока они работают вместе, результат можно сверить и только потом выключить лишнее.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Проектируют против потери записей, а не против диска

§ 12.1.1

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

Считают выбор способа взаимоисключающим

§ 12.1.1

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

Отдают записи программе без файла рядом

§ 12.1.1

Чем чреватоПри неудачной записи в программу узел бросает попытки до перезагрузки конфигурации или таймаута. Данные за это время не сохраняются нигде.
Как заметитьПрограмма-потребитель перезапускалась, и за этот промежуток записей нет.
Как правильноДержать рядом файловый блок учёта — прямой совет вендора.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Наследование
Наследования у механизма нет — наследуются директивы, которыми он включается, а они живут внутри своих блоков <acct-file>. Блоков может быть несколько, и каждый выбирает свой способ независимо.
Как проверить на узле
Признак исправного вебхука — промежуточные файлы появляются и исчезают, а не копятся:
ls -la /var/log/pmta/ | tail -20
Растущее число файлов означает, что приёмник не отвечает 2xx. Проверить заодно стоит и свободное место: именно оно, а не потеря записей, — настоящее следствие долгого отказа приёмника.
В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Разобрать зависшую очередь · Собрать телеметрию
Важность
критично