Здоровая SMPP-сессия — это не только «соединение поднято», а стабильный ритм отправки, предсказуемые задержки и честные статусы доставки. В этой статье разберём, какие метрики снимать с SMPP-шлюза и API, на какие пороги реагировать до того, как клиенты заметят задержку, и как собрать минимальный дашборд для ежедневного контроля. Всё на практике: без модных терминов, с конкретными шагами и типичными граблями, на которые наступают при росте нагрузки.
С чего начинается «здоровье» SMPP-сессии
SMPP v3.4 держит постоянное TCP-соединение между клиентом и шлюзом. Пока идёт bind_transceiver, окно keepalive, и шлюз отвечает на enquire_link, кажется, что всё работает. Но реальная картина появляется только тогда, когда смотришь на метрики трафика: скорость отправки, скорость приёма DLR, доли таймаутов и реконнектов. Просто «связь жива» — это necessary, но не sufficient.
На smpp.by техническая сторона протокола разобрана подробно, поэтому дальше сосредоточимся на операционных метриках. Их удобно делить на три слоя: канал (сеть), сессия (обмен PDU), бизнес-результат (доставлено/не доставлено). Каждый слой ловит свою категорию проблем, и только вместе они дают цельную картину.
Какие задержки измерять и в каких единицах
Задержка в SMPP — понятие многогранное, и путать их между собой — самая частая ошибка при настройке мониторинга. Фиксируйте хотя бы эти четыре:
- submit_sm latency — от момента формирования PDU клиентом до получения submit_sm_resp от шлюза. Это «время постановки в очередь».
- delivery latency end-to-end — от submit_sm_resp до DLR с финальным статусом DELIVERED. Это то, что видит клиент.
- enquire_link RTT — пинг-понг между клиентом и шлюзом. Рост RTT часто предшествует разрыву сессии.
- PDU processing time на стороне шлюза — берётся из логов провайдера или собирается через https://smpp.by/kak-ispolzovat-protokol-mcp-dlya-integratsii-llm-agentov-s-smpp-v-2026-godu, если используется прослойка MCP-агента.
Снимайте p50, p95 и p99 для каждой метрики, а не только среднее. Среднее по доставкам в SMS-рассылках обманчиво: основная масса уходит за 2–3 секунды, но хвост из 1–2% «тяжёлых» сообщений тянет p99 в десятки секунд. Именно хвост рождает жалобы «у меня SMS опоздало на полчаса».
Минимальный набор порогов: что считать нормой, а что — алертом
Универсальных цифр нет: у каждого шлюза и оператора связи своя топология и своя нагрузка. Но ориентиры, от которых отталкиваются, выглядят так. Дальше их подстраивают под собственную историю наблюдений.
| Метрика | Норма (p95) | Жёлтая зона | Красная зона |
|---|---|---|---|
| submit_sm_resp | ≤ 200 мс | 200–800 мс | > 800 мс или рост в 2 раза за час |
| delivery latency end-to-end | ≤ 10 с | 10–30 с | > 30 с или растёт тренд за сутки |
| enquire_link RTT | ≤ 1 с | 1–3 с | > 3 с или таймауты |
| Доля DLR UNDELIVERABLE | ≤ 2–3% | 3–7% | > 7% или резкий скачок |
| Реконнекты в час | 0 | 1–2 | > 3, особенно кластерами |
Жёлтая зона — это не «всё плохо», это «пора смотреть глазами»: открыть графики нагрузки, сверить с плановыми рассылками, проверить, нет ли массовой отправки на проблемный префикс. Красная зона — повод писать провайдеру, потому что вы уже на грани пользовательских жалоб.
Как собирать метрики на практике: API vs SMPP-канал
Если у вас классический HTTP API для отправки и отдельный SMPP-канал для bulk-рассылок, метрики лучше собирать в двух местах и сводить в один дашборд. Из HTTP API возьмите время ответа и HTTP-коды. Из SMPP — submit_sm_resp, DLR, enquire_link. Склейка по message_id позволяет видеть весь путь конкретного сообщения. Это сильно упрощает разбор спорных случаев, когда клиент говорит «не получил», а система показывает DELIVERED.
Очередь сообщений и rate limit — отдельная история, и про неё подробно написано в материале https://smpp.by/kak-postroit-ochered-sms-v-api-i-smpp. Главное правило: метрики очереди (глубина, время ожидания, процент отброшенных) живут рядом с метриками SMPP, потому что рост очереди напрямую бьёт по delivery latency. Вы не поймёте, почему вырос p99, пока не положите рядом график глубины очереди.
DLR и «ложные» DELIVERED: как не обмануться
Статус DELIVERED в DLR означает, что оператор связи подтвердил доставку на устройство. Но бывают сценарии, когда DELIVERED приходит, а клиент SMS не видел. Причины — устаревший HLR-кэш, буферизация на старых моделях телефонов, ошибки абонентской базы, глюки конкретного оператора. Сами по себе такие случаи редки, но при большом потоке даже 0,5% превращаются в десятки жалоб в день.
Что делать: заведите отдельную метрику «жалобы на неполученные» (из CRM, чатов, звонков) и сравнивайте её с долей DELIVERED. Если жалоб больше, чем 0,3–0,5% от доставленных, это повод проверить HLR-запросы и настройки маршрутизации. Дубли и повторные отправки, которые тоже бьют по доверию клиентов, разобраны в статье https://smpp.by/pochemu-sms-otpravlyaetsya-dvazhdy.
Типичные ошибки при мониторинге SMPP-сессии
- Считать только среднюю задержку и не смотреть на p95/p99. Средняя «зелёная» при растущем хвосте — иллюзия стабильности.
- Мониторить только канал, забывая про очередь. Рост очереди на 2–3 часа до отправки легко превращает 5-секундный latency в 5-минутный.
- Алертить по абсолютным порогам без учёта тренда. Резкий рост метрики за час важнее, чем её текущее числовое значение.
- Смешивать технические и бизнес-метрики в одном графике без комментариев. Команда видит скачок UNDELIVERABLE, но не понимает, что в этот час была разовая рассылка на старые номера.
- Игнорировать enquire_link RTT. Рост пинга до шлюза обычно на 10–15 минут предшествует разрыву соединения.
- Не фиксировать версию конфигурации шлюза и ПО клиента. Без этого потом не восстановить, что именно сломалось.
Что положить в дашборд и как часто на него смотреть
Минимальный дашборд для ежедневной работы: 4 графика задержек (p50, p95, p99), 2 графика долей (UNDELIVERABLE, EXPIRED), 1 график глубины очереди и 1 — реконнектов. Частота просмотра: утром — сводка за ночь, днём — при плановых рассылках и после них, вечером — контрольный взгляд. Алерты в Telegram или e-mail настраивайте только на красную зону, иначе команда быстро начнёт их игнорировать.
Если у вас несколько SMPP-подключений к разным провайдерам, полезно вывести сравнительный график: какой провайдер даёт стабильнее delivery latency на конкретном направлении. Это основа для перераспределения трафика и переговоров о ценах. Параллельно можно следить за стоимостью доставленного сообщения: когда p95 растёт, растёт и удельная стоимость, потому что вы платите и за ретраи, и за повторные отправки.
Не забывайте про нагрузочное тестирование. Метрики «в продакшене» показывают текущее состояние, а понять предел пропускной способности до пиков можно только на стенде. Здесь пригодится отдельный материал про нагрузочное тестирование SMPP-интеграции. Без него вы узнаете о пределе в худший момент — в разгар распродажи, когда трафик упрётся в потолок.
3 шага, которые можно сделать на этой неделе:
- 1. Снять текущие p50/p95/p99 по submit_sm_resp и delivery latency за последние 7 дней и записать как baseline.
- 2. Настроить алерты на красную зону по таблице выше, вывести дашборд на экран команды.
- 3. Сопоставить долю жалоб «не получил» с долей DELIVERED и при расхождении проверить HLR и маршрутизацию.
