Pong получен, а измерение ещё не обработано
Диспетчерский экран получает ответы Pong и продолжает показывать зелёный статус, хотя архив измерений остановился. Такое возможно, если протокольный обмен обслуживается отдельно от прикладного обработчика. Служебная реакция соединения полезна, но её нельзя автоматически считать доказательством сохранения данных. Для хозяйства нужно определить несколько уровней готовности и соответствующие им наблюдения.
Что именно проверяется
RFC 6455 задаёт Ping и Pong как управляющий обмен WebSocket. Их протокольная роль не включает подтверждение фиксации конкретного измерения в базе или доставки до оператора. Даже если приложение использует этот механизм для проверки соединения, смысл прикладной квитанции требуется задать собственным контрактом. (IETF RFC 6455 — WebSocket messages and control)
В карточке состояния разделяют наличие соединения, служебный ответ, работу декодера и подтверждённую обработку записи. Для каждого состояния выбирают реальный источник. Если все индикаторы питаются одним таймером Pong, интерфейс не сможет отличить зависший обработчик от полностью исправной телеметрии. Названия индикаторов должны отражать предел их доказательств.
Поставить различимый тест
На стенде отправляют учебную запись с идентификатором и наблюдают её путь. Затем предусмотренным тестовым механизмом задерживают только прикладную обработку, сохраняя соединение. Контролируют, продолжает ли поступать Pong и что показывает экран. Производственный архив ради демонстрации не останавливают; испытание проводится на изолированном потребителе без исполнительных функций.
Если система предусматривает прикладную квитанцию, её связывают с идентификатором записи и точно определённым этапом. «Получено серверным процессом» и «устойчиво сохранено» могут быть разными результатами. Если квитанции нет, это явно фиксируют и выбирают другой утверждённый способ контроля обработки. Нельзя заполнять отсутствие доказательства предположением по активности транспорта.
Настроить полезное наблюдение
Порог задержки и порядок тревоги назначает владелец эксплуатационного контракта. Статья не предлагает общий интервал для всех хозяйств. В испытании проверяют не только тревогу, но и возвращение к нормальному состоянию после обработки задержанной записи. Очередь, повтор и дубликаты должны отражаться по принятой модели, без превращения каждого служебного ответа в подтверждение данных.
В акте указывают, какой индикатор относится к соединению, а какой к прикладному результату. Приёмка завершена, когда остановка обработчика видна при продолжающемся служебном обмене и восстановление подтверждается контрольной записью. Тогда оператор получает основание обратиться к нужному компоненту системы, а не продолжает считать архив исправным только потому, что WebSocket отвечает на Ping.
