Как настроить мониторинг SMS-интеграции в 2026 году

Для малого бизнеса мониторинг SMS-интеграции начинается с четырёх показателей: доли доставленных сообщений, времени ответа API или SMPP, числа ошибок и задержки получения статуса DLR. Такая схема помогает понять, где возник сбой: в приложении, очереди, соединении со шлюзом или на маршруте доставки. В статье разберём, какие метрики собирать, как установить SLO без сложной инфраструктуры и какие алерты действительно требуют реакции.

Какие метрики показывают состояние SMS-интеграции?

Одна цифра «отправлено» почти ничего не говорит о качестве сервиса. Приложение могло принять запрос, но не передать его в SMPP-шлюз. Шлюз мог принять сообщение, однако оператор вернул ошибку или не прислал статус вовремя. Поэтому мониторинг связывает несколько этапов одной отправки.

Для каждого сообщения полезно хранить технический идентификатор, время постановки в очередь, время передачи, ответ шлюза и итоговый статус. Такой журнал позволяет сопоставить событие в CRM с записью в SMS-системе. Если клиент сообщает, что не получил подтверждение заказа, оператор сможет проверить конкретную попытку, а не искать её среди всех отправок.

Статусы лучше привести к единой схеме: «создано», «в очереди», «принято шлюзом», «доставлено», «не доставлено», «истёк срок ожидания». При этом исходный код ошибки SMPP или API нужно сохранять отдельно. Иначе команда увидит только общий статус «ошибка» и не поймёт, нужно ли повторить отправку.

Как задать SLO для SMS без лишней математики?

SLO — это рабочая цель для сервиса. Она описывает, какой уровень качества бизнес считает приемлемым за выбранный период. Для небольшой компании не требуется сразу строить сложную систему расчётов: достаточно определить цели для приёма запроса, передачи сообщения и получения конечного статуса.

• API или SMPP принимает корректный запрос без недоступности соединения.
• Сообщение покидает внутреннюю очередь за установленное для бизнеса время.
• Система фиксирует DLR и связывает его с исходным идентификатором.
• Ошибки получают понятную категорию и не исчезают из журнала.

Для разных типов SMS нужны разные цели. Код подтверждения заказа и уведомление о переносе доставки требуют быстрой обработки. Рекламная кампания терпит задержку, если отправка идёт по расписанию. Поэтому одну общую метрику для всех сообщений лучше не использовать: разделите трафик по назначению и сравнивайте одинаковые сценарии.

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

Какие алерты нужны небольшой компании?

Алерт должен сообщать о событии, на которое кто-то может отреагировать. Если уведомление приходит при каждом единичном сетевом сбое, сотрудники быстро перестают его читать. Для начала настройте несколько правил с временным окном и повторной проверкой.

Для алерта задайте условие, интервал и адресата. Например, система отправляет уведомление, если очередь растёт пять минут, а не после одного неудачного запроса. Для критичного сбоя сообщение можно направить ответственному сотруднику, а для статистического отклонения оставить запись в ежедневном отчёте.

Проверяйте также сам мониторинг. Если сервис отправляет тестовое SMS, но проверяет только факт ответа API, он не замечает проблемы с DLR. Контрольная проверка должна проходить весь путь: создать тестовое сообщение, получить ответ шлюза, дождаться статуса и сверить идентификатор.

Как связать мониторинг с SMPP и HTTP API?

SMPP и HTTP API дают разные технические события, поэтому их нельзя наблюдать одинаково. Для SMPP полезны состояние сессии, время подключения, ответы на команды и число переподключений. Для HTTP API отслеживают код ответа, время выполнения, таймауты и долю неуспешных запросов.

На уровне приложения добавьте correlation ID, который проходит через CRM, очередь и шлюз. Он помогает найти одну отправку в нескольких журналах. Для SMPP отдельно сохраняйте message ID, полученный после принятия сообщения. Именно по нему обычно связывают отправку с DLR, а не по номеру телефона или тексту.

Повторы требуют отдельного контроля. Если приложение не получило ответ из-за таймаута, оно не знает, принял ли шлюз сообщение. Без ключа идемпотентности повтор может создать дубль. Практика защиты от повторной отправки и ошибок на границе API и SMPP разобрана в материале почему SMS отправляется дважды.

Временные ошибки можно повторять с увеличивающейся паузой, но лимит попыток задаётся заранее. Ошибка формата номера, запрещённого значения или неверного параметра не исправится от повторов. Логика должна различать такие случаи, иначе очередь заполнится бесполезными задачами. Подход к автоматической обработке SMPP-ошибок описан в статье как не терять SMS при ошибках SMPP.

Какие типичные ошибки мешают мониторингу?

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

Для малого бизнеса разумно начать с одного дашборда и нескольких периодов: последний час, текущий день и предыдущая неделя. На первом экране разместите очередь, ошибки, долю финальных статусов и состояние SMPP-сессии. Такой набор уже показывает, нужна ли техническая реакция, проверка данных в CRM или обращение к провайдеру.

Если мониторинг должен работать без ручного просмотра журналов, пригодится готовая схема контроля транзакционных SMS с метриками и уведомлениями: как настроить мониторинг SMS без программиста. Интеграцию можно строить вокруг API, SMPP или обоих каналов, если бизнесу нужен резервный маршрут.