Работали ли вы с сервисами мониторинга ресурсов, такими как Grafana, Prometheus, Zabbix

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

Умеете ли вы смотреть на систему снаружи, цифрами, а не только через интерфейс. Тестировщик, который приносит график вместо фразы «у меня подтормаживает», экономит команде часы разбирательств.

Как отвечать

Начните с того, что это три разные вещи, и путать их нельзя:

• Prometheus: база временных рядов, которая сама ходит за метриками по HTTP и хранит их, запросы пишутся на PromQL;
• Grafana: слой визуализации и оповещений поверх источников данных, своих метрик не собирает и не хранит;
• Zabbix: законченная система мониторинга с агентом, шаблонами и собственным хранилищем, чаще про инфраструктуру: диск, память, доступность узлов.

Дальше покажите, как пользуетесь этим в работе: смотрите дашборд во время нагрузочного прогона и связываете просадку с конкретным сервисом, различаете счётчик и гистограмму, поэтому берёте квантиль задержки, а не среднее.

histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))

Сильный штрих в ответе: проверяли не только метрики, но и сами оповещения, то есть роняли сервис на стенде и смотрели, дошло ли уведомление до дежурного.

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

Говорят «настроил сбор метрик в Grafana». Собирает Prometheus или агент Zabbix, Grafana только рисует. Такая оговорка сразу показывает, что человек видел дашборд, но не настраивал источник.

Смотрят среднее время ответа. Среднее гасит хвост распределения, а пользователь чувствует именно хвост: верхние квантили покажут проблему, которой в среднем не видно.

Прикладывают к дефекту график без контекста. Нужны точные границы окна, версия сборки, какой сценарий крутился и сколько было потоков. Без этого разработчик смотрит на красивую линию и не может ничего воспроизвести.