Question 1

Чем метрики, логи и трейсы дополняют друг друга? С какого сигнала начнёшь, если пользователи жалуются на медленный API?

Accepted Answer

Метрики быстро показывают масштаб и время проблемы, логи объясняют конкретные события, а трейсы раскладывают один запрос по сервисам и зависимостям. Я начну с метрик задержки и ошибок, сузю интервал и сегмент, затем открою медленный трейс и связанные с ним структурированные логи. Один сигнал редко даёт и симптом, и причину.

Question 2

Какие типы метрик Prometheus выберешь для общего числа запросов, текущей длины очереди и времени ответа? Почему нельзя строить график нагрузки прямо по значению счётчика?

Accepted Answer

Общее число запросов — counter, длина очереди — gauge, а время ответа — histogram. Сырой counter почти всегда растёт и сбрасывается при рестарте, поэтому нагрузку показываю через rate() или increase() на диапазоне. Histogram хранит распределение по бакетам, сумму и число наблюдений, поэтому из него можно считать доли и квантили.

Question 3

Каким должен быть лог приложения, чтобы по нему реально расследовать сбой в проде? Что в лог писать нельзя?

Accepted Answer

Пишу структурированное событие со временем, уровнем, сервисом, окружением, названием операции, результатом и идентификаторами запроса или трейса. Поля должны быть стабильными и пригодными для фильтрации, а сообщение — объяснять событие, а не дублировать весь payload. Секреты, токены, пароли и лишние персональные данные в логи не попадают.

Question 4

Стоит ли будить дежурного из-за CPU выше порога? Как отличить хороший алерт от шумного?

Accepted Answer

Высокий CPU сам по себе чаще причина для дашборда или тикета, а не для немедленного page: будить нужно при срочном пользовательском воздействии и наличии действия. Хороший алерт устойчив к короткому шуму, содержит масштаб и контекст, ведёт к runbook и попадает правильному владельцу. Если на сигнал нельзя разумно отреагировать сейчас, его не стоит отправлять в pager.

Question 5

Разработчик добавил в Prometheus-метрику labels user_id, request_id и полный URL. Что сломается и как сохранить нужную диагностическую ценность?

Accepted Answer

Каждая уникальная комбинация labels создаёт отдельный временной ряд, поэтому неограниченные ID и URL резко увеличат cardinality, память, размер хранилища и стоимость запросов. В метриках оставлю только ограниченные измерения вроде метода, шаблона маршрута, статуса и региона. Конкретный запрос перенесу в логи или трейсы и свяжу сигналы через trace ID или exemplar.

Question 6

Как Prometheus получает метрики с приложения и как отличить падение сервиса от поломанного сбора метрик?

Accepted Answer

Prometheus по расписанию опрашивает обнаруженные targets по HTTP и сохраняет временные ряды из их exposition endpoint. Для известной цели метрика up показывает успех последнего scrape, а исчезнувшую из discovery цель приходится отдельно обнаруживать через проверку отсутствия ожидаемых рядов. Состояние scrape ещё не доказывает доступность сервиса для пользователя, поэтому его сверяю с внешней проверкой и сервисными метриками.

Question 7

Средняя задержка API нормальная, но пользователи жалуются на редкие зависания. Как посчитать p95 или долю запросов быстрее порога по Prometheus histogram и не ошибиться при агрегации реплик?

Accepted Answer

Использую histogram с бакетами вокруг значимых порогов. Для classic histogram сначала считаю rate по _bucket, суммирую реплики с сохранением label le, а затем применяю histogram_quantile. Долю запросов не дольше T считаю как sum(rate(..._bucket{le="T"}[...])) / sum(rate(..._count[...])), только если граница T была явно настроена; соседние бакеты дают лишь нижнюю или верхнюю оценку. Усреднять готовые квантили разных реплик нельзя.

Question 8

Как применить RED к API, а USE — к его узлам и зависимостям? Почему одного графика загрузки CPU недостаточно?

Accepted Answer

Для потока запросов RED — это rate, errors и duration: сколько работы приходит, какая доля неуспешна и сколько она занимает. Для ресурса USE — utilization, saturation и errors: насколько он занят, есть ли очередь или ожидание и происходят ли ошибки. CPU может быть невысоким при насыщенном диске, пуле соединений или внешней зависимости, поэтому он не описывает сервис целиком.

Question 9

Трасса HTTP-запроса обрывается после публикации сообщения в очередь. Что нужно передать между сервисами и как выбрать sampling, чтобы не потерять самые полезные запросы?

Accepted Answer

Продюсер должен внедрить trace context в метаданные сообщения, а consumer — извлечь его и создать связанный span; передавать локальный объект контекста между процессами нельзя. Head sampling дешёвый и принимает решение в начале, но не знает исход запроса; tail sampling видит готовую трассу и может сохранить ошибки и медленные запросы, зато требует буферизации. Политика должна сохранять целые трассы и учитывать низкочастотные критичные операции.

Question 10

Как определить SLI и SLO для API, если технический health-check всегда зелёный, а часть пользователей не может оформить заказ? Что такое error budget?

Accepted Answer

SLI должен измерять успешный пользовательский результат на границе сервиса, например долю валидных попыток оформления, завершившихся корректно и вовремя. SLO задаёт целевую долю хороших событий за явное окно, а error budget — допустимая доля плохих событий, равная единице минус цель. Зелёный health-check проверяет процесс, но не заменяет SLI бизнес-пути.

Question 11

После релиза p99 вырос только в одном регионе, а общий error rate почти не изменился. Как проведёшь расследование и какой дашборд поможет не гадать?

Accepted Answer

Сначала подтвержу временную и пользовательскую границу: регион, маршрут, версия, доля трафика и момент релиза. Затем сравню RED между старой и новой версиями, найду медленные трейсы проблемного сегмента и проверю спаны зависимостей и связанные логи. Если влияние существенно и релиз хорошо коррелирует с началом деградации, безопасный rollback важнее полного разбора во время инцидента.

Question 12

Спроектируй алерты по SLO для быстрого массового сбоя и медленной деградации. Что должно быть в runbook, чтобы дежурный не начинал расследование с нуля?

Accepted Answer

Алерчу не на сам факт единичной ошибки, а на burn rate — насколько быстрее допустимого расходуется error budget. Быстрый расход проверяю коротким и подтверждающим длинным окном для page, медленный — более длинными окнами и менее срочным каналом. Runbook объясняет влияние, даёт точные проверки и безопасные способы смягчения, владельца и условия эскалации.

Вопросы на собеседовании: Наблюдаемость и диагностика

junior: база, с которой начинают

Чем метрики, логи и трейсы дополняют друг друга? С какого сигнала начнёшь, если пользователи жалуются на медленный API?

Каким должен быть лог приложения, чтобы по нему реально расследовать сбой в проде? Что в лог писать нельзя?

Стоит ли будить дежурного из-за CPU выше порога? Как отличить хороший алерт от шумного?

Как Prometheus получает метрики с приложения и как отличить падение сервиса от поломанного сбора метрик?

middle: где отделяют уверенных

Разработчик добавил в Prometheus-метрику labels `user_id`, `request_id` и полный URL. Что сломается и как сохранить нужную диагностическую ценность?

Как применить RED к API, а USE — к его узлам и зависимостям? Почему одного графика загрузки CPU недостаточно?

Трасса HTTP-запроса обрывается после публикации сообщения в очередь. Что нужно передать между сервисами и как выбрать sampling, чтобы не потерять самые полезные запросы?

После релиза p99 вырос только в одном регионе, а общий error rate почти не изменился. Как проведёшь расследование и какой дашборд поможет не гадать?

senior: глубина и продакшн

Как определить SLI и SLO для API, если технический health-check всегда зелёный, а часть пользователей не может оформить заказ? Что такое error budget?

Спроектируй алерты по SLO для быстрого массового сбоя и медленной деградации. Что должно быть в runbook, чтобы дежурный не начинал расследование с нуля?

Соседние темы того же собеса