Чекеры и проверки из нескольких локаций

У PingZen сейчас три собственных публичных чекера: Москва (Selectel; по умолчанию) и Новосибирск в России, и Минск в Беларуси. Если вам нужно покрытие из региона, где у нас пока нет своей точки — Турция, Болгария, Нидерланды, Иран, что угодно другое, — можно подключить свой чекер: вы предоставляете VM (минимум 2 vCPU / 2 ГБ RAM), мы деплоим на неё наш Docker-агент. Она появится в панели как ещё одна точка проверки, доступная для выбора.

Как это работает

Каждый монитор проверяется центральным сервером в Москве, одним или несколькими чекерами либо их комбинацией; на бесплатном тарифе — одним на монитор. Каждый назначенный чекер выполняет проверку по своему расписанию и отправляет результат по защищённому WebSocket-соединению. Когда вы выбираете два чекера и больше, монитор переходит в режим консенсуса (any_fails / majority_fail / all_fail) — вы сами решаете, как региональные расхождения сворачиваются в общий статус.

1. Вы предоставляете VM и SSH-доступ; мы устанавливаем на неё агент чекера PingZen (один Docker-контейнер)
2. Агент подключается к pingzen.dev по WebSocket и регистрируется в вашем рабочем пространстве
3. Каждый монитор, который вы создаёте, привязывается к одному или нескольким чекерам — выберите их в поле «Локации проверки» при создании или редактировании монитора
4. Каждый назначенный чекер выполняет проверку независимо с заданным интервалом и отправляет результат обратно
5. Результаты чекеров сводятся в общий статус монитора по выбранному вами правилу — оповещения, инциденты и карточки панели отражают именно общий статус

Протоколы на чекерах

Внешние чекеры проверяют все протоколы PingZen. Камеры (RTSP) проверяют только они, сервер PingZen — никогда.

Три протокола зависят от чекера:

• PageSpeed работает на чекере, запущенном с GOOGLE_PAGESPEED_API_KEY. У всех публичных чекеров PingZen он есть.
• Transaction (сценарии в браузере) требует образ -full с Chromium. Публичные чекеры работают на облегчённом образе, поэтому транзакцию проверяет сервер PingZen, если только ваш чекер не запущен на -full.
• RTSP: у каждой камеры ровно один чекер. Камере в локальной сети нужен приватный чекер в этой сети. Подробнее — в разделе мониторинг IP-камер по RTSP.

Провайдеры DNSBL, например Spamhaus, ограничивают или блокируют запросы с адресов дата-центров. Если провайдер отказал чекеру, проверка покажет сбой провайдера, а не попадание в список.

Проверка одного эндпоинта из нескольких локаций

Чтобы мониторить один URL из нескольких регионов одновременно, создайте по одному монитору на каждую локацию — и каждый назначьте на свой чекер. Каждый монитор независим: у него своя история аптайма, график времени отклика, инциденты и оповещения. Пример ниже предполагает, что вы уже подключили три своих чекера; подставьте свои локации.

На панели будет три карточки — по одной на регион. Если Turkey упадёт, а Bulgaria и Netherlands останутся UP, оповещение сработает только по Turkey-монитору и будет помечено локацией чекера — вы сразу видите, где именно проблема.

Что если одна локация упала, а остальные работают?

Именно этот сценарий и выявляют проверки из нескольких локаций. Каждый монитор работает независимо на своём чекере, поэтому региональный сбой (плохой маршрут ISP, блокировка на уровне страны, локальный сбой CDN) ловит только монитор в пострадавшем регионе, а мониторы в других регионах продолжают показывать UP. Пример с Turkey/Bulgaria/Netherlands ниже предполагает, что эти локации у вас развёрнуты как собственные чекеры — у самого PingZen сейчас чекеры в Москве, Новосибирске и Минске.

Такая схема делает региональные сбои очевидными. На панели одна красная карточка (Turkey) рядом с двумя зелёными (Bulgaria, Netherlands), а в оповещении указан регион, где упало, — идеально для диагностики проблем CDN-маршрутизации, ISP-блокировок или региональной цензуры.

Защита от ложных срабатываний: подтверждение сбоя

Одиночные сетевые сбои случаются постоянно. PingZen отфильтровывает их подтверждением по N проверкам подряд — одна неуспешная проверка сама по себе никогда не вызывает оповещение.

Статусы чекеров

У самого чекера тоже есть статус здоровья, он виден на панели. Он рассчитывается по heartbeat-сообщениям и метрикам event-loop, которые агент присылает каждые 30 секунд.

Типы чекеров

При регистрации чекера вы выбираете его тип — чтобы панель правильно его отображала, а другие пользователи понимали, какую связность представляют его проверки.

Как добавить свой чекер

Свой чекер — это агент PingZen, развёрнутый на вашей VM. Минимальные требования к VM: 2 vCPU / 2 ГБ RAM / 25 ГБ диска с Docker и исходящим HTTPS-доступом к pingzen.dev. На меньшие VM мы не ставим. Формат — concierge: вы предоставляете VM, мы разворачиваем агент. Контейнер обычно использует 150–400 МБ RAM в зависимости от количества мониторов, входящие порты не нужны.

1. Напишите нам в Telegram (@rassadaRB): укажите локацию (город, страна, облачный провайдер), ожидаемое число мониторов и SSH-доступ к VM (пользователь + ключ)
2. Мы генерируем ключ чекера (pzp_…) на нашей стороне
3. Мы подключаемся по SSH к вашей VM и деплоим контейнер чекера PingZen (команда ниже — только для справки, запускать её самим не нужно)
4. Как только чекер подключится, он появится как ONLINE на панели (обычно в течение минуты)
5. Вы привязываете мониторы к новому чекеру — поштучно при создании/редактировании или массово из списка мониторов

Справочно: команда, которую мы запускаем на вашей VM

docker run -d --name pingzen-checker \
  --restart unless-stopped \
  --cap-add NET_RAW \
  -e PINGZEN_URL=https://pingzen.dev \
  -e PROBE_KEY=pzp_YOUR_KEY_HERE \
  -e PROBE_REGION="Istanbul, TR" \
  -e PROBE_COUNTRY_NAME="Turkey" \
  -e PROBE_PROVIDER="Hetzner" \
  -e PROBE_TYPE=datacenter \
  registry.gitlab.com/dobryj/pingzen/checker:0.9.10

Показываем для прозрачности — чтобы вы точно видели, что именно деплоится на вашу VM. Агенту нужен CAP_NET_RAW для ICMP-проверок. Входящие правила файрвола не требуются — весь трафик — это одно исходящее WebSocket-соединение к pingzen.dev. Самостоятельная регистрация чекера через интерфейс запланирована; пока развёртывание — ручной процесс с нашей стороны.

Справочник по нагрузке (оценочно)

Числа ниже — оценки, выведенные из конфигурации шедулера (max_concurrent = 100 одновременных проверок, жёсткий лимит = 1200 мониторов на чекер), а не результат формального бенчмарка. Реальная пропускная способность зависит от размера VM, сетевого пути и целевых сервисов. Используйте как ориентир для планирования и замеряйте под реальной нагрузкой:

При интервале 300 секунд эти числа примерно удваиваются по практической нагрузке, но hard-cap 1200 всё равно действует. Чтобы превысить 1200 мониторов из одной локации — зарегистрируйте несколько чекеров на разных VM, они работают полностью независимо. У вашего тарифа свой лимит мониторов (см. страницу тарифов), который действует поверх ёмкости чекера.

Приватные внешние чекеры

Поднимите чекер на своей машине, чтобы мониторить приватные ресурсы — intranet HTTP-сервисы, AWS VPC endpoints, RFC1918 хосты, сервисы, которые блокируют публичные чекеры. Чекер сам подключается к PingZen по WebSocket — никаких входящих правил файрвола не нужно.

Требования

• Тариф: любой. FREE — 10 чекеров, PRO — 20, BUSINESS — 50, ENTERPRISE — 100.
• Linux или macOS с Docker 20.10+ и docker compose
• Исходящий 443/TCP до pingzen.dev (входящие порты открывать не нужно)
• API-ключ из вашего аккаунта: аватар (внизу слева в боковом меню) → «API-ключи» → «Создать API-ключ» (значение pz_…)

Установка

1. Создайте API-ключ: аватар (внизу слева в боковом меню) → «API-ключи» → «Создать API-ключ», скопируйте значение pz_… (показывается один раз — сохраните сразу).
2. Сохраните compose-сниппет ниже как compose.yml на машине внутри вашей приватной сети.
3. Замените PROBE_KEY на ваше значение pz_…, а PROBE_NAME — на понятное имя (например “Office LAN”, “AWS-VPC-prod”).
4. Запустите: docker compose up -d
5. Проверьте подключение — см. раздел «Проверьте подключение чекера» ниже.

services:
  pingzen-checker:
    image: registry.gitlab.com/dobryj/pingzen/checker:0.9.10
    restart: unless-stopped
    cap_add: [NET_RAW]
    environment:
      PINGZEN_URL: https://pingzen.dev
      PROBE_KEY: pz_your_api_key_here
      PROBE_NAME: "Office LAN"
      PROBE_TYPE: home # home | datacenter (optional)
      PROBE_REGION: "Office, RU" # optional

cap_add: [NET_RAW] нужен для ICMP / Ping протокол-чеков. Уберите если мониторите только HTTP/HTTPS/TCP и предпочитаете более узкий набор capabilities.

Конфигурация

Переменные окружения образа чекера. PROBE_NAME и необязательные поля видны только на ВАШЕЙ панели — перед отправкой во внешние каналы оповещений (Discord, Slack, webhook, email) они скрываются.

Проверьте подключение чекера

После docker compose up -d чекер должен зарегистрироваться примерно за 5 секунд.

1. Запустите: docker compose logs pingzen-checker --tail 20 — ищите “Probe registered: id=N name=<ваше имя>”.
2. Откройте pingzen.dev → «Мониторы» → «Добавить монитор». Ваш приватный чекер появится в поле «Локации проверки» с бейджем Private.
3. Укажите URL внутри вашей приватной сети (например http://10.0.0.5/health), выберите ваш чекер и нажмите «Проверить» — примерно через секунду должен прийти UP.

Обновление чекера

Каждый релиз выходит новым тегом образа в GitLab Container Registry (registry.gitlab.com/dobryj/pingzen/checker). На Docker Hub ilyakong/pingzen-checker лежит копия, которую мы обновляем вручную, поэтому она может отставать от релиза; команда ниже заодно переводит установку с Docker Hub. restart: unless-stopped образ заново не скачивает, поэтому обновление — отдельный шаг на хосте чекера:

cd /path/to/your/compose.yml
sed -i -E 's#(ilyakong/pingzen-checker|registry.gitlab.com/dobryj/pingzen/checker):[^ ]*#registry.gitlab.com/dobryj/pingzen/checker:0.9.10#' compose.yml
docker compose pull && docker compose up -d

Для установки через docker run: остановите и удалите контейнер, затем повторите команду из раздела «Установка» с новым тегом. Регистрация переживёт замену — идентичность чекера — это его ключ pzp_ плюс PROBE_NAME, а не контейнер.

Проверка: откройте чекер в панели — его версия сменится в течение минуты. То же видно в логе контейнера при старте: PingZen External Checker v0.9.10 starting.

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

Что изменилось в 0.9.9: камера, которая заваливает чекер видео до или после замера, больше не может забить его память: медиа перестаёт учитываться на лимите байт и кадров замера в любой фазе. Превью кадра открывает одну сессию на камеру: повторные запросы получают её же кадр, а сессия, которая ждёт дольше 25 секунд вместе с очередью, отменяется — брошенные превью больше не задерживают проверки видео других камер. Логин, вписанный прямо в адрес камеры, теперь тоже получает часовую паузу после отклонённого пароля, как логин в полях формы. В логе чекера камера названа только хостом, поэтому пароль в пути адреса (камеры XMEye) в лог больше не попадает.

Что изменилось в 0.9.8: чекер проверяет RTSP-камеры и видеорегистраторы: отвечает ли камера и пускает ли по логину, а если включена проверка видео — несколько секунд потока (кадры в секунду, битрейт, интервал ключевых кадров, потери пакетов). Кадр для превью на странице монитора декодирует ваш браузер: чекер забирает один ключевой кадр и видео не декодирует. На камеру — один вход за раз, а после отклонённого пароля чекер час не входит на эту камеру, чтобы она не заблокировала учётную запись. Долгая проверка одного протокола (транзакция в браузере, видеосэмпл камеры) больше не задерживает остальные: каждый протокол ждёт в своей очереди, прежде чем занять общий слот.

Что изменилось в 0.9.7: страницу Cloudflare с ошибкой 1009 (владелец сайта закрыл доступ из страны чекера) чекер теперь сообщает как Cloudflare error 1009: the site owner blocks visitors from RU (HTTP 403). Check the site from a probe in another region (this region, если страна на странице не названа). Монитор показывает «Региональная блокировка», а не защиту от ботов, и такая проверка не повторяется. На HTTP 401 чекер теперь называет защиту от ботов, когда в ответе есть заголовок блокировки (x-datadome от DataDome, cf-mitigated: challenge, x-px-blocked) или страница-челлендж DataDome — так отвечает reuters.com. Прочие скрипты вендоров на странице с 401 не считаются, и настоящая ошибка входа остаётся «Недоступен». 403 без названной защиты от ботов больше не подписывается Blocked by <CDN>: это обычный отказ по коду ответа, на странице монитора — «Доступ запрещён».

Что изменилось в 0.9.6: если HTTPS-проверка подключилась, а TLS-рукопожатие осталось без ответа или оборвалось — так DPI блокирует сайт по имени (SNI), — чекер теперь это проверяет. Он повторяет рукопожатие на тот же адрес без имени сайта, а затем снова с ним; если обрывается только рукопожатие с именем, результат помечается «ISP Filter», и на странице монитора вместо «медленного сервера» показывается баннер о фильтрации ISP/DPI. Статус проверки при этом не меняется. Подробнее — Детекция блокировок ISP/DPI.

Ещё в 0.9.6: сообщение о таймауте теперь называет этап, на котором проверка зависла, — например Timeout after 6 seconds during TLS handshake with example.com (203.0.113.7); tcp 48 ms, — так видно, оборвалось ли рукопожатие или сервер просто не прислал заголовки. А на «голый» HTTP 403 (без названной бот-защиты) чекер делает ещё один запрос после паузы между повторами, прежде чем засчитать проверку как DOWN, — сайт, который отказывает через раз, больше не будит вас оповещением. 403 от названной бот-защиты, монитор с выключенными повторами и монитор, чей DOWN уже подтверждён, повторно не проверяются.

Что изменилось в 0.9.5: «Проверить сейчас» на чекере возвращает результат примерно за секунду, а не ждёт до 5 секунд следующей пачки. Образ к тому же стартует быстрее: стандартная библиотека Python и код чекера поставляются уже скомпилированными, и healthcheck контейнера больше не перекомпилирует их при каждом запуске. Плановые проверки не меняются.

Что изменилось в 0.9.4: если «Проверить соединение» отклонено по причине, которую чекер и так знает — заблокированный приватный адрес, схема URL не http и не https, — в панели теперь видна сама причина, а не Checker exception: ValueError: …. Неожиданный сбой по-прежнему называет класс исключения: там класс и есть информация. На плановые проверки это не влияет.

Что изменилось в 0.9.3: HTTPS-проверка теперь читает дату окончания сертификата с того TLS-соединения, которое и так открыла — без второго рукопожатия, без лишнего трафика и без изменения длительности проверки. Статус монитора остаётся прежним: он просто вдобавок знает, сколько дней осталось сертификату, и умеет прислать оповещение «Сертификат истекает». См. Мониторинг HTTP/HTTPS. Чекер на старом образе даты сертификата не присылает — у его HTTPS-мониторов отсчёт остаётся пустым, и такое оповещение не приходит.

Что изменилось в 0.8.0: проверки честно представляются — User-Agent: PingZen/1.0 (+https://pingzen.dev/docs/bot) … с заголовком X-PingZen-Check — и записывают, какой вендор ботозащиты отказал запросу (см. Белый список для WAF и файрвола). Чекеры на старых образах шлют прежний User-Agent, пока не обновлены.

Приватность и поток данных

Результаты проверок передаются от чекера к PingZen и хранятся в нашей БД. Поля каждой проверки (URL, status, response_time, error_message) видны всем участникам вашего рабочего пространства. В оповещениях, которые уходят во внешние каналы (Discord, Slack, webhook, email, MS Teams, Mattermost, PagerDuty), ваш PROBE_NAME перед отправкой заменяется на анонимную метку “Private probe #N”. Метрики Prometheus используют метку region, которая для приватных чекеров сводится к коду страны (или к значению “private”), — внутренние имена никогда не попадают к тем, кто собирает метрики.

Устранение неполадок

Чекер не появляется в форме монитора после docker compose up -d.

Сначала проверьте логи контейнера: docker compose logs pingzen-checker --tail 50. Частые причины: (a) PROBE_KEY невалиден или отозван — сгенерируйте новый. (b) Исходящий 443 до pingzen.dev блокируется — проверьте с того же хоста: curl -v https://pingzen.dev/api/v1/health (должен вернуть JSON, не connection refused). © Достигнут лимит тарифа — приватных чекеров на аккаунт: FREE=10, PRO=20, BUSINESS=50, ENTERPRISE=100. Признак: WebSocket-рукопожатие возвращает код 4001 с причиной quota_exceeded.

Чекер регистрируется, но проверки всегда DOWN с “connection refused”.

Чекер онлайн, но не может достучаться до целевого URL изнутри своей сети. Проверьте с хоста чекера: docker compose exec pingzen-checker curl -v <ваш URL>. Частые причины: целевой сервис в другом сегменте сети, правило файрвола блокирует трафик от чекера к цели, или URL использует имя хоста, которое чекер не может разрезолвить.

Чекер отваливается каждые несколько минут (“ws_disconnected” в логах).

Обычно корпоративный proxy или NAT-firewall отрубает idle WebSocket. Чекер шлёт keepalive ping каждые 30s; если ваша сеть рвёт idle TCP меньше чем за 30s — соединение хлопает. Решения: увеличить таймаут простоя в сети (больше 30 секунд) или запустить чекер на хосте, трафик которого не идёт через прокси.

Я отозвал API-ключ, но чекер всё ещё онлайн.

Авторизация WebSocket проверяется только при рукопожатии. Существующие сессии живут до следующего разрыва. Чтобы отключить принудительно: docker compose down на хосте чекера (или дождитесь следующего переподключения — новое рукопожатие будет отклонено).

Снёс старый контейнер чекера и поднял новый — в списке чекеров осталась старая строка offline.

Если новый контейнер запущен с тем же PROBE_NAME — сервер привяжет его к старой строке (дубликатов не будет). Если PROBE_NAME другой — создаётся новая строка, а старая запись offline удаляется сама при следующей регистрации любого вашего приватного чекера, если к ней не привязан ни один монитор. Если на старой строке ещё висят мониторы (значит, вы планировали переезд), сервер оставляет её на месте — переназначьте мониторы на новый чекер в форме монитора, и она уберётся при следующей регистрации. Без вашего участия ежедневная очистка всё равно удалит осиротевшие строки offline в течение 24 часов.

Ограничения

• Корпоративный HTTPS_PROXY пока не поддерживается — нужен прямой исходящий 443 до pingzen.dev.
• PageSpeed нужен GOOGLE_PAGESPEED_API_KEY в окружении чекера; без ключа чекер PageSpeed не предлагает.
• Тестировано на Linux/amd64 и Linux/arm64; macOS через Docker Desktop тоже работает. Windows-контейнеры не поддерживаются.
• Для транзакций в браузере нужен образ -full (Playwright с Chromium).

Частые вопросы

Вы проверяете один монитор со всех чекеров одновременно?

Да. Мониторы с несколькими чекерами запускают одну и ту же проверку параллельно с каждого назначенного чекера. Правило агрегации, которое вы выбираете при создании монитора, решает, как сводятся состояния отдельных чекеров: any_fails (самое строгое — оповещение сразу при первом упавшем чекере), majority_fail (фильтрует региональный шум), all_fail (мягкое — оповещение, только когда упали все чекеры). Карточка на панели показывает строку с цветными точками по чекерам, а инциденты хранят хронологию affected_probes — видно, какие именно регионы упали и восстановились. Лимиты по тарифу: FREE=1, PRO=3, BUSINESS=10, ENTERPRISE=50 чекеров на монитор.

Что происходит с мониторами, если мой чекер ушёл в offline?

Мониторы, привязанные к чекеру в offline, перестают выполняться до его переподключения. На панели виден последний известный статус с пометкой, что чекер офлайн. Остальные чекеры и центральный сервер в Москве работают как обычно.

Можно ли поднимать чекеры в странах, куда сам PingZen не достанет (Иран, Китай)?

Да — это основная причина держать свой чекер. Чекер подключается исходящим соединением изнутри региона, так что вы видите сервис так, как его видят в этом регионе. Важно, чтобы с самой VM был исходящий HTTPS к pingzen.dev (в некоторых жёстких сетях Cloudflare может быть заблокирован — проверьте заранее: curl https://pingzen.dev/api/v1/health с VM).

Трафик чекера зашифрован?

Да — агент подключается к pingzen.dev по WSS (WebSocket поверх TLS). Ключ чекера аутентифицирует подключение и привязан к одному рабочему пространству.

Могут ли несколько пользователей использовать мой чекер?

Чекер привязан к одному рабочему пространству. Его можно сделать публичным — тогда мониторы из других пространств тоже смогут к нему привязываться. Удобно, если хотите отдать мощности сообществу в обмен на расширение лимитов тарифа. Напишите нам, если интересно.

Влияет ли это на лимиты моего тарифа?

Нет. Ваш тариф (Free, Pro, Business, Enterprise) определяет максимальное количество мониторов, которое можно создать в аккаунте — этот лимит не зависит от того, сколько своих чекеров у вас запущено. Свой чекер добавляет точки проверки, но не поднимает вашу квоту мониторов автоматически. Если хотите расширенный лимит в обмен на мощности своего чекера — напишите нам.

Что дальше

В планах: (1) регистрация чекеров прямо из панели — без ручного копирования API-ключа, (2) поддержка корпоративного HTTPS_PROXY, чтобы чекеры работали за корпоративным шлюзом. Есть конкретная задача? Напишите — приоритизируем по запросам.