Документация
Полное руководство по настройке мониторинга сайтов с PingZen. Документация API, примеры кода и лучшие практики.
WebSocket-монитор открывает настоящее WebSocket-соединение с вашим адресом — то же рукопожатие с апгрейдом, которое делает браузер, — и, если вы попросите, отправляет одно сообщение и читает ответ, после чего закрывает соединение. Работает и с ws://, и с wss://; защищённый вариант отличается только тем, что соединение идёт поверх TLS.
Для чего подходит
Реалтайм, в котором пользователи сидят весь день
Чат, живые дашборды, котировки, канал уведомлений, игровой сервер. Они ломаются по своему расписанию: страница открывается нормально, а живая её часть тихо перестаёт работать.
Само рукопожатие с апгрейдом
Чаще всего WebSocket ломается не из-за мёртвого сервера. Прокси, балансировщик или CDN перед ним перестаёт пропускать апгрейд, либо маршрут начинает отвечать обычной HTTP-ошибкой. HTTP-монитор на том же хосте при этом показывает, что всё зелено. Эта проверка либо доводит рукопожатие до конца, либо нет.
Один круг по вашему собственному протоколу
Отправьте сообщение после подключения — ping-кадр, команду подписки, маленький JSON-запрос — и потребуйте кусочек текста в ответе. Тогда проверка упадёт и в случае, когда сокет открывается, а приложение за ним отвечать перестало.
Сокеты на нестандартных портах и путях
Адрес — это полный URL с путём, поэтому сокет по адресу wss://example.com:8443/api/stream проверяется ровно там, где он живёт, а не в корне сайта.
Для чего не подходит
Проверка открывает одно соединение, обменивается максимум одним сообщением и закрывается. Для остальных вопросов нужны другие мониторы:
| Что нужно узнать | Что использовать |
|---|---|
Когда истекает сертификат на адресе wss://? Этот монитор вообще не записывает данных о сертификате — истекающий сертификат не виден до того дня, когда он сломает рукопожатие | Монитор TLS/SSL-сертификата на тот же хост и порт, рядом с этим |
| Работает ли сайт или REST API на том же сервере? | Монитор HTTP / HTTPS |
| Открыт ли просто порт, без всякого WebSocket-рукопожатия? | Монитор TCP |
| Работает ли целый пользовательский сценарий — войти, открыть страницу, увидеть, как приходят сообщения в настоящем браузере? | Монитор Transaction, который прогоняет настоящий браузер по нескольким шагам |
| Делает ли воркер или потребитель на той стороне сокета свою работу? | Heartbeat-монитор, который дёргает сам воркер |
Что делает проверка
- Подключается к адресу и выполняет WebSocket-рукопожатие с апгрейдом — для
wss://сначала поднимается TLS. - Записывает время отклика: время до момента, когда соединение открылось. Всё, что происходит дальше, в него не входит.
- Если вы задали сообщение — отправляет его одним текстовым кадром и ждёт один ответ.
- Если вы задали ожидаемый ответ — проверяет, что этот текст есть в ответе.
- Закрывает соединение.
В результате сохраняются время отклика, ответ сервера, обрезанный до первых 500 символов, и текст ошибки, если проверка не прошла. Больше ничего: ни HTTP-статуса, ни полей сертификата.
Две детали стоит знать до того, как полагаться на проверку сообщением. Смотрится только первый ответ, поэтому на сокете, который здоровается с каждым клиентом приветственным кадром, сравниваться будет именно это приветствие. А если сервер принял ваше сообщение и затем штатно закрыл соединение, не ответив, проверка всё равно считается успешной — сравнивать просто не с чем.
Логика статусов
| Результат | Статус |
|---|---|
| Соединение открылось — и ответ совпал, если вы его задали | UP |
| Рукопожатие не прошло: адрес ответил как обычный HTTP, прокси не пропустил апгрейд или сервер отклонил запрос | DOWN |
| Соединение отклонено, имя не резолвится или сломался TLS | DOWN |
| В ответе не оказалось вашего текста — сам ответ сохраняется, чтобы было видно, что пришло | DOWN |
| Сервер закрыл соединение с ошибкой, пока проверка ждала ответа | DOWN |
| Соединение не открылось за отведённый таймаут | TIMEOUT |
У WebSocket-монитора нет середины: он либо работает, либо упал, либо не дождался. Промежуточного «жёлтого» состояния здесь нет, поэтому любой сбой из таблицы считается простоем и после подтверждения может открыть инцидент.
Сертификаты на wss://
Проверка wss:// идёт поверх TLS, но на сам сертификат она не смотрит. Она не читает ни дату окончания, ни издателя, ни детали цепочки и ничего из этого не сохраняет в результате.
Это важно в день, когда сертификат истечёт: рукопожатие перестанет работать, и монитор упадёт с ошибкой соединения — впервые и без предупреждения заранее. Чтобы узнать об этом на неделю-две раньше, заведите монитор TLS/SSL-сертификата на тот же хост и порт. Два монитора работают рядом: этот следит, работает ли сокет сегодня, сертификатный — будет ли он работать через месяц.
Настройки
Адрес
Полный URL сокета вместе с путём: wss://example.com/socket. Вставленный адрес с http:// или https:// превращается в ws:// или wss://, а адрес без схемы получает ту, что соответствует типу монитора. Порт указывайте, если он не стандартный: 80 для ws:// и 443 для wss://.
Сообщение для отправки (необязательно)
Отправляется одним текстовым кадром сразу после открытия соединения, до 2048 символов. Оставьте пустым — и проверка остановится на рукопожатии, что само по себе уже полезный сигнал.
Ожидаемый ответ (необязательно)
Кусочек текста, который должен где-то встретиться в ответе: подстрока, а не полное совпадение, и регистр важен. Работает только тогда, когда сообщение отправлено и сервер ответил. Держите его коротким и стабильным: слово статуса из JSON-кадра переживёт смену схемы, целый кадр — нет.
Таймаут
Сколько времени даётся на открытие соединения. По умолчанию 5 секунд, допустимо от 1 до 120. Сокету, которому и в хороший день нужно больше, стоит поднять значение, а не терпеть мигающий монитор.
Что ещё уходит в рукопожатии
Рукопожатие простое: субпротокол не согласуется, свои заголовки не отправляются. Если ваш адрес требует токен, чтобы принять соединение, этот токен должен помещаться в URL — например, в параметр запроса.
Ключевые возможности
- Проверяет и
ws://, иwss://, на любом порту и любом пути - Доказывает, что рукопожатие с апгрейдом проходит, — HTTP-монитор на том же хосте этого не умеет
- Необязательная проверка сообщением с поиском подстроки в ответе сервера
- Ответ сохраняется вместе с результатом, обрезанный до 500 символов, поэтому при несовпадении видно, что пришло
- Время отклика измеряется до момента, когда соединение открылось
- Обычное поведение «работает / упал / таймаут», с инцидентами и оповещениями, как у любого монитора
Частые вопросы
Какие протоколы можно мониторить?
PingZen поддерживает 23 протокола: HTTP/HTTPS, WebSocket (WS/WSS), TCP, UDP, ICMP Ping, gRPC, DNS, WHOIS, TLS/SSL сертификаты, Email (SMTP/IMAP/POP3), FTP/FTPS, DNSBL, PageSpeed, SOCKS5, MTProxy, API Check и Transaction. Вы можете мониторить сайты, API, серверы, базы данных и любые сетевые сервисы.
Как быстро приходят оповещения?
Telegram оповещения доставляются в течение 1-2 секунд после обнаружения. Slack и Discord уведомления приходят практически мгновенно. Вы можете настроить несколько каналов оповещений для резервирования.
Можно ли организовать мониторы по проектам?
Да! PingZen поддерживает рабочие пространства, которые позволяют организовать мониторы по проектам, окружениям или командам. Каждое рабочее пространство может иметь свои настройки оповещений и участников.
Есть ли API для автоматизации?
Абсолютно. PingZen предоставляет полный REST API с OpenAPI документацией. Вы можете создавать, обновлять и удалять мониторы программно.
Как работают статус-страницы?
Статус-страницы — это публичные брендированные страницы, показывающие аптайм ваших сервисов. Вы можете отображать статус в реальном времени и позволить клиентам подписаться на обновления.
Что происходит, если я достигну лимита мониторов?
Мы уведомим вас при приближении к лимиту. Вы можете приостановить некоторые мониторы или связаться с нами для увеличения лимита. Мы никогда не останавливаем мониторинг без предупреждения, обеспечивая защиту ваших критически важных сервисов.
Готовы перестать пропускать даунтаймы?
Присоединяйтесь к тысячам команд, которые доверяют PingZen. Настройка за 30 секунд.