Перейти к основному содержимому

Архитектура Flaree

Flaree — SaaS-мониторинг с агентом на вашей стороне. Agent живёт на хосте клиента, выполняет проверки и отправляет телеметрию в бэкенд только исходящими HTTPS-запросами. Бэкенд оценивает правила, открывает инциденты, шлёт уведомления и обновляет статус-страницы. Эта страница даёт общую картину, чтобы вы понимали, где рождаются данные и где принимаются решения.

Компоненты​

  • Flaree Agent — один статический бинарник на хосте клиента. Выполняет проверки (HTTP, TCP, базы данных, heartbeat), читает логи и метрики из настроенных источников, принимает OTLP от приложений на той же машине. Детали — в концепции агента.
  • Ingestion — приёмный слой бэкенда. Проверяет токен агента, применяет квоты и ставит данные в очередь на обработку. Ничего не решает про инциденты.
  • Rules engine — оценивает поток логов и метрик по правилам LogRule и MetricRule и меняет статусы компонентов.
  • Инциденты и уведомления — при срабатывании правила или падении проверки открывается инцидент, а подписчики получают уведомления в Telegram, Email или Webhook.
  • Статус-страницы — публичное отражение статусов компонентов для ваших пользователей.

Поток данных​

Направление соединений​

Агент никогда не принимает входящие соединения из сети — весь обмен инициирует он сам по HTTPS:443. Конфигурация проверок раздаётся с бэкенда: агент периодически опрашивает сервер и получает декларативный список заданий. Открывать порты на хосте или настраивать входящие правила firewall не нужно.

Единственные слушающие сокеты агента привязаны к 127.0.0.1 и доступны только с самого хоста: Prometheus-метрики, локальный heartbeat-приёмник и опциональный OTLP-receiver. Подробнее — в egress-only модели.

От данных к инциденту​

  1. Агент выполняет проверку или получает батч логов и метрик.
  2. Батч уходит в ingestion; при превышении квоты агент получает 429 и повторяет позже — данные ждут в буфере (см. квоты и retention).
  3. Rules engine сверяет данные с правилами. Flap-guard и cooldown отсекают шум.
  4. Сработавшее правило меняет статус компонента и открывает инцидент.
  5. Уведомления уходят в настроенные каналы, статус-страница обновляется.

Дальше​