Кто обычно пишет запросы для Grafana и Kibana: разработчики или аналитики

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

Не распределение ролей в вакууме, а то, работали ли вы сами с наблюдаемостью своего сервиса. Для Python-разработчика верный ответ склоняется к «в основном мы», и интервьюер ждёт примеров. Следом часто просят прочитать или написать простой запрос на PromQL.

Как отвечать

Разведите две задачи. Технический мониторинг, то есть задержки, ошибки, нагрузка и логи, это зона разработчиков, SRE и DevOps: они инструментируют код и первыми смотрят в дашборды на дежурстве. Продуктовая аналитика, воронки и конверсии, обычно живёт в BI вроде Superset, Metabase или DataLens поверх хранилища, и там аналитики пишут SQL. В Kibana они заходят чаще, чем в Grafana, обычно за событиями из логов.

Что делает разработчик:

• метрики: prometheus_client с Counter, Histogram, Gauge или OpenTelemetry, эндпоинт /metrics. В Grafana запросы вроде rate(http_requests_total[5m]) или histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])));
• логи: JSON через structlog или форматтер для logging, чтобы в Kibana фильтровать по полям на KQL: service.name : "billing" and log.level : "error". Для агрегаций есть Query DSL и ES|QL, для логов из Loki в Grafana язык LogQL;
• алерты: правила на те же запросы, чтобы о росте ошибок узнавать не от пользователей;
• дашборды как код: JSON в репозитории с provisioning или Terraform, а не ручные правки в интерфейсе.

Если за дашборды у вас отвечал отдельный SRE, скажите честно и расскажите, какие метрики добавляли в код сами.

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

Отвечают «аналитики, это же аналитика». Grafana в первую очередь инструмент эксплуатации, и такой ответ выдаёт, что вы в неё не заходили.

Путают языки: пишут SQL там, где нужен PromQL, или не знают, что строка поиска Kibana по умолчанию понимает KQL.

Логируют строками без структуры, а потом не могут отфильтровать ошибки одного запроса по request_id.