Приходилось ли настраивать графики и дашборды в Grafana
Что проверяют
Умеете ли вы выбирать метрики своего сервиса и строить дашборд, по которому дежурный поймёт, что сломалось. Инструмент тут вторичен, важно другое: что мерить и как это правильно посчитать.
Как отвечать
Расскажите цепочку целиком. В Go метрики отдаёт клиентская библиотека Prometheus через отдельную ручку, рядом идут метрики рантайма: число горутин, куча, паузы сборщика. Дальше Prometheus собирает, Grafana рисует.
По содержанию опирайтесь на понятную схему: для сервиса это поток запросов, доля ошибок и задержка, для ресурсов это загрузка, насыщение и ошибки. Сверху общая строка здоровья, ниже разрезы по ручкам и инстансам, переменные дашборда для выбора окружения, аннотации выкаток, чтобы связывать всплеск с релизом.
Отдельно покажите знание формул: задержку берут из гистограммы, через histogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket[5m]))), а не из среднего. Алерты вешают на симптом, который чувствует пользователь, и обязательно с выдержкой for, чтобы одиночный всплеск не будил человека ночью.
Где спотыкаются
Кладут в метку идентификатор: пользователя, заказ, путь с числом внутри. Каждое значение метки это отдельный временной ряд, и такая метрика укладывает хранилище целиком.
Показывают среднее время ответа. Среднее прячет хвост: часть пользователей может ждать секунды, а график останется ровным. Ещё хуже усреднять готовые квантили по инстансам, это математически бессмысленно, считать надо по сумме бакетов.
Строят дашборд на сотню панелей и алерты без выдержки. На первое никто не смотрит, потому что непонятно, с чего начинать, а второе через неделю уезжает в отдельную папку почты вместе с настоящими авариями.