Универсальный API для доступа к метрикам инфраструктурного мониторинга

Как превратить Zabbix и Prometheus в data provider с понятным интерфейсом

Статус: В продуктивной эксплуатации

Технологический стек

Python FastAPI PostgreSQL Prometheus Zabbix Redis (кэш) Swagger/OpenAPI

Аудитория и нагрузка

10–50
команд используют
100k+
запросов в неделю

Контекст и проблема

Исходная ситуация

В компании существует развитая система инфраструктурного мониторинга на базе Zabbix и Prometheus-экспортеров. Данные о состоянии серверов, сетей и приложений постоянно собираются и хранятся. Эти данные потенциально ценны для множества внутренних команд:

  • Команды разработки хотят забирать метрики в свои приложения для кастомной логики или алертинга.
  • Аналитики нуждаются в данных для построения отчетов и выявления трендов.
  • Смежные отделы планируют использовать метрики в своих системах для биллинга, SLA-отчетности или собственных дашбордов.

«Боль» пользователей:

До создания сервиса каждая интеграция превращалась в исследовательский проект. Разработчик, желающий получить, например, загрузку CPU конкретного сервера, сталкивался с рядом препятствий:

Неизвестная точка входа: Непонятно, на какой эндпоинт обращаться за данными.
Сложность данных: Нужно разобраться, какие агенты мониторинга установлены на сервере, какие метрики они отдают и в каком формате.
Порог входа в PromQL: Для получения осмысленного значения требовалось писать и отлаживать запросы на языке PromQL, что требует времени и специфических знаний.
Отсутствие каталога: Нет единого места, где можно было бы посмотреть, какие метрики вообще доступны по интересующему узлу.

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

Триггер к созданию:

Назрела очевидная потребность в создании единого интеграционного слоя, который превратил бы инфраструктурный мониторинг из закрытой системы в поставщика данных (data provider) с понятным и стабильным интерфейсом.

Решение: API с точечной нотацией

Был разработан микросервис, предоставляющий унифицированный HTTP API для доступа к метрикам мониторинга. Ключевая идея — абстрагировать потребителей от сложности нижележащих систем (Zabbix, Prometheus, экспортеры) и языка PromQL.

Принцип работы: Точечная нотация

Вдохновляясь подходом Zabbix (где ключи выглядят как system.cpu.util), был введен аналогичный, но расширенный стандарт именования метрик:

source.application.metric_name
  • source — источник данных (zabbix, node_exporter, postgres_exporter)
  • application — слой приложения (cpu, ram, disk, net, database)
  • metric_name — конкретный показатель (util_percent, latency, up, total)
zabbix.cpu.util_percent
утилизация CPU из Zabbix
node_exporter.disk.latency
задержки дисков из node_exporter

Функциональность API

1. Получение списка доступных метрик

Потребитель может запросить все метрики, доступные по конкретному хосту.

{
  "output": "extent",
  "hosts": ["hostname.domain"]
}

Ответ возвращает полный перечень метрик в точечной нотации для данного узла.

2. Получение исторических данных

Запрос метрики за определенный период (временные метки в Unix-time).

{
  "metric": ["node_exporter.cpu.util_percent"],
  "hosts": ["hostname.domain"],
  "time_start": 1672531200,
  "time_end": 1672617600
}

Поддерживается запрос нескольких метрик и нескольких хостов в одном вызове.

3. Получение последнего значения

Если параметры time_start и time_end опущены, API возвращает только последнее актуальное значение по метрике.

4. Фильтрация

Поддерживается дополнительный параметр filter для более тонкой выборки данных (например, по конкретному диску или сетевому интерфейсу).

Управление и стабильность (Маппинг)

Сердце системы — база данных PostgreSQL, хранящая маппинг (словарь соответствий):

Точечная нотация (metric.name) ⇄ PromQL-запрос / Zabbix-ключ
Наполнение: Администраторы мониторинга добавляют и обновляют записи при разработке новых стандартов мониторинга или изменении существующих.
Стабильность контракта: Благодаря этому словарю, потребители всегда обращаются к метрикам по неизменным именам. Если под капотом меняется экспортер или оптимизируется PromQL-запрос, администратор вносит изменение в одном месте, и все существующие интеграции продолжают работать.

Архитектура и техническая реализация

Микросервис выступает в роли прокси-слоя между потребителями и системами мониторинга.

Валидация запросов

Проверка входных данных на корректность

Rate Limiting

Защита от дестабилизации системы

Кэширование

Redis для снижения нагрузки

Безопасность

Защита от "выкачивания всего"

Документация:

Swagger/OpenAPI База знаний в Confluence Примеры запросов и ответов

Результаты и ценность для бизнеса

Резкое ускорение интеграций

Было: недели → Стало: часы

Снижение когнитивной нагрузки

Не нужно быть экспертом мониторинга

Единая точка доступа

Данные из всех сегментов сети через единый эндпоинт

Стабильность и обратная совместимость

Изменения в мониторинге не ломают интеграции

Метрики успеха

10–50
команд активно используют
100k+
запросов в неделю
↓ 90%
обращений к администраторам мониторинга

Этот проект превратил инфраструктурный мониторинг из закрытой технической системы в полноценную платформу данных, доступную для всего остального ИТ-ландшафта компании.

Другие проекты

Self-Service BI — Модуль генерации дашбордов в Grafana
Admin Portal — Консоль самообслуживания