Обзор StatusRadar

StatusRadar — это профессиональная платформа мониторинга доступности (uptime), которая объединяет в одном продукте внешние проверки, метрики уровня сервера, публичные status-страницы и full-stack observability. Вы наблюдаете за своими эндпоинтами с распределённых probe, собираете подробные метрики изнутри серверов с помощью лёгкого агента, публикуете брендированную status-страницу для своих пользователей и направляете оповещения в каналы, которыми ваша команда уже пользуется.

На этой странице описано, что делает StatusRadar и с какими ключевыми концепциями вам предстоит работать. Если вы предпочитаете сразу приступить к делу, переходите к разделу Быстрый старт.

Что вам даёт StatusRadar

• Мониторинг доступности (uptime) — Проверяйте HTTP/HTTPS-эндпоинты, SSL-сертификаты, TCP-порты, ping, DNS-записи и серверы с распределённых probe, с настраиваемыми интервалами, тайм-аутами и повторными попытками.
• Мониторинг серверов (агент) — Небольшой агент на Python работает на ваших Linux-серверах и сообщает метрики CPU, памяти, диска, сети и отдельных сервисов через 16 опциональных плагинов (базы данных, веб-серверы, кэши, очереди и многое другое).
• Status-страницы — Публичные или приватные страницы, которые показывают текущее состояние и историческую доступность выбранных вами мониторов, с вашими собственными цветами и версткой.
• Инциденты и обслуживание — Отслеживайте сбои от момента обнаружения до устранения, публикуйте обновления и планируйте окна технического обслуживания, которые отображаются на вашей status-странице.
• Оповещения — Узнавайте о любой поломке в момент её возникновения благодаря пороговым и ML-оповещениям об аномалиях, которые доставляются на email, в Slack, Telegram, Discord, через webhooks и не только.
• Observability (OTLP + RUM) — Принимайте backend-трейсы, логи и метрики по OTLP, а также собирайте фронтенд Real User Monitoring (Core Web Vitals, ошибки, session replay) из браузера.

Ключевые концепции

Мониторы

Монитор — это один объект, за которым вы хотите следить: URL, порт, сертификат, DNS-запись или сервер. У каждого монитора есть name, target и поля тайминга (interval_seconds, timeout_seconds, retry_count), а также опции, зависящие от типа. Поддерживаются следующие типы:

Мониторы выполняются с одного или нескольких probe-серверов, чтобы вы могли убедиться, что сбой глобальный, а не локальный для одного региона.

Серверный агент

Агент — это демон, который вы устанавливаете на Linux-сервер для сбора метрик изнутри машины: системные ресурсы плюс опциональные сервисные плагины (Redis, MySQL, PostgreSQL, MongoDB, Nginx, Apache, PHP-FPM, Memcached, RabbitMQ, Elasticsearch, Meilisearch, Varnish, HAProxy, Docker, VictoriaMetrics и mdadm). Он работает в паре с монитором типа Server и обеспечивает данные для серверных дашбордов.

Status-страницы

Status-страница — это публичная (или приватная) страница по адресу /status/{slug}, которая отображает назначенные ей мониторы, их текущий статус и историческую доступность. Вы управляете slug, видимостью, темой (основной цвет и верстка) и тем, сколько истории показывать (show_history_days — 30, 60, 90, 180 или 365).

Инциденты и окна обслуживания

Инциденты представляют собой сбои или деградации — создаются вручную или автоматически системой обнаружения аномалий. У них есть уровень серьёзности, затронутая сущность (монитор или сервер), жизненный цикл «подтвердить → устранить» и обновления с метками времени. Окна обслуживания позволяют планировать плановые работы, чтобы они отображались на вашей status-странице и подавляли шум.

Оповещения

Оповещения превращают условия по мониторам и метрикам в уведомления. Они поддерживают пороги сбоя/восстановления, предупреждения об истечении срока SSL, всплески времени отклика, ML-обнаружение аномалий и предупреждения о квотах, доставляемые через несколько каналов с группировкой и троттлингом для снижения шума.

Команды

Команда — это субаккаунт компании, который объединяет ресурсы и людей. Роли: owner (биллинг, команда, передача, удаление), admin (управление участниками), member (управление ресурсами) и viewer (только чтение). Участники присоединяются по приглашению на email, а количество мест привязано к вашему тарифу.

Observability-приложения (OTLP + RUM)

Observability-приложение представляет одно из ваших приложений и хранит его квоты телеметрии и токены. Приложения OTLP принимают backend-трейсы, логи и метрики; приложения RUM принимают браузерную телеметрию (Core Web Vitals, ошибки JavaScript, session replay, клики, сеть). У каждого приложения есть собственный токен, а для RUM — белый список доменов для CORS.

Биллинг

Тарифы определяют квоты на мониторы, status-страницы, места в команде, серверы, срок хранения данных, локации probe и объём observability (RUM/OTLP). Биллинг работает на Stripe с автопродлением, и вы можете покупать top-up кредиты, чтобы покрыть превышение по observability без смены тарифа.

Как всё устроено вместе

                         ┌──────────────────────┐
   Distributed probes ──▶│                      │──▶ Alerts (email, Slack, …)
   Server agent       ──▶│      StatusRadar     │──▶ Status page (/status/{slug})
   Browser RUM SDK    ──▶│                      │──▶ Dashboards & incidents
   Backend OTLP SDK   ──▶│                      │
                         └──────────────────────┘

Probe проверяют ваши мониторы снаружи, агент отчитывается изнутри, а SDK для RUM и OTLP передают телеметрию приложений. StatusRadar коррелирует всё это в дашборды, инциденты, оповещения и вашу публичную status-страницу.

Аутентификация вкратце

StatusRadar использует разные схемы аутентификации для разных интерфейсов — не считайте, что везде применяется Bearer-токен:

Подробности см. в разделе Аутентификация API.

Дальнейшие шаги

• Быстрый старт — настройте свой первый монитор, агента, status-страницу и оповещение
• Обзор мониторов — типы мониторов, поля и probe
• Установка агента — установка серверного агента
• Настройка status-страниц — публикация status-страницы
• Обзор оповещений — типы оповещений, каналы и пороги
• Обзор API — полный программный интерфейс