Логирование ошибок в STOMP.js начинается с понимания того, что протокол STOMP работает поверх WebSocket и формально разделяет ошибки на несколько уровней: транспортный (WebSocket), протокольный (STOMP frame), прикладной (логика обработки сообщений и брокер), а также ошибки подтверждения доставки и подписок. Каждый уровень требует отдельной стратегии фиксации событий, поскольку единый механизм отладки в STOMP.js отсутствует.
В процессе работы STOMP.js ошибки возникают не только при разрыве соединения, но и на этапе установления сессии, подписки и обработки сообщений. Наиболее характерные источники:
WebSocket-уровень
STOMP-уровень
Прикладной уровень
STOMP.js предоставляет несколько точек перехвата ошибок, которые формируют основу системы логирования.
На уровне транспорта используется стандартный обработчик WebSocket:
onWebSocketErroronWebSocketCloseТиповая задача этих обработчиков — фиксировать события разрыва и диагностировать причины нестабильности соединения.
Особенность заключается в том, что WebSocket не всегда передаёт текстовую причину ошибки. Поэтому логирование часто ограничивается кодами закрытия соединения и временными метками.
Пример структуры логирования:
При успешном подключении сервер может вернуть ERROR frame, который является ключевым источником диагностической информации.
В STOMP.js это обрабатывается через:
client.onStompErrorСодержимое ERROR frame обычно включает:
Логирование на этом уровне должно сохранять:
Особое значение имеет сохранение исходного frame без преобразований, поскольку брокеры (ActiveMQ, RabbitMQ, Apollo) формируют разные форматы ошибок.
Процесс установления соединения также подвержен сбоям, особенно при использовании авторизации или прокси.
Типовые проблемы:
В STOMP.js логирование строится вокруг callback:
onConnectonStompErroronWebSocketCloseКлючевой аспект — различие между отказом соединения на уровне WebSocket и отказом на уровне STOMP. В первом случае отсутствует STOMP frame, во втором приходит ERROR frame с деталями.
Подписки создаются через client.subscribe, и ошибки
здесь часто имеют скрытый характер.
Типовые ситуации:
STOMP.js не предоставляет прямого error callback для subscribe, поэтому логирование строится косвенно:
Callback обработки сообщений является наиболее частым источником runtime-ошибок.
Типовой обработчик:
message => { ... }Основные риски:
Практика логирования включает:
Особое значение имеет разделение:
При использовании клиентского подтверждения
(ack: client) появляется дополнительный класс ошибок.
Сценарии:
Логирование должно фиксировать:
Дополнительно важно фиксировать повторную доставку одного и того же message-id, так как это напрямую влияет на идемпотентность системы.
Heartbeat в STOMP используется для обнаружения “тихих” обрывов соединения.
Ошибки:
STOMP.js фиксирует heartbeat через таймеры, но логирование требует отдельной диагностики:
Такие ошибки часто не приводят к явному disconnect, но вызывают деградацию доставки сообщений.
Эффективная система логирования в STOMP.js строится как единый pipeline:
1. Уровень транспорта
2. Уровень протокола
3. Уровень сообщений
4. Уровень приложения
Каждое событие должно иметь единый формат:
При высокой нагрузке логирование без агрегации приводит к потере диагностической ценности.
Используются подходы:
Дополнительно важна классификация:
При использовании брокеров сообщений (RabbitMQ, ActiveMQ, Apollo) логирование STOMP.js должно учитывать, что часть ошибок генерируется сервером, а часть — промежуточной инфраструктурой.
Поэтому важно сохранять:
Это позволяет сопоставлять клиентские логи с серверными trace-логами.
Connection refused
Broker authentication failed
Message not delivered
Unexpected disconnect
Handler exception
Логирование в STOMP.js представляет собой не линейный процесс, а многослойную систему наблюдения за состоянием соединения, протокола и обработки данных. Эффективная диагностика возможна только при сохранении контекста всех уровней взаимодействия и строгой корреляции событий между транспортом и прикладной логикой.