Как реализован сбор и отображение метрик в Grafana

Что проверяют

Понимаете ли вы, что Grafana ничего не собирает сама: она строит графики поверх хранилища метрик. Интервьюеру важно, как метрики появляются в вашем Python-сервисе и доходят до дашборда. Следом спрашивают, какие метрики вы бы вывели и как настроили алерты.

Как отвечать

Опишите цепочку из трёх звеньев на самом распространённом стеке:

• инструментирование: в сервисе библиотека prometheus_client или OpenTelemetry SDK с экспортом в Prometheus. Типы: Counter для запросов и ошибок, Gauge для текущих значений вроде размера очереди, Histogram для задержек. Для FastAPI и Django есть готовые middleware, которые отдают /metrics;
• сбор: Prometheus работает по модели pull и раз в scrape_interval сам ходит на /metrics каждого таргета из конфига или service discovery. Для коротких batch-задач есть Pushgateway, для долгого хранения ставят VictoriaMetrics, Thanos или Mimir;
• отображение: в Grafana Prometheus подключается как data source, панели строятся запросами на PromQL: rate(http_requests_total[5m]), доля ошибок, перцентили через histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m]))).

Дашборды и источники данных держат в репозитории через provisioning (YAML и JSON), а не накликивают руками. Алерты задают в Grafana Alerting или в Alertmanager рядом с Prometheus.

Отдельно назовите особенность Python: под Gunicorn с несколькими воркерами каждый процесс считает свои метрики, и нужен multiprocess-режим prometheus_client с каталогом из PROMETHEUS_MULTIPROC_DIR.

Где спотыкаются

Говорят, что Grafana «собирает метрики с сервера». Это путает визуализацию с хранилищем.

Кладут в лейблы user_id, полный URL или текст ошибки. Высокая кардинальность раздувает Prometheus и тормозит запросы.

Строят график по сырому счётчику вместо rate() и не понимают, откуда провалы после рестарта процесса.