Monitoring

Мониторинг — это механизм наблюдения за состоянием сервисов, инфраструктуры и внешних зависимостей. С помощью мониторов можно автоматически проверять доступность ресурсов, получать уведомления о сбоях и использовать события мониторинга для автоматизаций и реагирования.

Мониторы создаются в рамках проекта и могут привязываться к конкретному окружению (environment).

---

Как создать монитор

Шаг 1. Перейдите в раздел мониторинга

• В левом меню выберите нужный проект;
• Перейдите на вкладку «Мониторинг»;
• Нажмите кнопку «Создать монитор» в правом верхнем углу.

Шаг 2. Выберите тип монитора

В открывшейся форме выберите тип монитора из выпадающего списка:

• HTTP — для проверки доступности веб-сервисов и API;
• DNS — для контроля DNS-резолвинга;
• TCP — для проверки сетевой доступности портов;
• HEARTBEAT — для контроля периодических задач и воркеров.

Шаг 3. Настройте параметры монитора

Общие параметры (для всех типов)

Название монитора

• Краткое описательное название (например, "API Production", "Database Connection");
• Помогает быстро идентифицировать монитор в списке.

Окружение (опционально)

• Привязка к конкретному environment (Development, Staging, Production);
• Позволяет группировать мониторы по окружениям.

Включен

• Переключатель активации монитора;
• Выключенный монитор не выполняет проверки и не создаёт инциденты.

Параметры HTTP-монитора

Адрес ресурса

• Полный URL для проверки (например, https://example.com/health);
• Поддерживаются HTTP и HTTPS протоколы.

Метод

• HTTP-метод запроса: GET, POST, PUT, DELETE, PATCH;
• По умолчанию: GET.

Заголовки запроса (опционально)

• Дополнительные HTTP-заголовки;
• Полезно для передачи токенов авторизации или custom headers;
• Нажмите «+ Добавить» для добавления заголовка.

Статус (мин/макс)

• Диапазон ожидаемых HTTP-статусов;
• Минимум: 200, Максимум: 299 (по умолчанию);
• Статусы вне диапазона считаются ошибкой.

Таймаут (мс)

• Максимальное время ожидания ответа в миллисекундах;
• По умолчанию: 5000 мс (5 секунд);
• При превышении таймаута считается ошибкой.

Интервал (сек)

• Периодичность проверок в секундах;
• По умолчанию: 60 секунд;
• Минимальное значение зависит от тарифного плана.

Grace-период (сек)

• Период отсрочки перед началом проверок после создания;
• По умолчанию: 0 секунд;
• Полезно для разворачиваемых сервисов.

Регионы

• Выбор географических регионов для проверки;
• Позволяет тестировать доступность из разных точек;
• Отметьте нужные регионы (например, msk-01, fra-01).

Параметры DNS-монитора

Hostname

• Доменное имя для проверки (например, api.example.com);
• Без указания протокола.

Тип записи

• Тип DNS-записи: A, AAAA, CNAME, MX, TXT;
• По умолчанию: A.

Ожидаемое значение (опционально)

• Конкретный IP или значение записи для проверки;
• Если не указано, проверяется только наличие записи.

Параметры TCP-монитора

Хост

• IP-адрес или доменное имя сервера;
• Например: db.internal или 10.0.1.50.

Порт

• Номер TCP-порта для проверки;
• Например: 5432 (PostgreSQL), 3306 (MySQL), 6379 (Redis).

Таймаут (мс)

• Максимальное время установки соединения;
• По умолчанию: 3000 мс.

Параметры HEARTBEAT-монитора

Grace-период (сек)

• Максимальное время ожидания heartbeat-сигнала;
• После превышения монитор считается DOWN;
• Должен быть больше периода выполнения задачи.

URL для heartbeat

• Уникальный URL для отправки heartbeat-сигналов;
• Генерируется автоматически после создания монитора;
• Ваш сервис должен периодически вызывать этот URL.

Шаг 4. Создайте монитор

• Проверьте все настройки;
• Нажмите кнопку «Создать»;
• Монитор появится в списке и начнёт выполнять проверки.

Результат

После создания:

• Монитор отображается в списке мониторов проекта;
• Начинаются регулярные проверки согласно настроенному интервалу;
• История проверок визуализируется в виде индикаторов статуса;
• При сбоях автоматически создаются инциденты (после превышения порога в 3 минуты).

---

Для чего используется мониторинг

1. Контроль доступности сервисов

Мониторы позволяют регулярно проверять:

• доступен ли сервис;
• отвечает ли он в ожидаемое время;
• корректно ли работает сетевое взаимодействие.

Это особенно важно для:

• production-сервисов;
• критичных внешних API;
• внутренних микросервисов.

2. Раннее обнаружение инцидентов

При нарушении условий мониторинга платформа:

• фиксирует инцидент;
• меняет статус монитора;
• отправляет уведомления;
• может запускать автоматизации и сценарии реагирования.

Типы мониторов

В платформе доступны следующие типы мониторов:

• HTTP
• DNS
• TCP
• HEARTBEAT

Каждый тип предназначен для своего сценария использования.

HTTP Monitor

HTTP-монитор используется для проверки доступности HTTP/HTTPS-эндпоинтов.

Что проверяет:

• доступность URL;
• HTTP-статус ответа;
• время ответа;
• (опционально) тело ответа или заголовки.

Пример использования:

• /health или /status эндпоинты;
• REST API;
• публичные сайты;
• internal-сервисы.

Пример конфигурации:

• URL: https://api.example.com/health
• Метод: GET
• Ожидаемый статус: 200
• Таймаут: 3s
• Интервал проверки: 30s

Рекомендации:

• Используйте специальные health-check эндпоинты;
• Не проверяйте тяжёлые бизнес-методы;
• Настраивайте таймауты меньше, чем клиентские.

DNS Monitor

DNS-монитор проверяет корректность DNS-резолвинга.

Что проверяет:

• наличие DNS-записи;
• корректность ответа (A, AAAA, CNAME и др.);
• доступность DNS-сервера.

Пример использования:

• проверка доменов и поддоменов;
• контроль DNS после миграций;
• мониторинг внешних провайдеров.

Пример конфигурации:

• Hostname: api.example.com
• Тип записи: A
• Ожидается: наличие записи

Рекомендации:

• Используйте перед релизами и миграциями;
• Комбинируйте с HTTP-мониторами;
• Следите за TTL и кэшем DNS.

TCP Monitor

TCP-монитор проверяет возможность установить TCP-соединение с хостом и портом.

Что проверяет:

• доступность хоста;
• открыт ли порт;
• базовую сетевую связность.

Пример использования:

• базы данных (PostgreSQL, MySQL);
• брокеры сообщений (Kafka, RabbitMQ);
• internal-сервисы без HTTP.

Пример конфигурации:

• Host: db.internal
• Port: 5432
• Таймаут: 2s
• Интервал: 60s

Рекомендации:

• Используйте для инфраструктурных сервисов;
• Не заменяет полноценный health-check;
• Хорошо подходит для раннего обнаружения сетевых проблем.

HEARTBEAT Monitor

Heartbeat-монитор используется для проверки того, что сервис сам регулярно сигнализирует о своей работоспособности.

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

• сервис периодически отправляет heartbeat-сигнал;
• если сигнал не получен в заданный интервал — монитор считается DOWN.

Пример использования:

• cron-задачи;
• фоновые воркеры;
• batch-процессы;
• scheduled jobs.

Пример сценария:

• Job должен выполняться каждые 5 минут;
• Heartbeat ожидается раз в 5 минут;
• Таймаут: 10 минут.

Если heartbeat не пришёл — фиксируется инцидент.

Рекомендации:

• Используйте для асинхронных процессов;
• Делайте heartbeat в конце успешного выполнения;
• Логируйте отправку heartbeat для отладки.

Лучшие практики

Комбинируйте типы мониторов:

• HTTP + DNS для публичных API;
• TCP + HEARTBEAT для внутренних сервисов;
• HTTP + HEARTBEAT для background workers.

Используйте разные интервалы:

• Критичные сервисы — чаще;
• Фоновые задачи — реже;
• Избегайте излишней нагрузки.

Привязывайте мониторы к окружениям:

• Production ≠ Staging;
• Разные SLA и политики;
• Разные правила уведомлений.

Используйте мониторинг вместе с Feature Flags:

• Автоматически отключайте фичи при падении сервиса;
• Включайте fallback-механику;
• Минимизируйте влияние инцидентов на пользователей.

---

Дополнительные материалы

Мониторинг тесно интегрирован с другими возможностями платформы:

• Incidents — управление инцидентами, создаваемыми мониторами
• Workflows — автоматизация реагирования на события мониторинга (в разработке)
• Feature Flags — управление функциональностью при сбоях в мониторах