Сводный отчёт SparkPost Signals: метрики отправки за выбранный период с группировкой по домену получателя, домену отправки — части заголовка Sender или From, — кампании (это идентификатор задания), адресу отправки и пулу адресов.
Отчёт живёт в приложении SparkPost, а не в мониторе узла: узел только отправляет туда данные учёта и сам ничего оттуда не читает. Доступ к отчёту — учётной записью SparkPost, а не http-access.
Пересекается с нашей аналитикой: разрезы те же. Оценка здоровья от самой службы живёт не здесь, а в обзоре Signals.
Данные приходят с задержкой: службе нужно несколько тысяч писем и пакетная обработка, так что при первом подключении отчёт может заполниться только через сутки.
Где что смотреть:
| Вопрос | Где |
|---|---|
| метрики отправки в разрезе службы | здесь |
| отказы по классификации SparkPost | отчёт об отказах Signals |
| оценка здоровья и спам-ловушки | обзор Signals |
| точные числа по узлу | учёт узла |
# без блока signals данные в службу не уходят и отчёт пуст <signals> api-key 0123456789abcdef012345678901234567890123</signals>
1 связь
grep -n -A3 '<signals>' /etc/pmta/config grep -n 'enable-signals' /etc/pmta/config
3 статьи
◇Что узел рассказывает о себе и по каким каналамСемь поверхностей наблюдения: веб-монитор, консоль в четырёх форматах, журнал, учёт, поиск по учёту, метрики и выгрузка во внешнюю аналитику.◇Сторож, который перезапускает MTAПрисматривает за MTA и после падения поднимает его сам, отправляя отчёт о падении на адрес ответственного.◇Как складывается политика для приёмникаНастройки собираются от самого общего образца к самому точному; порядок блоков в файле не значит ничего.