Как устроена архитектура взаимодействия между бэкендом и агентами мониторинга

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

Умеете ли вы спроектировать канал, по которому тысячи агентов шлют данные, и продумать его отказы. Следом обычно спрашивают: что будет, если бэкенд лёг на десять минут, и как при этом не потерять метрики.

Как отвечать

Начните с модели доставки:

• pull: сервер сам опрашивает цели. Так работает Prometheus: Spring Boot через Micrometer и Actuator отдаёт /actuator/prometheus, сервер скрейпит его по расписанию. Нагрузку контролирует сервер, а недоступная цель сразу видна по up == 0;
• push: агент шлёт данные сам. Так устроены OpenTelemetry (протокол OTLP поверх gRPC или HTTP), активный режим Zabbix-агента, лог-шипперы. Подходит для короткоживущих задач и агентов за NAT.

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

На приёме stateless-сервис за балансировщиком: проверяет авторизацию и формат, кладёт пачку в Kafka и сразу отвечает. Консьюмеры пишут в TSDB (Prometheus, VictoriaMetrics) или в ClickHouse для логов, отдельный компонент считает алерты.

Безопасность: mTLS или отдельный токен на агента, чтобы отозвать один без перевыпуска остальных. Формат: Protobuf с версионированием схемы, потому что агенты обновляются не одновременно и бэкенд обязан понимать несколько версий сразу.

Где спотыкаются

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

Лечат сетевые задержки кэшированием. Для телеметрии это мимо: работают буфер на агенте, батчинг, повторы с backoff и идемпотентные ключи пачек, чтобы повтор не создал дубль.

Забывают про кардинальность. Метка с userId или URL с идентификатором плодит миллионы временных рядов и кладёт TSDB быстрее любой сетевой проблемы.