resume/stack/monitoring/QUESTIONS.md

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

Опираются на кейс: 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/).

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

Grafana + Prometheus + Mimir + объектное хранилище (MinIO/S3) под блоки Mimir. Один Prometheus не рассчитан на такой масштаб (публичный ориентир — до ~1–2 млн активных series на инстанс, см. ../../legend/CAPACITY.md), поэтому схема — множество Prometheus-инстансов, шардированных по группам серверов/сервисов (например, по датацентру или по команде), каждый scrape'ит свою часть парка и отправляет данные через remote_write в Mimir. Mimir горизонтально масштабируется (ingester/distributor/querier как отдельные компоненты) и хранит блоки в объектном хранилище — это снимает ограничение на объём долгосрочного хранения метрик с одного диска. Grafana обращается к Mimir как к единому PromQL-совместимому источнику, не зная о шардировании снизу. У себя в лабе я воспроизвёл этот же принцип в миниатюре — Prometheus → remote_write → Mimir → Grafana (см. 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 я специально проверял, как выглядит 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"}), и при смене значения в выпадающем списке весь дашборд пересчитывается под выбранный контекст. Это то, что позволяет держать один шаблонный дашборд вместо копии на каждый сервис/инстанс — прямое продолжение темы унификации метрик, которая уже разбиралась выше.