External Checkers и мониторинг из нескольких локаций

PingZen сейчас держит две собственные probes: Москва (Yandex Cloud, ru-central1; default) и Новосибирск (bare-metal дата-центр). Если вам нужно покрытие из региона, где у нас пока нет своей точки — Турция, Болгария, Нидерланды, Иран, что угодно другое — можно подключить свой external checker: вы предоставляете VM (минимум 2 vCPU / 2 ГБ RAM), мы деплоим на неё наш Docker-агент. Она появится в дашборде как ещё одна точка проверки, доступная для выбора.

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

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

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

Поддерживаемые протоколы на external checkers

PingZen поддерживает 23 протокола всего, но на external checkers сейчас доступно подмножество из 13. Остальные протоколы работают только на центральной московской probe.

Если в вашей смеси есть протоколы из правой колонки — эти мониторы продолжат работать из Москвы; на ваши external checkers можно переназначить только мониторы из левой колонки.

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

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

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

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

Именно этот сценарий и призван выявлять multi-location мониторинг. Каждый монитор работает независимо на своей probe, поэтому региональный сбой (плохой маршрут ISP, блокировка на уровне страны, локальный сбой CDN) ловит только монитор в пострадавшем регионе, а мониторы в других регионах продолжают показывать UP. Пример с Turkey/Bulgaria/Netherlands ниже предполагает, что эти локации у вас развёрнуты как self-hosted external checkers — сам PingZen сейчас держит только Moscow и Novosibirsk.

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

Защита от ложных срабатываний: confirmation-логика

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

Статусы probes

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

Типы probes

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

Как добавить свой external checker

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

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

Справочно: команда, которую мы запускаем на вашей 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 \
  ilyakong/pingzen-checker:0.3.2

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

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

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

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

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

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

Требования

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

Установка

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

services:
  pingzen-checker:
    image: ilyakong/pingzen-checker:0.3.2
    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.

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

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

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

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

1. Запустите: docker compose logs pingzen-checker --tail 20 — ищите “Probe registered: id=N name=<ваш label>”.
2. Откройте pingzen.dev → Monitors → Create. Ваш приватный probe появится в dropdown “Check from” с бейджем Private.
3. Выберите target URL внутри вашей приватной сети (например http://10.0.0.5/health), выберите ваш probe, кликните Test Connection — должны увидеть UP за ~1 секунду.

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

Результаты проверок передаются от probe к PingZen и хранятся в нашей БД. Per-check поля (URL, status, response_time, error_message) видны всем участникам вашего workspace. Alert-нагрузки во внешние каналы (Discord, Slack, webhook, email, MS Teams, Mattermost, PagerDuty) редактируются — ваш PROBE_NAME заменяется на анонимный label “Private probe #N” перед отправкой. Prometheus-метрики используют region label, который для приватных probes сводится к country code (или литералу “private”) — внутренние имена никогда не достигают scrape-клиентов.

Troubleshooting

Probe не появляется в picker после 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 0 приватных probes; PRO=3, BUSINESS=10, ENTERPRISE=50. WebSocket-handshake вернёт код 4001 с reason quota_exceeded — подтверждение.

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

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

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

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

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

WebSocket auth проверяется только на handshake. Существующие сессии живут до следующего разрыва. Чтобы принудительно отключить: docker compose down на probe-хосте (или дождитесь следующего natural reconnect — новый handshake будет отклонён).

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

Если новый контейнер запущен с тем же PROBE_NAME — backend re-attach’ит старую строку (никаких дубликатов). Если PROBE_NAME другой — создаётся новая строка, а старая offline-запись авто-удаляется при следующей регистрации любого вашего приватного probe, при условии что к ней не прикреплён ни один монитор. Если на старой строке ещё висят мониторы (значит вы планировали мигрировать), backend оставляет её на месте — переназначьте мониторы на новый probe в MonitorForm и она авто-уберётся со следующей регистрации. Без участия с вашей стороны daily reaper всё равно зачистит orphan offline-строки в течение 24 часов.

Ограничения

• Корпоративный HTTPS_PROXY пока не поддерживается — нужен прямой исходящий 443 до pingzen.dev.
• Протокол PageSpeed требует Lighthouse и не входит в checker image.
• Тестировано на Linux/amd64 и Linux/arm64; macOS через Docker Desktop тоже работает. Windows-контейнеры не поддерживаются.
• С приватного probe доступны только HTTP-style targets — DNSBL-проверки против IP-репутации должны использовать публичные региональные probes.

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

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

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

Что происходит с мониторами, если моя probe ушла в offline?

Мониторы, привязанные к offline probe, перестают выполняться до её переподключения. На дашборде виден последний известный статус с пометкой «probe offline». Остальные probes и центральная московская — работают как обычно.

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

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

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

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

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

Probe привязан к одному workspace. Её можно пометить как public — тогда мониторы из других workspaces тоже смогут к ней привязываться. Удобно, если хотите отдать capacity сообществу в обмен на расширение лимитов плана. Напишите нам, если интересно.

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

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

Что дальше

В roadmap: (1) self-service регистрация probes прямо с дашборда — без копи-паста API ключа руками, (2) поддержка корпоративного HTTPS_PROXY чтобы probes работали за enterprise-gateway, (3) образ с встроенным Lighthouse для PageSpeed-мониторинга из приватных локаций. Есть конкретный use case? Напишите — приоритизируем по запросам.