# Вопросы: мониторинг (Prometheus / Grafana / Mimir)

Опираются на кейс: [CASE.md](CASE.md).

### Чем Prometheus отличается от Zabbix/Nagios?

Prometheus тянет метрики сам (pull-модель) с эндпоинта `/metrics` у сервиса, хранит их как временные ряды с лейблами и даёт мощный язык запросов PromQL. Классические Zabbix/Nagios исторически больше про push-агентов и чек-скрипты с бинарным статусом «ок/не ок». Я поднимал у себя стенд с node-exporter — Prometheus сам ходит и забирает метрики по расписанию (`scrape_interval`), это и есть pull.

### Что такое target, job, label в Prometheus?

Target — конкретный адрес, откуда собираются метрики (например, `node-exporter:9100`). Job — логическая группа таргетов одного типа (в моём конфиге — job `node`). Label — пара ключ-значение, которая добавляется к метрике и позволяет фильтровать/группировать в PromQL (`instance`, `job`, и кастомные).

### Зачем нужен remote_write и чем Mimir отличается от обычного Prometheus?

Prometheus по умолчанию хранит данные локально и недолго (по умолчанию TSDB держит порядка 15 дней). Если нужно долгосрочное хранение и горизонтальное масштабирование под много Prometheus-инстансов, метрики отправляют через `remote_write` во внешнее хранилище — у меня это Mimir. Mimir совместим с PromQL, поэтому Grafana обращается к нему так же, как к обычному Prometheus-источнику, но данные хранятся отдельно и масштабируемо (у меня — на файловой системе, в проде обычно объектное хранилище типа S3).

### Как устроен путь метрики от хоста до дашборда?

node-exporter отдаёт метрики на `/metrics` → Prometheus по scrape_interval их забирает → одновременно пушит их через remote_write в Mimir → Grafana ходит в Mimir как в datasource и рисует панели через PromQL-запросы.

### Что делать, если target в Prometheus в статусе DOWN?

Проверить: доступен ли хост/порт сетевым способом (в моём случае — контейнер node-exporter упал или сеть Docker недоступна), отдаёт ли эндпоинт `/metrics` корректный ответ, не изменился ли путь/порт в конфиге scrape_config. Я специально гасил node-exporter в стенде и смотрел, как это отражается в Prometheus targets и на дашборде (пропуски данных).

### Как написать alert rule и куда он «стреляет»?

Alert rule — это условие на PromQL-выражение с длительностью (например, «CPU idle < 20% в течение 5 минут» → алерт). В Grafana я настраивал такое правило на дашборде; в проде алерты обычно уходят дальше в Alertmanager/мессенджеры — этого в лабе я не поднимал, но принцип понятен: правило проверяется на интервале evaluation_interval, и если условие держится дольше `for`, алерт переходит из pending в firing.

### Чем отличается rate() от irate() в PromQL?

Обе функции считают скорость роста counter-метрики, но `rate()` усредняет по всему интервалу окна (более гладкий график, подходит для алертов и дашбордов), а `irate()` считает по двум последним точкам (более «дёрганый», подходит для быстрого реагирования на всплески). В своих запросах CPU я использовал `rate()`, потому что нужен был сглаженный тренд, а не мгновенный всплеск.

### Зачем нужна унификация форматов метрик, если данные идут из разных источников?

Если разные экспортеры называют одну и ту же сущность по-разному (разные названия лейблов, разные единицы измерения), дашборды и алерты становится сложно переиспользовать и сравнивать между сервисами. Унификация — это соглашение об именовании метрик и лейблов, чтобы один и тот же дашборд можно было применить к разным сервисам без переделки запросов.

### Как организовать доступ к дашбордам для команды?

В Grafana это роли и права на уровне организации/папок дашбордов плюс подключение аутентификации (LDAP/OAuth/встроенные пользователи). Права разграничиваются так, чтобы просмотр был у всех, а редактирование — у ограниченного круга, чтобы не ломали чужие дашборды.

### В чём разница между метриками и логами и почему нужны оба?

Метрики — агрегированные числовые ряды во времени (быстро смотреть тренды, ставить алерты по порогам). Логи — детальные текстовые события конкретного момента (нужны, чтобы понять, что именно произошло внутри инцидента). Метрика в Grafana покажет, что вырос p99 задержки, но причину чаще всего покажут логи — поэтому мониторинг обычно закрывается связкой метрики (Prometheus/Mimir) + логи (ELK, см. [../elk/](../elk/)).

### Как задеплоил бы мониторинг архитектурно для очень большого парка серверов (например, 300 000)?

Grafana + Prometheus + Mimir + объектное хранилище (MinIO/S3) под блоки Mimir. Один Prometheus не рассчитан на такой масштаб (публичный ориентир — до ~1–2 млн активных series на инстанс, см. [../../legend/CAPACITY.md](../../legend/CAPACITY.md)), поэтому схема — множество Prometheus-инстансов, шардированных по группам серверов/сервисов (например, по датацентру или по команде), каждый scrape'ит свою часть парка и отправляет данные через `remote_write` в Mimir. Mimir горизонтально масштабируется (ingester/distributor/querier как отдельные компоненты) и хранит блоки в объектном хранилище — это снимает ограничение на объём долгосрочного хранения метрик с одного диска. Grafana обращается к Mimir как к единому PromQL-совместимому источнику, не зная о шардировании снизу. У себя в лабе я воспроизвёл этот же принцип в миниатюре — Prometheus → remote_write → Mimir → Grafana (см. [CASE.md](CASE.md)), просто с одним источником вместо тысяч, и в кластере — [../kubernetes/CASE.md](../kubernetes/CASE.md), где тот же стек развёрнут Helm-чартом `kube-prometheus-stack`.

### У тебя есть 300 000 метрик от кастомных агентов в формате JSON — как будешь их собирать?

Раз агенты сами по себе пушат данные и их формат (JSON) нельзя поменять, два реалистичных варианта: (1) pull-модель — написать текстовый файл-адаптер для `node_exporter` через его textfile collector: отдельный процесс парсит входящие JSON (`jq` или скрипт на Python) и периодически перезаписывает `.prom`-файл в формате метрик Prometheus, который `node_exporter` дальше просто отдаёт по scrape; (2) push-модель — если агенты сами инициируют отправку, а не ждут scrape, использовать Pushgateway: агент (или обвязка вокруг него) конвертирует JSON в формат Prometheus и пушит через HTTP API Pushgateway, откуда данные уже забирает Prometheus обычным scrape. Выбор между вариантами зависит от того, кто инициирует передачу — если агенты только отдают данные по запросу, то pull через textfile collector; если сами шлют данные без внешнего опроса — Pushgateway.

### К тебе пришёл разработчик с жалобой на HTTP 400/500 — как будешь мониторить и почему?

Начал бы с метрик — они быстрее покажут масштаб и динамику проблемы: в Grafana смотрю долю 4xx/5xx от общего числа запросов во времени (`rate` по статус-коду, если это есть в лейблах метрики — например, у nginx через `nginx-prometheus-exporter` или у самого приложения) — это отвечает на вопросы «когда началось», «это массово или единичный случай», «на каком именно сервисе». Дальше для выяснения точной причины конкретных ошибок — логи (ELK): по временному окну, где метрики показали всплеск, ищу в логах конкретные запросы с этим статус-кодом и смотрю стектрейс/сообщение об ошибке. То есть метрики — для обнаружения и оценки масштаба, логи — для диагностики конкретной причины; в стенде [../nginx/CASE.md](../nginx/CASE.md) я специально проверял, как выглядит 503 от `limit_req` в логах nginx и как это же отразилось бы на метрике доли ошибочных ответов.

### Работал с Zabbix? Чем он отличается от Prometheus и что такое зонтичный мониторинг?

Практического опыта с Zabbix у меня нет, но принцип понимаю: Zabbix — классическая push/агентская модель мониторинга с центральным сервером, который получает данные от агентов на хостах (или сам их опрашивает по SNMP/скриптам), и с готовым UI из коробки, включая triggers/actions для алертинга — исторически более «всё в одном», чем связка Prometheus+Grafana, которая собирается из отдельных модульных компонентов. Зонтичный мониторинг — верхнеуровневая система, агрегирующая сигналы (алерты/статусы) от нескольких нижележащих систем мониторинга разных команд/доменов в единую панель для дежурных/руководства — не подменяет специализированные системы мониторинга конкретных сервисов, а сводит их в общую картину состояния на уровне всей организации.

### Что такое Monq?

Российская платформа для зонтичного (umbrella) мониторинга и AIOps — агрегирует события/алерты из нижележащих систем мониторинга разных команд (включая Zabbix, Prometheus и другие источники) в единую панель, с возможностью писать сценарии обработки событий (корреляция, автоматические действия по алертам). Личного опыта работы с конкретно Monq у меня нет — знаю его как класс продукта (зонтичный мониторинг, см. вопрос про Zabbix выше) по описанию вакансии, а не по практике; на собеседовании честно обозначил бы это и попросил рассказать подробнее о том, как именно он используется в их процессах.

### Что такое переменные в Grafana?

Параметры дашборда, которые можно менять через выпадающий список сверху (например, `$instance`, `$job`, `$datacenter`), не редактируя сами запросы панелей — сами PromQL-запросы ссылаются на переменную (`up{instance="$instance"}`), и при смене значения в выпадающем списке весь дашборд пересчитывается под выбранный контекст. Это то, что позволяет держать один шаблонный дашборд вместо копии на каждый сервис/инстанс — прямое продолжение темы унификации метрик, которая уже разбиралась выше.