dummy-smtp-update-stats

Global

Подмешивать ли поддельный трафик в статистику узла
в конфигурации это строкаdummy-smtp-update-stats trueвнутри блока Global
Единственная строка, которая портит настоящие данные

Решает, попадает ли трафик поддельного приёмника в счётчики, которые показывает веб-монитор и команда состояния узла. Умолчание — true, то есть попадает.

Остальные семь строк семьи настраивают саму подделку и за пределы прогона не выходят. Эта — выходит: она смешивает нагрузочный прогон с боевой отправкой в одних и тех же цифрах.

Разделить их потом нельзя. Счётчик накопительный, признака «это был прогон» в нём нет; остаётся помнить дату прогона и вычитать на глаз.

Главная ловушка — про неё вспоминают после прогона. Нагрузочный прогон — это обычно десятки или сотни тысяч писем за час: цифра, которая перекрывает суточную боевую отправку и делает дневной отчёт бессмысленным. К моменту, когда это замечают, счётчики уже накоплены.
Что делает Хаб. Не пишет: механизм на узлах не поднимается. Если появится, выключать эту строку придётся обязательно: Хаб снимает телеметрию с тех же счётчиков, и прогон отразится в его аналитике так же, как в мониторе узла.
Рекомендуемые значения

Выключайте до прогона, а не после. Задним числом счётчики не чистятся.

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

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

Требование выключать до прогона — наше. Из руководства здесь умолчание true и то, какие именно счётчики затрагиваются: показываемые веб-монитором состояния.
Пример в конфигурации
# прогон не должен попасть в счётчики узла
dummy-smtp-port 2525
dummy-smtp-latency 100
dummy-smtp-update-stats false
Строка стоит последней в наборе намеренно: её проще всего забыть, а последствия из всей семьи у неё единственные необратимые.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Забывают выключить перед прогоном

§ 3.3.1.57.8

Чем чреватоСотни тысяч поддельных писем ложатся в те же счётчики, что и боевая отправка. Дневной отчёт перестаёт что-либо означать, и восстановить его нельзя.
Как заметитьВсплеск отправки в мониторе, которого не было в рассылке.
Как правильноВыключать до прогона; после — сбрасывать счётчики целиком, если это допустимо.

Рассчитывают вычесть прогон задним числом

наш опыт

Чем чреватоПризнака «это был прогон» в счётчиках нет. Вычитать приходится на глаз, по памяти о том, когда он шёл и сколько писем содержал.
Как заметитьОтчёт правят вручную, объясняя расхождение датой прогона.
Как правильноВыключать строку заранее — другого способа разделить потоки нет.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
dummy-smtp-update-stats <boolean>
Значения
yes или no; true и false принимаются наравне с ними
Умолчание
true § 3.3.1.57.8
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
Global
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Строка уровня узла: пишется в корне файла, не внутри блока. Наследования у неё нет. Подхватывается по pmta reload; уже накопленные счётчики не пересчитываются — правка действует только на дальнейший трафик.
Как проверить на узле
Значение задаётся в конфигурации; накопленные счётчики печатает команда состояния:
grep -n dummy-smtp-update-stats /etc/pmta/config
pmta show status | head -20
Сбросить счётчики можно только целиком, командой сброса состояния, — выборочно вычесть прогон нельзя. Хаб снимает телеметрию с этих же счётчиков.
В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Планирование мощности