max-events-recorded

<domain>

Сколько недавних событий держится в памяти по этому домену
в конфигурации это строкаmax-events-recorded 10внутри блока <domain>
Короткая память MTA на ошибки

Сколько последних событий MTA помнит про домен получателя. Руководство уточняет: сейчас записываются только ошибки, других событий в этот список не попадает.

Это не журнал. Руководство говорит прямо: события не пишутся в файл, они держатся в памяти. Отсюда всё остальное — перезапуск службы их стирает, grep по журналу их не найдёт, а посмотреть можно только у работающего MTA: show domains с ключом –errors, show topdomains –errors или страница очереди в веб-мониторе.

Зачем это нужно. Колонка «последняя ошибка» в списке доменов — самый быстрый ответ на вопрос «что не так с этим получателем». Не надо искать в учёте и сопоставлять времена: MTA уже держит последние отказы рядом с очередью, к которой они относятся.

Умолчание — 10. Веб-монитор показывает на странице очереди ровно столько же — «последние 10 ошибок очереди».

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

Умолчание в десять событий трогать незачем: оно ничего не стоит и на разбор обычно хватает.

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

Умолчание менять не надо. Десять последних ошибок отвечают на вопрос «что происходит сейчас», а история — это учёт и журнал, а не память MTA.

Поднимать — точечно и временно. Разбираетесь с одним получателем: поставьте ему в блоке 50, посмотрите, верните обратно. В общем блоке то же число умножится на количество доменов в очереди.

Ноль осмысленно только там, где память дороже разбора, — например на маленьком узле с очень широким списком получателей.

Совет поднимать точечно — наш. Из руководства здесь умолчание 10, то, что события живут в памяти и не пишутся в журнал, что записываются только ошибки, и предупреждение о расходе памяти.
Пример в конфигурации
# общий блок оставляем как есть, поднимаем только там, где разбираемся
<domain *>
    max-events-recorded 10
</domain>

<domain problem-mailbox.example>
    max-events-recorded 50</domain>
Пример руководства ставит 3, здесь наоборот показано, зачем поднимать: глубина нужна одному получателю, а не всем сразу — память тратится на каждый домен отдельно.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Ищут эти события в журнале

§ 3.3.10.7

Чем чреватоРуководство говорит прямо: они не пишутся в файл, а держатся в памяти. Поиск по журналу ничего не даёт, и разбирательство уходит в сторону — при том, что ответ виден одной командой.
Как заметитьВ журнале про домен ничего, а в консоли у него стоит последняя ошибка.
Как правильноСпрашивать MTA командой с ключом –errors. Для истории — учёт: там события переживают перезапуск.

Поднимают глубину в общем блоке

§ 3.3.10.7

Чем чреватоПамять тратится на каждый домен. Сотня событий в блоке <domain *> на парке с сотнями получателей — это десятки тысяч записей в памяти, и руководство о таком расходе предупреждает отдельно.
Как заметитьРасход памяти MTA вырос после правки, которая «ничего не должна была изменить».
Как правильноДержать в общем блоке умолчание, а глубину поднимать в блоке конкретного получателя и возвращать обратно после разбора.

Ждут здесь события по получателям

наш опыт

Чем чреватоЗаписываются только ошибки очереди. Доставки, отказы и отложенные письма по конкретным адресам — это соседняя директива track-recipient-events, и она по умолчанию выключена.
Как заметитьВ консоли видно, что очередь ошибается, но неясно, каким адресам и с каким ответом.
Как правильноВключить track-recipient-events — она держит последние пятьдесят событий по получателям.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
max-events-recorded <integer>
Значения
целое число событий; умолчание 10
Умолчание
10 § 3.3.10.7
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<domain>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Значение сливается по блокам <domain> от общего к частному: побеждает наиболее подходящий блок, а не последний по файлу — поэтому и работает приём «в общем десять, этому пятьдесят». Подхватывается по pmta reload, перезапуск не нужен, но уже накопленные события при перезапуске службы теряются.
Как проверить на узле
События смотрят у работающего MTA — в конфигурации их нет, в журнале тоже:
pmta show domains --errors problem-mailbox.example
pmta show topdomains --errors
Первая команда печатает последние ошибки по одному домену, вторая — по самым нагруженным. Пустой список ошибок означает, что их не было с момента запуска службы, а не что их не было вообще: история живёт в учёте, а не здесь.
В Хабе
Цена ошибки
безопасно: неверное значение ничего не ломает
Сценарии
Разобраться с доставляемостью