Docker
Агент собирает метрики контейнеров (CPU, память, статус) через Docker Engine API и стримит логи выбранных контейнеров. Всё общение с демоном идёт через локальный Unix-сокет только на чтение: агент выполняет GET /containers/json, GET /containers//stats и GET /containers/{id}/logs — и ничего не пишет.
Kubernetes
Агент, установленный в кластере через Helm, собирает базовую сводку состояния Kubernetes: счётчики и готовность подов, узлов, deployments и PVC. Он читает Kubernetes API через in-cluster service account с read-only правами и не требует ни привилегированных подов, ни доступа к kubelet. Шаги установки — на странице установки в Kubernetes; здесь — что именно мониторится.
Метрики хоста
Агент собирает базовые метрики хоста, на котором он запущен источник входит в агента.
Journald
Агент собирает журналы systemd через journalctl --follow и отправляет их во Flaree по общему пайплайну логов. Источник настраивается в дашборде — можно читать журнал целиком или логи одного unit-а.
HAProxy
Агент снимает метрики HAProxy со стандартного CSV-эндпоинта статистики: статус бэкендов, текущие сессии и трафик по каждой паре proxy/server. Логи HAProxy можно собирать файловым источником, но специализированного парсера для его формата нет — используйте JSON-лог на стороне HAProxy или plaintext.
OTLP
Flaree принимает метрики и логи по OTLP/JSON двумя путями: через loopback-приёмник агента на том же хосте или напрямую в публичный ingestion-шлюз. Traces принимаются в обоих режимах, но отбрасываются — Flaree их не хранит. Концепция обоих режимов — в OTLP-концепции.
Сбор логов
Агент собирает логи из трёх типов источников — файлы, Docker-контейнеры и journald — и прогоняет каждую строку через единый пайплайн: парсер → фильтры → маскирование → сэмплирование → отправка. Источники и правила обработки настраиваются в дашборде; агент подтягивает изменения при синхронизации конфига каждые 30 секунд.
Привязка метрик к компоненту
Привязка (binding) связывает имя метрики и набор лейблов с конкретным Component. Без привязки метрика принимается, расходует квоту и доступна в поиске, но не отображается на карточке компонента и не годится для MetricRule. Привязки настраиваются в дашборде, на вкладке метрик компонента — конфиг агента править не нужно.
Проверка PostgreSQL
Проверка PostgreSQL создаётся в дашборде и выполняется агентом рядом с базой. Строка подключения хранится только локально в agent.yaml на вашем хосте и на сервер Flaree не отправляется. В задании проверки указывается лишь connectionRef — имя строки из секции connections:.
Проверка MySQL
Проверка MySQL (включая MariaDB и Percona) создаётся в дашборде, а выполняет её агент рядом с базой. Строка подключения живёт только локально в agent.yaml и на сервер Flaree не отправляется — в задании указывается лишь connectionRef.
Проверка MongoDB
Проверка MongoDB создаётся в дашборде, выполняет её агент на вашем хосте. URI подключения хранится только локально в agent.yaml — в задании указывается лишь connectionRef. Чекер выполняет команду ping к базе admin.
Проверка Redis
Проверка Redis создаётся в дашборде, выполняет её агент на вашем хосте. Строка подключения хранится только локально в agent.yaml — в задании указывается лишь connectionRef. Чекер делает PING и снимает INFO memory.
Проверка RabbitMQ
Проверка RabbitMQ создаётся в дашборде, выполняет её агент на вашем хосте. Чекер вызывает aliveness-test HTTP-API плагина rabbitmq_management. Пароль не хранится на сервереимя}}, который агент подставляет локально из секции secrets: в agent.yaml.
Проверка Kafka
Проверка Kafka создаётся в дашборде, выполняет её агент на вашем хосте. Чекер лёгкий: он делает TCP-connect к каждому bootstrap-брокеру и падает, только если недоступны все. Consumer-lag и метрики брокеров этот чекер не собирает.
Nginx
Агент собирает access-логи Nginx через файловый источник со встроенным парсером формата combined — каждая запись раскладывается на статус, адрес клиента, запрос и user-agent, а уровень выставляется по коду ответа (5xx → ERROR, 4xx → WARN). Дополнительно агент умеет снимать метрики stub_status.