Как устроен Prometheus? Расскажите про pull-модель, типы метрик и как строится алертинг.
Короткий ответ
- Pull-модель: Prometheus сам опрашивает /metrics по scrape-интервалу
- Service discovery находит цели в Kubernetes автоматически
- Типы метрик: counter, gauge, histogram, summary
- PromQL: rate() по счётчикам, квантили по гистограммам
- Правила алертинга вычисляются в Prometheus, маршрутизация — в Alertmanager
- Для батч-задач — Pushgateway, для долгого хранения — Thanos или Mimir
Prometheus опрашивает экспортеры по pull-модели, хранит временные ряды с лейблами, а Alertmanager группирует и доставляет алерты.
Как сказать вслух
пример ответаPrometheus работает по pull-модели: он сам по расписанию ходит к приложениям и экспортерам на эндпоинт с метриками, а цели находит через service discovery, например по аннотациям в Kubernetes. Метрики бывают четырёх типов — счётчики, измерители, гистограммы и summary, — и по ним через PromQL считаются скорости и перцентили. Алерты описываются правилами в самом Prometheus, а Alertmanager группирует их, подавляет дубли и рассылает в нужные каналы. Для визуализации обычно рядом стоит Grafana.
Подробный ответ
Основной ответ
Prometheus периодически собирает метрики по HTTP с таргетов, которые находит через service discovery (Kubernetes, Consul, статичные списки), и складывает их в локальную TSDB как временные ряды с лейблами. Pull-модель упрощает контроль (метрика up показывает доступность цели) и защищает от шторма записей; для короткоживущих задач есть Pushgateway. Типы метрик: counter (монотонный, анализируется через rate/increase), gauge (текущее значение), histogram (бакеты, перцентили через histogram_quantile, агрегируемы между инстансами), summary (квантили на клиенте, не агрегируются). Alerting: recording/alerting rules в Prometheus вычисляют выражения с условием for, Alertmanager группирует, маршрутизирует по получателям, подавляет (inhibition, silence). Долгое хранение и горизонтальное масштабирование — Thanos, Mimir или VictoriaMetrics.
Ключевые моменты
- Pull и service discovery. Цели обнаруживаются автоматически, а недоступность цели сама по себе сигнал (up == 0).
- Counter + rate(). Счётчики почти всегда анализируют через rate() по окну — работа с «сырыми» значениями бессмысленна при рестартах.
- Histogram vs summary. Гистограммы агрегируются между репликами и считаются на сервере — для латентности почти всегда выбирают их.
- Разделение ролей. Prometheus вычисляет условия, Alertmanager отвечает за группировку, маршрутизацию и дедупликацию уведомлений.
Практический контекст
Стек Prometheus + Grafana + Alertmanager — отраслевой стандарт, и вопрос встречается почти в каждой вакансии. На практике инженер пишет PromQL-запросы для дашбордов, настраивает алерты на симптомы (латентность, ошибки), а не на причины, и борется с кардинальностью лейблов. Интервьюер часто просит написать запрос вроде «процент пятисотых за пять минут» — стоит держать такие шаблоны в голове.
Частые ошибки
- Путают pull и push модели и не могут объяснить плюсы pull
- Строят алерты и графики по counter без rate()
- Не знают разницы между histogram и summary и когда что агрегируется