Мониторинг: регулярные измерения и история

§1Что такое мониторинг

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

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

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

Мониторинг состоит из пяти шагов, и они выполняются по порядку.

1. Измерить

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

2. Сохранить

   Значение записывается вместе с моментом измерения. Без отметки времени число не поставить в историю.

3. Сопоставить

   Значения группируют и сравнивают: по маршрутам, по экземплярам, с тем же часом вчера.

4. Показать

   Результат выводится графиком, таблицей или одним числом на панели.

5. Отреагировать

   Правило проверяет условие, например «доля ошибок выше 2% в течение пяти минут», и отправляет уведомление человеку.

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

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

Первоисточник: Google SRE Book · Monitoring Distributed Systems ↗

Первый шаг мониторинга — измерить. Следующий раздел разбирает, из чего состоит результат измерения.

§2Из чего состоит показатель

На панели стоит строка «CPU 80%». Для решения её недостаточно: непонятно, чей это процессор, как посчитан процент и за какой промежуток времени. У любого показателя в мониторинге четыре части.

Первая часть — объект: чей это показатель. Объектом бывает процесс, сервер, маршрут или очередь, например процесс API на сервере api-2. Вторая — величина: что измеряется, например длительность обработки запроса к /products. Третья — единица, в которой выражено значение, например миллисекунды. Четвёртая — способ расчёта: как из отдельных измерений получено одно число, например среднее за последнюю минуту.

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

Способ расчёта хорошо виден на том же CPU. В Linux утилита top по умолчанию показывает загрузку процесса относительно одного ядра, поэтому процесс, полностью занявший четыре ядра, получит 400%. Другая программа делит ту же нагрузку на число ядер и показывает 100%. Обе цифры верны, но посчитаны разными способами, и без подписи сравнивать их нельзя.

Показатель описывает одно значение. Чтобы видеть изменения, значения одного показателя собирают в ряд.

§3Временной ряд: значение и момент измерения

Одно измерение отвечает только на вопрос «сколько сейчас». Для мониторинга важнее, как значение менялось и когда начались изменения. Для этого измерения одной величины собирают в последовательность.

Временной ряд — последовательность значений одной величины у одного объекта, упорядоченная по времени. Каждая точка ряда — пара «момент измерения и значение».

Ниже два ряда загрузки CPU. Последнее значение у них одинаковое — 80%. Переключите ряды и сравните форму линии.

В первом ряду загрузка держится около 80% все пять минут. Для вычислительной задачи это может быть обычная работа. Во втором ряду загрузка за две минуты выросла с 25% до 80%: пришла новая нагрузка или запустилась тяжёлая задача. По последнему числу эти ситуации не различить, а по истории они различаются сразу.

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

Первоисточник: Prometheus · Data model ↗

Точки ряда стоят на расстоянии друг от друга. Следующий раздел показывает, что зависит от этого расстояния.

§4Частота измерений и что происходит между ними

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

Часть потерь снимает выбор типа показателя. Счётчик, который только растёт, не пропустит события между измерениями: если за минуту пришло 600 запросов, счётчик вырастет на 600, когда бы его ни прочитали. Мгновенное значение, например текущая длина очереди, такой гарантии не даёт. Разница между ними разобрана в главе 1.4.

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

Интервал определяет, как часто снимают значение. Не меньше влияет промежуток, за который значения складывают.

§5Окно времени меняет смысл числа

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

Поэтому количество почти всегда пересчитывают в долю.

failed_requests = 5      # неуспешные запросы за 5 минут
all_requests = 1000      # все запросы за те же 5 минут

error_ratio = failed_requests / all_requests
print(f"{error_ratio:.1%}")

0.5%

error_ratio получает значение 0,005. Формат :.1% умножает число на 100 и выводит один знак после запятой.

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

§6Сложение количеств вместо усреднения процентов

У сервиса обычно несколько экземпляров. Каждый считает свои показатели, а на панели нужна общая картина, и здесь часто ошибаются в арифметике.

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

У этого примера есть и вторая сторона. Общая доля 0,5% выглядит спокойно, а на первой реплике сбоит каждый второй запрос. Общий показатель скрывает проблему одного экземпляра, поэтому на панели держат и общую долю, и разбивку по экземплярам.

Доля посчитана верно. Остаётся понять, много это или мало.

§7С чем сравнивать: базовый уровень

В 14:00 каталог обработал 300 запросов в минуту. Много это или мало, по одному числу не понять. Нужен базовый уровень — значение, которое считается обычным для этого времени и этого сервиса.

Нагрузка на пользовательские сервисы обычно повторяется по суткам и дням недели. Интернет-магазин днём получает больше запросов, чем ночью, а утро понедельника не похоже на вечер воскресенья. Поэтому текущее значение сравнивают с тем же часом вчера и с тем же днём неделю назад.

Базовый уровень нужен и для правил уведомлений. Порог «больше 500 запросов в минуту» в рабочий день будет срабатывать постоянно, а ночью пропустит настоящий всплеск. Чем точнее известно обычное поведение сервиса, тем точнее можно описать необычное.

Известно, как читать и сравнивать показатель. Следующий раздел отвечает на вопрос, какие показатели нужны сервису.

§8Что измерять у сервиса

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

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

Кроме самого API, у сервиса есть окружение. Очередь может расти при свободном процессоре, если обработчики ждут ответа внешней системы, поэтому одного сервера для мониторинга мало.

Первоисточник: Google SRE Book · The Four Golden Signals ↗

Все эти показатели сервис сообщает о себе изнутри. Есть и второй источник данных: проверка сервиса снаружи.

§9Проверка снаружи и показатели изнутри

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

Мониторинг чёрного ящика (black-box monitoring) — проверка поведения системы через её внешний интерфейс, без знания внутреннего устройства. Внешний агент отправляет запрос и проверяет ответ: пришёл ли он, какой у него код, сколько он занял.

Мониторинг белого ящика (white-box monitoring) — измерение показателей, которые система сообщает о себе изнутри: длина очереди, число занятых соединений, время отдельных этапов обработчика.

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

Внутренние показатели точнее указывают место проблемы. Внешняя проверка сообщит «страница открывается пять секунд», а внутренний показатель покажет, что четыре из пяти секунд запрос ждал свободное соединение с базой. Поэтому используют оба подхода: снаружи узнают, что пользователю плохо, изнутри выясняют, в каком месте.

Измерения из обоих источников собраны. Последний шаг мониторинга превращает их в действие.

§10От измерения к действию: правило и уведомление

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

Правило составляют по проблеме пользователя. Состояние отдельного ресурса для этого подходит хуже. «Доля ошибок /products выше 2% в течение пяти минут» означает, что пользователи получают сбои. «CPU выше 90%» говорит только о загрузке процессора, которая для вычислительной задачи может быть обычной.

В правиле из примера четыре части. Показатель — доля ответов HTTP 500 на /products. Порог — больше 2%. Длительность — условие выполняется 5 минут подряд. Получатель — дежурный инженер сервиса каталога.

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

§11Частые ошибки

§12Проверьте себя

§13Шпаргалка