Мониторинг SMPP через DLR помогает понять, что произошло с каждым SMS после отправки: сообщение доставили, отклонили, поставили в очередь или не удалось передать оператору. В статье разберём, какие статусы сохранять, как считать успешность доставки, когда отправлять алерты и как отличить сбой канала от проблем с номерами. Эти правила подходят небольшому интернет-магазину, сервисному центру и другому бизнесу, который отправляет уведомления через SMPP.
Что такое DLR и почему одного ответа submit_sm недостаточно?
При отправке SMS приложение передаёт шлюзу сообщение через SMPP-команду submit_sm. Ответ шлюза подтверждает, что запрос принят на этом участке. Такой ответ ещё не означает, что абонент получил SMS. Сообщение может попасть в очередь, завершиться ошибкой маршрутизации или не дойти до телефона.
DLR, или Delivery Receipt, приходит позже и описывает результат обработки сообщения. Шлюз связывает отчёт с исходным SMS через идентификатор сообщения. Приложение получает этот отчёт по отдельному SMPP-соединению или в рамках transceiver-сессии, затем меняет статус отправки в своей базе.
Для мониторинга нужно хранить как минимум:
- идентификатор сообщения, который вернул SMPP-шлюз;
- внутренний идентификатор заказа или операции;
- время отправки запроса и время получения DLR;
- номер назначения в безопасном для логов виде;
- исходный статус доставки и текст диагностической причины, если шлюз её передаёт;
- счётчик повторных попыток и последний результат.
Отдельно полезно зафиксировать состояние, когда приложение отправило SMS, но DLR ещё не пришёл. Такой статус нельзя сразу считать ошибкой: задержка отчёта и окончательный отказ — разные события. Для понимания формата статусов пригодится материал о выгрузке статусов SMPP в 1С: принцип одинаков, даже если вместо 1С используется собственная система.
Какие статусы DLR нужно учитывать?
Названия статусов зависят от шлюза и маршрута, поэтому приложение не должно проверять только одно строковое значение. Надёжнее привести ответы к внутренней группе: «доставлено», «окончательная ошибка», «в обработке» и «неизвестно». Исходный код при этом нужно сохранить, чтобы инженер мог разобрать спорный случай.
| Группа | Примеры смысла | Действие системы |
|---|---|---|
| Доставлено | Сообщение принято сетью назначения и доставлено абоненту | Закрыть отправку как успешную, записать время доставки |
| В обработке | Сообщение ожидает обработки или отчёт ещё не завершён | Оставить отправку открытой и контролировать срок ожидания |
| Окончательная ошибка | Номер недоступен по маршруту, сообщение отклонено или истёк срок доставки | Зафиксировать причину и решить, нужен ли повтор |
| Временная ошибка | Временная перегрузка, очередь или кратковременная недоступность | Повторить по ограниченной политике, не создавая бесконечный цикл |
| Неизвестно | Шлюз прислал код, которого нет в таблице приложения | Сохранить исходные данные и отправить технический алерт |
Статус «доставлено» тоже стоит проверять аккуратно. DLR сообщает результат, который вернул маршрут, а не подтверждает, что человек прочитал текст. Поэтому в отчётах бизнеса лучше писать «доставлено» и «не доставлено», не подменяя эти понятия открытием сообщения или фактом получения заказа.
Как считать успешность доставки по DLR?
Для малого бизнеса достаточно начать с простой раздельной статистики. За выбранный интервал посчитайте количество сообщений в каждой группе и отдельно покажите отправки без финального DLR. Если смешать ожидающие сообщения с отказами, показатель будет трудно интерпретировать: задержка отчётов начнёт выглядеть как падение доставки.
Минимальный набор метрик выглядит так:
- число принятых шлюзом SMS;
- доля сообщений с финальным статусом «доставлено»;
- доля окончательных ошибок;
- число временных ошибок;
- количество сообщений без DLR после заданного срока ожидания;
- время от submit_sm до получения DLR;
- распределение ошибок по кодам, маршрутам и типам уведомлений.
Считайте показатели по короткому временному окну и сравнивайте их с обычным уровнем именно для этого канала. Авторизация, уведомление о готовности заказа и код подтверждения могут иметь разный объём и разные требования к скорости, поэтому единый порог для всех сообщений часто даёт ложные тревоги.
Для каждой отправки полезно хранить два времени: момент принятия запроса шлюзом и момент получения финального DLR. Так инженер увидит, где возникла задержка. Если submit_sm проходит, а отчёты перестают приходить, нужно проверять приём DLR, идентификаторы сообщений и соединение. Если уже submit_sm возвращает ошибки, искать проблему следует раньше, на этапе передачи.
Какие алерты поставить на SMPP-канал?
Алерт должен сообщать о событии, на которое можно ответить. Сообщение «доставка снизилась» бесполезно без периода, выборки и причины. Уведомление для владельца бизнеса и уведомление для разработчика тоже лучше разделить: первому нужен факт влияния на заказы, второму — технические детали.
Практический набор сигналов:
- нет новых DLR за заданный интервал при наличии отправленных сообщений;
- доля финальных ошибок заметно выше обычного уровня;
- один код ошибки повторяется у большого числа сообщений;
- растёт очередь сообщений со статусом «в обработке»;
- DLR приходят с неизвестным идентификатором;
- SMPP-сессия разорвана или перестала отвечать на служебные проверки;
- приложение не успевает обрабатывать входящие отчёты.
Порог выбирают по объёму трафика. При небольшом количестве SMS процент может резко измениться из-за одной ошибки, поэтому полезно сочетать относительное условие с минимальным числом сообщений. Например, алерт запускают только при заметной доле ошибок и при достаточном объёме отправок за интервал. Конкретные значения лучше подобрать после периода наблюдения, а не брать из чужой конфигурации.
В сообщение об ошибке добавьте время, идентификатор канала, группу статуса, код DLR, число затронутых SMS и ссылку на технический журнал внутри вашей системы. Сам текст SMS и полный номер получателя в уведомление о сбое обычно не нужны. Для повторной отправки пригодятся правила, описанные в материале о повторе SMS при Throttling и Message Queue Full.
Как связать DLR с healthcheck SMPP?
DLR показывает путь конкретного сообщения, а healthcheck проверяет, живо ли само соединение. Эти механизмы дополняют друг друга. Канал может отвечать на служебные запросы, но не передавать отчёты в приложение. Бывает и обратная ситуация: DLR для старых сообщений ещё приходят, а новая отправка уже получает отказ.
В healthcheck обычно проверяют:
- состояние bind-сессии и роль соединения: transmitter, receiver или transceiver;
- ответ на Enquire Link и время ответа;
- возможность принять входящий DLR;
- величину очереди исходящих SMS и очередь необработанных отчётов;
- долю submit_sm с ошибкой;
- наличие DLR за контрольный период, если за это время были отправки.
Служебная проверка соединения сама по себе не заменяет тестовую отправку. Для настройки механизма поддержания SMPP-сессии можно обратиться к инструкции как настроить Enquire Link на SMPP-шлюзе. В рабочей системе Enquire Link должен иметь тайм-аут, журнал событий и понятное действие при разрыве: переподключение, перевод трафика в резерв или остановка повторов.
Типичные ошибки при мониторинге DLR
- Считать ответ submit_sm доставкой. Принятие запроса шлюзом и доставка абоненту фиксируются на разных этапах.
- Удалять исходный код DLR после нормализации. Внутренняя группа удобна для отчёта, но технический код нужен для расследования.
- Повторять каждую ошибку. Для недействительного номера повтор не поможет и создаст лишний трафик. Повторы оставляют для временных причин.
- Проверять только процент доставки. При малом объёме один отказ сильно меняет процент, поэтому смотрят ещё на абсолютное число, очередь и коды ошибок.
- Игнорировать сообщения без DLR. Их нужно выделять отдельно и контролировать срок ожидания.
- Не тестировать переподключение. Система должна корректно восстановить bind, не потерять входящие отчёты и не отправить одно сообщение повторно без контроля идентификатора.
3 шага, которые можно сделать на этой неделе:
- Составить таблицу соответствия кодов DLR внутренним группам и сохранить исходные значения.
- Добавить метрики по доставленным, ошибочным, ожидающим и неизвестным статусам, а также по задержке получения отчёта.
- Настроить два алерта: на отсутствие DLR при активной отправке и на всплеск окончательных ошибок, после чего проверить сценарий разрыва SMPP-сессии.
