Prometheus

Prometheus — это система мониторинга и алертинга, ориентированная на метрики и временные ряды (time-series database).
Изначально разработан в SoundCloud, сейчас — один из ключевых проектов CNCF (Cloud Native Computing Foundation), наряду с Kubernetes.

Ключевая идея Prometheus:

• он сам опрашивает сервисы (pull-модель),
• собирает числовые метрики во времени,
• хранит их локально,
• позволяет строить запросы и алерты на основе PromQL.

Важно сразу обозначить:

Prometheus — это не система логирования и не APM в классическом понимании.

Он отвечает на вопрос:
«Что происходит с системой прямо сейчас и как это менялось во времени?»

Область применения

Prometheus используется там, где есть:

• распределённые системы
• микросервисы
• контейнеры
• динамическая инфраструктура

Типичные сценарии:

Инфраструктура

• CPU, RAM, диск, I/O
• состояние серверов и VM
• мониторинг hypervisor’ов (Proxmox, VMware через exporters)

Контейнеры и Kubernetes

• стандарт де-факто для Kubernetes
• мониторинг:
  • pod’ов
  • node’ов
  • control plane
  • ingress’ов
• автоскейлинг (HPA) через метрики

Приложения

• кастомные метрики (RPS, latency, errors)
• состояние очередей
• бизнес-метрики (заказы, платежи, сессии)

Сетевые сервисы

• Nginx / HAProxy
• базы данных (MySQL, PostgreSQL, Redis)
• DNS, VPN, firewall’ы

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

Упрощённо:

[ Exporters / Applications ]
              ↓ (HTTP /metrics)
         [ Prometheus Server ]
              ↓
     [ TSDB (локальное хранилище) ]
              ↓
        [ Alertmanager ]
              ↓
       Email / Slack / Telegram

Основные компоненты

• Prometheus Server
  • сбор метрик
  • хранение
  • выполнение запросов
• Exporters
  • node_exporter
  • mysql_exporter
  • nginx_exporter
  • сотни готовых
• Alertmanager
  • дедупликация алертов
  • группировка
  • маршрутизация
• Grafana (часто, но не обязательно)
  • визуализация

Преимущества Prometheus над аналогами

1. Простота и прозрачность

• один бинарник
• текстовая конфигурация
• HTTP-интерфейсы
• всё читаемо и дебажимо

2. Pull-модель

В отличие от Zabbix / Influx push-подходов:

• легче масштабировать
• проще дебажить
• сервисы не «ломаются», если мониторинг временно недоступен

3. PromQL — мощный язык запросов

Позволяет:

• агрегировать
• строить производные
• делать сложные алерты

Пример:

rate(http_requests_total{status=~"5.."}[5m]) > 1

4. Cloud-native подход

• идеально ложится на Kubernetes
• service discovery из коробки
• не требует ручного добавления хостов

5. Огромная экосистема

• exporters почти под всё
• готовые дашборды
• активное сообщество

Преимущества для малого бизнеса

Для небольших компаний Prometheus — очень сильный вариант, если:

Плюсы

• полностью open-source
• ноль лицензий
• можно развернуть на одном сервере
• минимальные требования
• быстрое внедрение

Один Prometheus + Grafana:

• заменяет Zabbix в большинстве кейсов
• даёт понятные графики
• позволяет ловить проблемы до падения

Минусы

• требует базовых DevOps-навыков
• нет «кнопочного» UI как у Zabbix
• нужно думать про retention и бэкапы

Преимущества для крупного бизнеса

В enterprise-среде Prometheus используют почти все, но:

Как правило:

• не один Prometheus
• не локальное хранилище
• обязательный federation или remote storage

Плюсы

• горизонтальное масштабирование
• гибкость архитектуры
• отсутствие vendor lock-in
• интеграция с CI/CD и GitOps

Минусы

• из коробки не HA
• сложность архитектуры
• требуется команда, а не «админ на полставки»

Хранение истории (retention)

По умолчанию

Prometheus хранит данные:

• в локальной TSDB
• на диске
• с retention по времени или размеру

Пример:

--storage.tsdb.retention.time=30d

Реальность

• 15–30 дней — норм для локального Prometheus
• дальше начинаются проблемы с диском и производительностью

Хранение логов — важный момент

И вот здесь частая ошибка 👇

Prometheus НЕ хранит логи

Он хранит только метрики:

• числа
• счётчики
• гистограммы

Что делать с логами?

Используют связку:

• Loki — логи
• Prometheus — метрики
• Grafana — единый интерфейс

И это честный, правильный подход.

Долгосрочное хранение метрик

Для архива и аналитики используют:

Remote storage

• Thanos
• Cortex
• VictoriaMetrics
• Mimir

Они дают:

• месяцы и годы хранения
• репликацию
• HA
• S3 / Object Storage

В enterprise это обязательная часть архитектуры.

Устойчивость к нагрузкам

Один Prometheus

• выдерживает десятки тысяч метрик
• сотни тысяч sample/sec — реальность
• ограничение — CPU, RAM и диск

Масштабирование

Prometheus не масштабируется горизонтально сам.

Решения:

• federation
• sharding
• remote write
• внешние TSDB

Правда жизни

• для small/medium — отлично
• для large — нужна архитектура

Автоматизация через Ansible

Да, и очень хорошо автоматизируется.

Что обычно автоматизируют:

• установку Prometheus
• exporters
• генерацию prometheus.yml
• Alertmanager
• systemd-сервисы

Пример подхода:

• роли:
  • prometheus
  • node_exporter
  • alertmanager
• inventory → targets
• templates → конфиги

Prometheus отлично дружит с:

• Ansible
• Terraform
• Helm (в Kubernetes)

Prometheus vs Zabbix / Influx / Datadog

Zabbix

• ✔ проще для классической инфраструктуры
• ✖ хуже для динамики и Kubernetes
• ✖ тяжелее масштабируется

InfluxDB

• ✔ хорош как TSDB
• ✖ мониторинг — вторичен
• ✖ менее развитая экосистема

Datadog

• ✔ SaaS, красиво
• ✖ дорого
• ✖ vendor lock-in

Prometheus:

• ✔ гибкость
• ✔ open-source
• ✖ требует инженерного подхода

Итог: честный вывод

Prometheus — это:

✔ лучший open-source стандарт для мониторинга метрик
✔ идеален для Kubernetes и микросервисов
✔ подходит и малому, и крупному бизнесу
✖ не система логирования
✖ не «включил и забыл» без понимания архитектуры

Если нужен:

• контроль над системой
• гибкость
• масштабирование
• отсутствие лицензий

👉 Prometheus — правильный выбор