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

Разумный подход начинается с простого вопроса: какую боль пользователя мы хотим предотвратить? Если интернет-магазин открывает каталог за десять секунд, клиент уходит, и никакие внутренние показатели процессора этого не объяснят. Поэтому метрики делят на уровни: то, что видит пользователь, то, что видит приложение, и то, что происходит с инфраструктурой. Каждый уровень требует своего набора показателей, и путать их — значит искать причину не там. Например, команда может месяцами оптимизировать запросы к базе, хотя реальная задержка возникает на уровне сетевого балансировщика. Чтобы не утонуть в сотнях параметров, стоит присмотреться к российскому решению для мониторинга приложений, которое помогает собрать ключевые сигналы в единую картину без лишнего шума.

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

Четыре золотых сигнала как отправная точка

Концепция четырёх золотых сигналов из книги Google SRE остаётся самым практичным стартовым набором для любого веб-приложения. Это задержка, трафик, ошибки и насыщение. Задержка показывает, сколько времени занимает обработка запроса, и её важно мерить не средним значением, а процентилями: среднее может быть прекрасным, пока десять процентов пользователей ждут по три секунды. Трафик — это количество запросов в единицу времени, которое помогает отличать всплеск нагрузки от деградации сервиса. Ошибки считают как долю неуспешных ответов, причём важно разделять явные сбои и бизнес-ошибки, например, когда пользователь ввёл неверный пароль.

Насыщение — самый недооценённый сигнал. Он показывает, насколько близко система подошла к своему пределу: заполненность очереди, загрузка процессора, количество свободных соединений с базой. Проблема в том, что у каждого компонента свой предел, и универсальной формулы нет. Для базы данных это может быть число активных сессий, для веб-сервера — занятая память, для брокера сообщений — глубина очереди. Поэтому золотые сигналы — это не догма, а рамка, внутри которой каждая команда определяет конкретные показатели под свой стек.

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

Метрики пользовательского опыта против технических показателей

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

Для веб-приложений полезно собирать хотя бы базовые показатели из области Real User Monitoring: Largest Contentful Paint, First Input Delay, Cumulative Layout Shift. Они показывают, насколько быстро появляется основной контент, как быстро страница реагирует на клик и не прыгает ли вёрстка во время загрузки. Для мобильных приложений аналогами будут время холодного старта, частота крашей и задержка отклика на касание. Эти метрики стоит держать на отдельном дашборде, потому что они отвечают на вопрос «каково пользователю», а не «что болит у сервера».

Связывать оба слоя помогает трассировка запросов. Когда пользовательская метрика проседает, инженер открывает трассу и видит, сколько времени запрос провёл в каждом сервисе, в очереди, в базе данных. Без этой связи команда гадает: то ли оптимизировать рендеринг на клиенте, то ли чинить медленный SQL-запрос. Поэтому при выборе метрик стоит сразу думать о том, как они будут коррелировать между собой. Одиночные показатели без контекста часто вводят в заблуждение.

Практический подход к отбору метрик

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

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

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

Чего стоит избегать при выборе показателей

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

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

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

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

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

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

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