Зачем метрики — не склад, а система оповещения
Мониторинг нужен не для того, чтобы собирать данные, а для того, чтобы вовремя заметить проблему. Четыре базовых сигнала — задержка, поток запросов, доля ошибок и насыщение ресурса — работают как сигнализация: они не объясняют причину, но сообщают, что пора действовать.
Эти сигналы не показывают, кому именно из пользователей плохо и почему. Они только сигнализируют о проблеме. Но без них вы узнаете о проблеме последним — когда сервис уже не отвечает, а пользователи начали массово жаловаться.
Задержка: почему среднее не работает
Задержка — это время между запросом и ответом. Кажется логичным использовать среднее значение: сложить все задержки и разделить на количество запросов. Но среднее обманчиво, потому что оно усредняет выбросы.
Представьте ситуацию: большинство запросов выполняются быстро, но небольшая часть — значительно медленнее. Среднее значение будет ближе к быстрым запросам, и проблема останется незамеченной. Выбросы — это не случайность, а закономерность: если часть запросов выполняется медленнее остальных, это сигнал о проблеме.
Вместо среднего используют перцентили:
- Медиана (p50) показывает типичную задержку: половина запросов быстрее, половина медленнее.
- Высокие перцентили (например, p90 или p99) показывают, как часто встречаются выбросы. Если p90 значительно выше p50, значит, у части пользователей задержка непредсказуемо высока.
Перцентили показывают не только среднюю скорость, но и стабильность работы. Если разница между p50 и p99 велика, значит, часть пользователей получает значительно худший опыт.
Поток запросов: почему количество не равно нагрузке
Поток запросов — это количество запросов в единицу времени. Сам по себе поток мало о чём говорит: важно, как он распределяется.
Если запросы приходят равномерно, сервис справляется. Если они приходят пачками — например, из-за одного клиента или балансировщика — это может вызвать перегрузку. Поток запросов нужно анализировать вместе с другими метриками: если он растёт вместе с задержкой или долей ошибок, это сигнал, что сервис не справляется.
Поток запросов не показывает, плохо ли сервису. Но он помогает понять, когда пора начинать разбираться.
Доля ошибок: почему журналы не дают полной картины
Доля ошибок — это процент запросов, которые завершились с ошибкой. Кажется, что можно просто посчитать количество ошибок в журналах и разделить на количество запросов. Но журналы не всегда полны:
- Если сервис упал, он может не успеть записать ошибку.
- Не все ошибки одинаково важны. Ошибка 404 (ресурс не найден) может быть нормальной, если пользователь запросил несуществующую страницу. Ошибка 500 (внутренняя ошибка сервера) — это всегда проблема.
Долю ошибок считают по ответам сервиса: сколько запросов вернули ошибку, делённое на общее количество запросов. Это даёт более точную картину, чем журналы, потому что учитывает все ответы, а не только те, которые успели записаться.
Насыщение ресурса: какой ресурс упирается первым
Насыщение — это когда ресурс (процессор, память, диск, сеть) загружен почти полностью. Но не все ресурсы одинаково важны. Обычно первым упирается тот, который используется интенсивнее всего:
- Процессор — если сервис выполняет много вычислений.
- Память — если сервис хранит много данных в памяти.
- Диск — если сервис много читает или пишет на диск.
- Сеть — если сервис обменивается большими объёмами данных.
Чтобы увидеть насыщение до отказа, смотрят на:
- Использование ресурса. Если ресурс загружен почти полностью, это ещё не проблема. Но если он загружен почти полностью постоянно, это сигнал, что скоро будет перегрузка.
- Очереди. Если запросы начинают накапливаться в очереди, это значит, что сервис не справляется с нагрузкой.
Насыщение ресурса — это предупреждение, что скоро будет отказ. Но оно не говорит, почему ресурс упирается.
Пределы четырёх сигналов
Четыре сигнала — задержка, поток запросов, доля ошибок и насыщение ресурса — показывают, что сервису плохо. Но они не показывают:
- Кому плохо? Если задержка растёт, это может быть проблема у одного пользователя или у всех.
- Почему плохо? Если доля ошибок растёт, это может быть баг в коде или атака.
- Что делать? Если ресурс упирается, это может быть нехватка мощности или неэффективный код.
Четыре сигнала — это индикаторы, а не диагноз. Они говорят, что пора разбираться, но не говорят, как.
Тупик: начинать с алертов на всё подряд
Первое, что обычно пробуют — настроить алерты на все четыре сигнала сразу. Кажется логичным: если что-то пойдёт не так, алерт сработает. Но это не работает, потому что:
- Алерты срабатывают слишком часто. Если настроить алерты на каждое небольшое отклонение, они будут срабатывать постоянно, и на них перестанут обращать внимание.
- Алерты не показывают причину. Если сработал алерт на задержку, это не значит, что проблема именно в задержке. Это может быть следствием насыщения ресурса или роста потока запросов.
- Алерты не помогают понять, что делать. Если алерт сработал, но не объясняет, почему, приходится разбираться с нуля.
Начинать с алертов на всё подряд — это как включать пожарную сигнализацию на каждый чих. Лучше сначала понять, какие метрики действительно важны, и настроить алерты только на них.
Что добавляется следующим
Четыре сигнала — это основа. Но чтобы понять, почему сервису плохо, нужны метрики по смыслу продукта. Например:
- Для API: количество запросов на пользователя, время выполнения конкретных эндпоинтов.
- Для базы данных: количество запросов на таблицу, время выполнения запросов.
- Для фронтенда: время загрузки страницы, количество ошибок на странице.
Эти метрики показывают, что именно ломается, а не просто что сервису плохо. Они помогают понять, почему растёт задержка или доля ошибок.
Позиция редакции
Четыре сигнала — задержка, поток запросов, доля ошибок и насыщение ресурса — это минимальный набор метрик, который показывает, что сервису плохо. Они не объясняют, почему плохо, и не говорят, что делать. Но они работают как индикаторы: если что-то из этого зашкаливает, пора разбираться.
Эти метрики — не панацея. Они не заменяют метрики по смыслу продукта и не дают полной картины. Но они — хорошая отправная точка, чтобы не пропустить проблему.
Позиция неверна, если:
- У вас нет доступа к метрикам на уровне сервиса (например, вы работаете с чужим API).
- Ваш сервис не обрабатывает запросы (например, это фоновая задача).
- Вы уже знаете, какие метрики важны для вашего продукта, и они не совпадают с четырьмя сигналами.
Как не утонуть в метриках
Четыре сигнала — это только начало. Следующий шаг — добавить метрики по смыслу продукта, которые показывают, почему растёт задержка или доля ошибок. Но даже с ними важно не собирать всё подряд.
Лучше задать себе вопрос: «Какую проблему я хочу решить?» — и собирать только те метрики, которые помогают на него ответить. Например, если вы знаете, что задержка растёт из-за одного эндпоинта, собирайте метрики именно по нему. Если вы знаете, что ошибки возникают из-за определённой таблицы в базе данных, собирайте метрики по ней.
Метрики — это не цель, а инструмент. Они помогают понять, что происходит с сервисом, но не заменяют здравый смысл и анализ.