Без мониторинга инфраструктуры и сервисов любая проблема с приложением становится сюрпризом, причём обычно неприятным, который случается в самый неподходящий момент. С помощью настроенного мониторинга мы можем обнаружить проблемы до того, как пользователи придут и начнут жаловаться. 

Меня зовут Юлия Рубцова, я ведущий менеджер продукта Yandex Monitoring. В этой серии статей я и мой коллега Владимир Гордийчук @gordiychuk рассказываем про реальные сценарии использования мониторинга облачных решений. Что вас ждёт: мы покажем, как настроить дашборды, быстро проверить гипотезы при расследовании инцидента, а в конце соберём лучшие практики для настройки мониторинга. 

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

Что такое мониторинг и зачем он нужен 

В случае облачной инфраструктуры под мониторингом мы понимаем не просто пару графиков, а целую экосистему наблюдений, в которую входят: 

• Метрики с числовыми показателями: количество запросов в секунду, время ответа. 

• Логи в виде текстовых записей событий из разных журналов.

• Трассировки — истории запросов, проходящих через несколько сервисов, помогающие понять, как запрос шёл по системе. 

Вместе они позволяют посмотреть на одну и ту же проблему под разными углами и разобраться, где узкое горлышко в системе и как можно оптимизировать производительность или где случилась поломка и почему она произошла. Метрики, логи и трейсы — всё это называется телеметрией. В этой статье сфокусируемся на метриках. 

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

У нас есть подсказки или чек‑листы, как это можно сделать. Первый чек‑лист — это четыре золотых сигнала от Google SRE. 

Согласно этому подходу, мы измеряем:

• время отклика, или latency: сколько времени занимает выполнение операций или запроса; 

• traffic — сколько запросов мы вообще обслуживаем; 

• errors — сколько запросов завершается с ошибками;

• saturation — насколько загружена система, то есть остаток ресурсов и степень заполненности очередей. 

Эти четыре показателя дают обзор системы как с пользовательской стороны, так и с инфраструктурной. Любую проблему можно начинать диагностировать с них. 

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

Помимо этого, есть чек‑листы для разных типов систем. 

Например, для системы микросервисов, где главное — это обработка внешних запросов, Том Уилки предложил использовать подход RED (Requests, Errors, Durations). С точки зрения пользователя мы смотрим на систему как на чёрный ящик: сколько запросов, насколько быстро они происходят, сколько из них выполнилось с ошибками.

Для низкоуровневых компонентов, таких как диски, сеть, операционные системы, рекомендуют использовать подход USE (Utilization, Saturation, Errors), который предложил Брендон Грегг. Этот подход ориентирован на мониторинг инфраструктуры. Подход помогает ответить на вопросы вида «Не упёрлись ли мы в пределы железа?». 

Если золотые сигналы дают общий обзор, то RED и USE вместе дополняют друг друга. RED показывает, когда плохо пользователям, а USE — почему тяжело системе. Мы рекомендуем инструментировать метриками всё: любые асинхронные операции, очереди, клиент‑серверные взаимодействия. Это позволит не гадать на кофейной гуще, а быстрее и проще подтверждать гипотезу, где и что сломалось. 

Мониторинг асинхронных задач 

В этой части я расскажу о нескольких кейсах мониторинга асинхронных задач (все совпадения случайны :-) ). 

Асинхронные задачи — это, по сути, обработка запросов несколькими тредами, которые не блокируют основной поток выполнения. Другими словами, мы начинаем одну задачу и параллельно продолжаем делать другие вещи. Для этого запускаем воркеры — это фоновый процесс, который обрабатывает задачи из очереди сообщений. Когда ответ будет готов, мы его получим. 

Асинхронные задачи коварны тем, что они выполняются в фоне и пользователю не видны. Если воркер зависает, мы можем не узнать про это сразу. Поэтому асинхронные задачи очень важно инструментировать метриками. 

Какие метрики мы рекомендуем собирать для важных асинхронных задач: 

1. Сколько задач запускается в секунду (RPS, также может обозначаться на дашборде как started). Метрика покажет интенсивность. С её помощью можно понять, запускаются задачи или нет, произошёл ли какой‑то инцидент, а также какое количество задач успешно завершается (completed). Идеально, когда у нас завершается столько же задач, сколько и начиналось.

2. Сколько задач завершается с ошибкой (errors). Если этот параметр больше нуля, то надо разбираться. 

3. Время выполнения задачи (elapsed time). Обычно анализируем перцентили распределения: 50-й, 90-й, 99-й, рассчитанные по гистограмме времени выполнения. 

Этот набор метрик обеспечивает полноту картины: как часто задачи приходят, сколько их висит в процессе, сколько времени они занимают и часто ли падают. Разберёмся, как вычислять перцентили, и как это может нам помочь на примере асинхронных задач . 

Например, есть задача посчитать перцентиль времени выполнения запроса по всем хостам. 

Предположим, у нас несколько хостов, и мы считаем elapsed time, то есть сколько времени выполнялась одна конкретная задача. Для каждого хоста мы выделили четыре бакета, и в зависимости от времени выполнения мы инкрементируем значение в нужном бакете. 

Например, мы хотим посчитать 5% самых медленных запросов в кластере. При анализе распределения 5% медленных запросов означают, что остальные 95% укладываются в ожидаемое время обработки — то есть посчитать 95-й перцентиль. 

Если мы возьмём 95-й перцентиль с каждого хоста и потом усредним это значение, то получим статистически не корректный ответ. Потому что перцентили связаны с конкретными значениями в наборе, и их вычисление зависит от распределения этих данных. А гистограммы — это дискретное распределение данных по бакетам, но не сами данные. Поэтому мы можем просуммировать гистограммы по всем хостам и получить новое распределение. И вот уже по общему распределению можно найти нужный перцентиль, который покажет информацию по всему кластеру. 

Найдём 95-й перцентиль для хостов А и В. Для этого нам нужно понять, в каком бакете находятся десять самых медленных запросов: 95-й перцентиль от 200 просуммированных запросов — это десять запросов. 

Для этого мы суммируем гистограммы и проанализируем полученное распределение. 

На графике видим, что десять самых медленных запросов всей системы какого‑то отдельно взятого хоста лежат в последнем бакете, они выполняются более чем за 300 миллисекунд. Итого: мы сложили гистограммы бакетов, посчитали, сколько запросов в каждом бакете, и нашли, где находится десять самых медленных запросов. Это и есть наш 95-й перцентиль. 

Гистограммы мы можем складывать, а перцентили складывать нельзя. Перцентили дают нам корректное представление о производительности всей системы, а не отдельно конкретной виртуальной машины. 

Проблема: таинственное зависание асинхронных задач

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

• Started — сколько запросов мы вообще обслуживаем (Traffic); 

• Elapsed time — время выполнение операций или запроса (Latency); 

• Errors — сколько запросов завершается с ошибками; 

• Inflight — насколько загружена система: количество выполняемых задач (Saturation). 

Посмотрим на графики последовательно. Видим, что есть сервис, который обрабатывает данные асинхронно; обычно он запускает 500 задач в секунду. Судя по графикам, всё нормально: количество запускаемых задач стабильно. 

Количество завершаемых задач примерно такое же и тоже стабильно.

Ошибок нет. 

90-й и 50-й перцентили времени выполнения неизменны, составляют где‑то около одной секунды.

Но вот метрика инфлайта (inflight, букв. «в полёте»), то есть количества задач в процессе, растёт, достигает какого‑то высокого уровня, затем выходит на плато. Это значит, что задачи копятся и не завершаются вовремя. 

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

Гипотеза 1: все задачи стали выполняться медленнее, но тогда бы изменились метрики времени, а мы этого на графиках не видим. 

Гипотеза 2: часть задач подвисает и не завершается, то есть она где‑то залипла. Очень похоже на правдивую гипотезу. 

Попробуем разобраться. Прямо из дашборда переходим к графику инфлайтов. Для этого нажимаем на иконку «Перейти в мониторинг». 

Мы перешли в Metrics Explorer и смотрим на графики инфлайта. Нам нужно понять, где залипает операция. Что здесь можно сделать? Можно воспользоваться разбивкой графика. Эта функциональность разбивает графики по той метке, по которой мы хотели бы разложить метрику и посмотреть топ значений по определенной статистике, например, среднее. Конкретно сейчас нас интересует метка хост. 

Разбиваем график по метке host и смотрим отдельно графики по каждому хосту. Далее полученные графики мы сортируем по среднему значению метрики. 

И видим, что рост инфлайта идёт с одного конкретного хоста. Это host-03. Остальные машины работают нормально, а на этой машине задачи накапливаются.

Вернёмся на наш дашборд и выберем проблемный host-03 в параметрах. 

Инфлайт на этом хосте достиг постоянно высокого уровня, он дошёл до предельного значения. 

Новые задачи туда не берутся: мы видим, что метрика стартов упала до нуля. 

Это значит, что новая задача стартует только после того, как завершаются предыдущие. На практике это выглядит так, будто воркер выполняет ровно одну задачу за один раз. Следующие задачи не берутся в работу, пока предыдущая не отпадёт. 

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

Таким образом, мы локализовали проблему. Один экземпляр сервиса зависает на задаче и больше ничего не делает. С помощью метрик мы определили, на каком именно хосте залипает задача. 

Это был скрытый баг, который без мониторинга мы бы очень долго искали. В нашем случае в логах мы нашли, что асинхронная задача на этом хосте зависла на обращении к внешнему API и не завершилась по тайм‑ауту. 

Какие выводы можно сделать из этого кейса? Первое — мониторинг позволил быстро понять, что проблема не в общей нагрузке, а конкретно в зависшем воркере. Второе — мы оперативно починили баг, все метрики вернулись в норму. 

На этом с асинхронными задачами всё. А в следующий раз посмотрим на мониторинг очередей.