Мониторинг SMS-интеграции: метрики API, очереди и доставки

SMS-интеграция может отвечать HTTP 200 и при этом работать плохо: очередь растёт, DLR задерживаются, один оператор показывает аномальную недоставку, а важные уведомления уступают место массовой кампании. Поэтому мониторинг строят по всей цепочке, а не только по доступности API.

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

Четыре слоя метрик

Первый слой — бизнес-события. Сколько оплат, заказов или запросов OTP должно было породить SMS и сколько задач реально создано. Без этого незаметен сбой до очереди.

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

Третий — SMS API: latency, ошибки по классам, 429, таймауты, доля принятых запросов и скорость отправки.

Четвёртый — доставка: финальные DLR, время до статуса, доля постоянных ошибок и разрез по оператору, маршруту, Sender ID и сценарию.

Главная метрика — возраст, а не только размер

Очередь из тысячи задач может быть нормальной при высокой скорости, а десять задач с возрастом двадцать минут — критичными для OTP. Поэтому алерт строят по возрасту старейшей задачи и процентилям ожидания, отдельно для классов трафика.

Сравнивайте возраст с TTL. Если сообщение уже не успеет принести пользу, система должна остановить отправку и зафиксировать причину. Настройка срока жизни разобрана в статье про TTL SMS.

API-метрики

Отслеживайте p50, p95 и p99 времени ответа, а не только среднее. Ошибки группируйте на временные, постоянные, лимит и внутренние. Отдельная метрика нужна для неоднозначных таймаутов, когда неизвестно, принял ли провайдер сообщение.

Доля HTTP 200 без сопоставимого message ID тоже является ошибкой контракта. Успех означает, что система получила идентификатор и сохранила связь с correlation ID.

Метрики DLR

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

Полезные показатели:

• доля финальной доставки;
• доля pending старше ожидаемого окна;
• время от события до принятия API;
• время от принятия до delivered;
• доля expired и permanent failure;
• неизвестные коды DLR;
• дубликаты и нарушения порядка webhook.

Единый маппинг статусов провайдеров делает эти метрики сопоставимыми.

Разрезы и кардинальность

Начните со сценария, провайдера, оператора, маршрута, Sender ID, типа трафика и среды. Не добавляйте номер телефона, message ID или correlation ID в labels метрик — уникальные значения перегрузят систему наблюдения.

Конкретный идентификатор хранится в логах и трассировках. Из графика оператор переходит к выборке логов по времени и стабильным измерениям, а затем исследует отдельные сообщения.

Алерты

Алерт должен означать действие. Примеры:

• старейший OTP в очереди превысил допустимый возраст;
• доля 429 растёт несколько минут;
• permanent failure у одного оператора существенно выше базовой линии;
• нет DLR для сообщений, принятых определённое время назад;
• расход или сегменты растут быстрее объёма бизнес-событий;
• появились неизвестные provider status;
• конкретный критичный сценарий перестал создавать задачи.

Фиксированный порог полезен для жёсткого SLO, а сравнение с обычной линией — для сезонных показателей. Алерт по одному событию часто шумит; используйте устойчивое окно и минимальный объём выборки.

Synthetic-проверка

Периодическая тестовая SMS на контролируемые номера помогает проверить путь до устройства, но сама создаёт расходы и не покрывает всех абонентов. Маркируйте такие сообщения отдельным сценарием, ограничьте частоту и исключите их из бизнес-аналитики.

Synthetic не заменяет реальные DLR. Он подтверждает, что выбранный маршрут в данный момент способен доставить несколько тестов, но не доказывает качество всего трафика.

Dashboard для разных ролей

Дежурному нужны возраст очереди, ошибки, DLR и активные инциденты. Владельцу продукта — выполнение сценариев и влияние на клиента. Финансам — сегменты, стоимость и аномалии расходов. Одна перегруженная панель редко подходит всем.

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

Runbook рядом с алертом

Алерт содержит ссылку на короткие действия: проверить очередь, статус провайдера, последние релизы, конкретные коды и возможность безопасно остановить сценарий. При внешнем сбое используется отдельный план действий при отказе SMS-провайдера.

После инцидента корректируют не только порог. Добавляют недостающую метрику, автоматический предохранитель или диагностическое поле, которое сократит следующий разбор.

Чек-лист

• есть метрика ожидаемых и созданных SMS-задач;
• очередь контролируется по возрасту и классу трафика;
• API latency измеряется процентилями;
• 429, таймауты и постоянные ошибки разделены;
• DLR считаются после окна созревания;
• доступны разрезы по оператору и сценарию;
• уникальные ID не попадают в labels;
• каждый алерт имеет владельца и runbook;
• synthetic-трафик ограничен и отделён от бизнеса.

Итог

Хороший мониторинг SMS связывает бизнес-событие, внутреннюю очередь, вызов API и финальный DLR. Он показывает не только факт ошибки, но и место задержки, масштаб и затронутый сценарий. Это позволяет остановить проблему до того, как её первым заметит клиент.