Вопросы по мониторингу на собеседовании: Prometheus, алерты, логи

Мониторинг проверяют на понимании, а не на списке инструментов. Почему лейбл с идентификатором пользователя роняет хранилище, чем sum(rate(...)) отличается от rate(sum(...)), почему алерт на загрузку процессора будит зря, а деградацию сервиса пропускает.

Что спрашивают

• +Метрики: pull-модель и экспортеры, counter, gauge и histogram, кардинальность и число рядов
• +PromQL: rate и обработка сброса счётчика, порядок агрегации, квантили из бакетов гистограммы
• +Алертинг: параметр for, симптомы против причин, группировка и подавление в Alertmanager
• +Логи и трассы: структурный формат, сквозной идентификатор запроса, сэмплирование, золотые сигналы

Из чего состоит тема

Так тема разложена в тренажёре: движок ведёт прогресс по каждой подтеме отдельно и возвращает те, где вы ошибаетесь.

• Логи8
• Алертинг и дежурство7
• Метрики и Prometheus7
• PromQL и правила6
• Трейсинг и золотые сигналы6

Разборы подтем

Конспект по каждой: что это, как отвечать вслух, на чём валятся, плюс вопросы для самопроверки.

• Метрики и Prometheus: типы и кардинальность7 вопросов
• PromQL: rate, агрегация, квантили6 вопросов
• Алерты и дежурство без шума7 вопросов
• Логи: структура, объём, идентификатор запроса8 вопросов
• Трассировка и золотые сигналы6 вопросов

Примеры вопросов с разбором

1. #dvo_alerting1 / 9
   В правиле алерта указано for: 5m. Что это даёт?

   A)Алерт повторно шлётся каждые пять минут, пока не погаснет

   B)Условие должно держаться все пять минут

   C)Метрика усредняется за пятиминутное окно перед сравнением

   D)После срабатывания алерт молчит пять минут и не дублируется

   показать ответ и разбор

   +B)Условие должно держаться все пять минут

   // разбор: Правило переходит в состояние pending, как только условие стало истинным, и превращается в firing, только если оно продержалось указанное время. Так отсекаются секундные всплески и дребезг у порога. Оборотная сторона — задержка обнаружения: для быстро деградирующих сервисов держат короткое ожидание или комбинируют два правила с разными окнами и порогами.

2. #dvo_logging2 / 9
   Почему в проде просят писать логи структурно, а не свободной строкой?

   A)Структурный лог занимает меньше места на диске

   B)Только такой формат принимают системы сбора логов

   C)По полям можно искать и фильтровать без разбора регулярками

   D)Структурный формат исключает попадание секретов в лог

   показать ответ и разбор

   +C)По полям можно искать и фильтровать без разбора регулярками

   // разбор: Строка «ошибка у пользователя 42 при оплате» требует регулярки, которая ломается от любой правки формулировки. Запись с полями (уровень, сервис, идентификатор запроса, код ошибки, длительность) индексируется и ищется запросами, агрегируется в дашборд, связывается с трассой по общему полю. Плата — чуть больший объём и дисциплина: набор полей должен быть общим для всех сервисов.

3. #dvo_metrics3 / 9
   Как Prometheus получает метрики сервиса?

   A)Сервис шлёт метрики в Prometheus по протоколу statsd

   B)Агент на ноде собирает метрики и пересылает их в базу

   C)Prometheus сам забирает значения по HTTP

   D)Метрики попадают через журнал: Prometheus читает логи сервиса

   показать ответ и разбор

   +C)Prometheus сам забирает значения по HTTP

   // разбор: Модель pull: сервис отдаёт текущее состояние счётчиков на эндпоинте, а Prometheus по расписанию обходит цели, найденные через service discovery. Плюсы — сервер знает, кто жив (метрика up), нет очередей и обратного давления от приёмника. Минус — короткоживущие задачи не успевают попасть под опрос; для них есть pushgateway, но им не злоупотребляют: метрика теряет привязку к экземпляру.

4. #dvo_promql4 / 9
   Почему частоту запросов считают через rate по счётчику, а не разностью соседних значений?

   A)Разность запрещена синтаксисом языка запросов

   B)Rate сглаживает данные и убирает выбросы измерений

   C)Разность считает в штуках, а нужны проценты

   D)Rate даёт частоту и переживает сброс

   показать ответ и разбор

   +D)Rate даёт частоту и переживает сброс

   // разбор: Счётчик обнуляется при каждом рестарте процесса, и наивная разность даёт отрицательный скачок или чудовищный всплеск. Rate за окно видит сброс, чинит его и делит прирост на длительность — получается частота в секунду, сравнимая между инстансами и окнами. Для алертов чаще берут rate за 5 минут, для быстрых графиков — irate, который смотрит два последних отсчёта.

5. #dvo_tracing5 / 9
   Метрики и логи уже есть. Что добавляет распределённая трассировка?

   A)Разбивку одного запроса по сервисам с временем каждого шага

   B)Хранение метрик с высоким разрешением за длительный период

   C)Автоматическое обнаружение аномалий в поведении сервисов

   D)Проверку доступности сервисов из разных точек сети

   показать ответ и разбор

   +A)Разбивку одного запроса по сервисам с временем каждого шага

   // разбор: Метрики отвечают «сколько и как быстро в целом», логи — «что случилось в конкретном месте», трасса — «куда ушло время внутри одного запроса»: цепочка спанов с длительностью каждого вызова, включая базы и внешние API. Это единственный удобный способ увидеть, что 300 миллисекунд из 400 съел один медленный вызов на четвёртом уровне вложенности.

6. #dvo_alerting6 / 9
   Дежурного будят алертом «CPU ноды выше 90%». Пользователи при этом ничего не замечают. В чём беда правила?

   A)Порог занижен: будить стоит от 95% и выше

   B)Алерт нужно вешать на среднее по кластеру, а не на ноду

   C)Правилу не хватает окна: с пятиминутным ожиданием оно замолчит

   D)Это алерт на причину, а будить должны симптомы для пользователя

   показать ответ и разбор

   +D)Это алерт на причину, а будить должны симптомы для пользователя

   // разбор: Высокая загрузка процессора сама по себе не беда: сервис может отвечать в срок и на 95%. Будят по симптомам — росту ошибок, задержкам выше цели, сжиганию бюджета ошибок, — то есть по тому, что чувствует пользователь. Метрики ресурсов остаются на дашбордах и помогают разбираться после срабатывания, а в правила попадают только там, где упор в ресурс гарантированно ведёт к отказу.

7. #dvo_logging7 / 9
   После релиза объём логов вырос в десять раз, хранилище задыхается. Что делать в первую очередь?

   A)Поднять срок хранения, чтобы данные не терялись при чистке

   B)Найти болтливые источники, урезать уровень

   C)Перевести сбор логов на push-модель с агентом на каждой ноде

   D)Сжать индексы и отключить полнотекстовый поиск по всем полям

   показать ответ и разбор

   +B)Найти болтливые источники, урезать уровень

   // разбор: Сначала находят источник: обычно это debug, забытый включённым, или лог на каждый запрос в горячем пути. Дальше — уровень логирования по сервисам, сэмплирование повторяющихся событий, вынос детальной отладки во включаемый по требованию режим. Заодно проверяют срок хранения по классам логов: аудит держат долго, отладку — дни.

8. #dvo_metrics8 / 9
   Считаем число обработанных заказов, текущий размер очереди и распределение времени ответа. Какие типы метрик брать?

   A)Counter, gauge и histogram соответственно

   B)Gauge, counter и summary соответственно

   C)Три counter: остальные типы нужны только для системных метрик

   D)Histogram для всех трёх: он покрывает и счётчики, и текущие значения

   показать ответ и разбор

   +A)Counter, gauge и histogram соответственно

   // разбор: Counter только растёт и обнуляется при рестарте — им считают события: запросы, ошибки, заказы. Gauge меняется в обе стороны и показывает мгновенное значение: длина очереди, число соединений, свободная память. Histogram раскладывает наблюдения по бакетам и позволяет считать квантили на сервере и агрегировать их между экземплярами — то, чего summary с его локальными квантилями не умеет.

9. #dvo_promql9 / 9
   Нужна суммарная частота запросов по сервису. Почему пишут sum(rate(...)), а не rate(sum(...))?

   A)Rate считают до агрегации, иначе сброс портит сумму

   B)Sum не работает с диапазонными векторами по синтаксису

   C)Порядок не важен, sum(rate) просто короче записывается

   D)Rate после агрегации даст значения в других единицах измерения

   показать ответ и разбор

   +A)Rate считают до агрегации, иначе сброс портит сумму

   // разбор: Rate умеет чинить обнуление, только пока видит каждый ряд отдельно. Если сначала сложить счётчики, то рестарт одного пода уронит сумму, и функция примет это за сброс или пропустит скачок — цифры поедут. Потому канон такой: rate по каждому ряду, затем sum by нужным лейблам. Тот же принцип действует для гистограмм: сначала rate по бакетам, потом суммирование и квантиль.

Частые вопросы

• Что такое кардинальность и почему она важна?

  Временной ряд задаётся именем метрики и полным набором лейблов. Значение с большим числом вариантов, например идентификатор пользователя, порождает ряд на каждого: хранилище распухает и падает по памяти. Уникальное место в логах и трассах, а не в лейблах.

• По чему правильно будить дежурного?

  По симптомам, которые чувствует пользователь: рост ошибок, задержка выше цели, быстрое сжигание бюджета ошибок. Загрузка процессора и памяти остаются на дашбордах и помогают в разборе, но сами по себе не означают, что сервису плохо.