Запись появляется, когда сервер назначения принял письмо для конкретного получателя. По одной на получателя — значит эта запись самая массовая из всех, и любая цифра об объёме отправки в итоге считается по ней.
Тип записи в строке — d. Первое поле каждой строки учёта называет тип, и по нему записи и разбирают: d — доставлено, b — отбито, t — временная неудача.
Полей тридцать шесть, по умолчанию пишется двадцать два. Набор тот же самый, что у записей об отказе и о временной неудаче, — это удобно: разбор всех трёх типов пишется один раз.
Что в записи есть. Исход и его код, время постановки в очередь и время события, адрес отправки, задание, размер, защита передачи и данные прокси, если он был. То есть достаточно, чтобы ответить и «сколько ушло», и «с какого адреса», и «шифровалась ли передача».
Чего в ней нет. Того, что случилось с письмом после приёма сервером назначения: попало ли оно в папку «Входящие», открыл ли получатель. Запись говорит только о передаче.
Приходит она потоком через веб-крючок, а не чтением файла: узел настроен отдавать записи Хабу по мере появления.
⚠️ Именно поэтому мы показываем доставляемость, а не долю «Входящих» — данных о папке у нас нет и быть не может: узел о ней не знает. Инбокс-мониторинг потребовал бы контрольных ящиков и опроса по IMAP, и это отдельная задача.
Что этой записью можно измерить, а что нет:
| Вопрос | Отвечает ли запись |
|---|---|
| сколько писем принято серверами назначения | да, это она и есть |
| с какого адреса и по какому заданию | да, поля есть |
| шифровалась ли передача | да, защита передачи записана |
| попало ли письмо во «Входящие» | нет — узел этого не знает |
| открыл ли получатель | нет — это другой источник |
Двадцать два поля из тридцати шести — умолчание, а не предел. Состав пишущихся полей настраивается; расширять его стоит осознанно: запись самая массовая, и каждое лишнее поле умножается на объём отправки.
Тот же набор полей у трёх типов записей — доставки, отказа и временной неудачи. Разбор, написанный под один тип, читает и остальные два.
# строка учёта о доставке: тип в первом поле d,2019-02-08 21:53:41+0000,2019-02-08 21:53:41+0000,CB-A=example.com@bounce.foo.com,# A@example.com,,delivered,2.0.0,smtp;250 OK,mail.example.com (10.1.2.3),...
что делают не так и чем это кончается3 ошибки▶
§ 12.2
§ 12
§ 3.3.10
3 связи
Адрес отправкиПоле с именем адреса отправки — по нему видно, какая очередь доставила письмо. § 12.2.1Версия шифрованияПоле с версией шифрования: шифровалась ли передача и как именно. § 12.2.1Сколько было попытокПоле с числом попыток: сколько раз пришлось повторить до успеха. § 12.2.1
Что узел рассказывает о себе и по каким каналамЗапись учёта, из которой складывается ответ «что стало с письмом». § 1.4pmc-acct-min-free-spaceGlobalТе же события, что уходят в учёт узла, пишутся и для консоли — отдельными файлами в формате CSV. inferencedisable-acct-records<domain>Запись о доставке — та, что пишется даже для писем, отправленных в никуда. § 3.3.10.8assume-delivery-upon-data-termination-timeout<domain>Запись доставки, сделанная на предположении, в учёте неотличима от настоящей. § 3.3.10.102Договор о телеметрииСамая частая запись потока: письмо доставлено получателю. § 3.3.11records<acct-file>Вид записи, который выбирают чаще всего: успешная доставка получателю. § 3.3.11.11
head -3 /var/log/pmta/acct-*.csv cut -d, -f1 /var/log/pmta/acct-*.csv | sort | uniq -c
3 статьи
◇Что узел рассказывает о себе и по каким каналамСемь поверхностей наблюдения: веб-монитор, консоль в четырёх форматах, журнал, учёт, поиск по учёту, метрики и выгрузка во внешнюю аналитику.◇Договор о телеметрииОдин блок описывает выход учёта целиком: какие виды записей, какие поля, куда они идут, как сменяются файлы и что обезличивается.◇Как устроена запись учётаКак устроена запись учёта: вид записи в первом столбце, дальше поля, состав которых настраивается.