Мониторинг серверов и инфраструктуры: какие метрики действительно важны

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

Что такое «важные метрики» на практике

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

Плохая метрика — это число ради числа. Классический пример: сам по себе процент загрузки CPU без контекста мало о чём говорит. Кратковременный пик до 90% при стабильной latency — это нормальная картина для конца рабочего дня. А вот 40% загрузки при одновременном росте времени ответа и появлении очередей — уже повод лезть в расследование. Контекст решает всё.

Базовый принцип: мониторим не сервер, а сервис

Это самая частая ошибка в инфраструктурном мониторинге. Администратор смотрит на CPU, RAM и свободное место на диске, а пользователь в этот момент жалуется на медленный сайт, потому что проблема сидит в базе данных, сети, очереди задач или внешнем API. Железо при этом может выглядеть почти идеально.

Правильный подход строится от сервиса, а не от хоста:

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

Например, для интернет-магазина критичнее не абстрактная «загрузка сервера», а вполне конкретные вещи: время ответа каталога, ошибки при оформлении заказа, доступность базы данных, задержки в очереди, потеря пакетов до CDN или upstream-провайдера. Если пользователь не может оформить заказ, то график CPU ему ничем не поможет.

Главные группы метрик, без которых мониторинг неполный

1. Доступность

Это самый очевидный слой, но даже здесь нельзя ограничиваться банальным пингом. Пинг показывает только то, что узел отвечает на ICMP. Сервер при этом может преспокойно пингнуться, но сайт уже лежит из-за упавшего веб-сервера, протухшего SSL-сертификата или недоступной базы данных.

Полезные показатели доступности:

• HTTP/HTTPS-доступность ключевых страниц;
• ответ на критичные URL: корзина, авторизация, API;
• TCP-connect до критичных портов;
• успешность DNS-резолва;
• доступность базы, брокера сообщений, объектного хранилища.

2. Задержка ответа

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

Ключевые метрики задержки:

• среднее время ответа;
• p95 и p99 latency;
• время до первого байта (TTFB);
• задержку ключевых бизнес-операций;
• время выполнения запросов к базе.

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

3. Ошибки

Ошибки — один из самых честных индикаторов проблемы. Если растёт доля 5xx, у вас уже инцидент, даже если график аптайма ещё зелёный.

Что отслеживать:

• долю HTTP 5xx;
• долю HTTP 4xx, если они означают сломанный сценарий, а не легитимные 404;
• ошибки приложения;
• ошибки БД;
• ошибки очередей и фоновых задач;
• ошибки TLS, DNS, авторизации, таймауты.

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

4. Нагрузка и насыщение ресурсов

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

• CPU;
• RAM;
• swap;
• disk usage;
• disk IOPS;
• disk latency;
• network throughput;
• network errors;
• queue length;
• open file descriptors;
• процессорное steal time в виртуализации.

Загрузка сама по себе ничего не означает, если не смотреть на насыщение. CPU на 80% при стабильной latency — это нормально, процессор просто занят работой. CPU на 30%, но очередь растёт, а запросы тормозят — значит, узкое место в другом: диск, сеть, блокировки или база данных. Поэтому всегда нужно смотреть связку «нагрузка + насыщение + latency», а не отдельные проценты.

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

На уровне сервиса

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

• успешность health-check;
• время ответа основных endpoint’ов;
• доля ошибок;
• количество активных сессий;
• скорость обработки очереди;
• объём бизнес-операций за минуту;
• число таймаутов.

На уровне приложения

Здесь уже видна внутренняя механика. Полезно смотреть:

• время обработки запросов по типам;
• число запросов к базе на один пользовательский запрос;
• размер пулов соединений;
• число retries;
• длину внутренних очередей;
• потребление памяти процессом;
• число фоновых задач в ожидании;
• скорость GC, если это JVM/Go/managed runtime с соответствующей статистикой.

На уровне сервера

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

• load average;
• CPU usage по режимам user/system/iowait;
• memory available;
• swap in/out;
• disk free;
• inode usage;
• disk read/write latency;
• network drops;
• retransmits;
• температура, если есть доступ к аппаратным датчикам;
• SMART-атрибуты для дисков.

На уровне сети

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

• RTT до ключевых точек;
• packet loss;
• retransmits;
• jitter;
• BGP-состояния, если есть своя маршрутизация;
• доступность DNS;
• latency между зонами;
• ошибки интерфейсов;
• saturation линка.

На уровне хранилища

Для многих систем именно диск становится узким местом раньше CPU. Особенно это заметно на базах данных и объектных хранилищах. Критичные метрики:

• IOPS;
• latency чтения и записи;
• throughput;
• queue depth;
• процент заполнения;
• время ответа массивов/томов;
• ошибки контроллера;
• репликационный лаг;
• состояние RAID/CEPH/RAIDZ/других систем хранения.

Таблица: какие метрики смотреть в первую очередь

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

Что часто мониторят зря

Не все популярные метрики одинаково полезны. Часть из них превратилась в обязательный ритуал, но на деле лишь отвлекает внимание.

1. CPU без контекста

Если просто смотреть на процент CPU, можно пропустить проблему. Лучше дополнять картину такими показателями:

• load average;
• iowait;
• run queue;
• throttling в контейнерах;
• latency сервиса.

2. Свободная RAM без понимания cache

Linux стремится использовать память под кэш страниц, поэтому низкий «free» — это не всегда проблема. Гораздо важнее:

• available memory;
• swap activity;
• OOM-killer events;
• рост RSS процесса;
• давление по памяти в контейнерах.

3. Абсолютный размер диска

«Осталось 20 ГБ» — это не ответ. Важно знать, как быстро растёт использование, сколько дней осталось до заполнения, что именно съедает место, есть ли логическая очистка и не переполнится ли inode-таблица. Иначе можно оказаться в ситуации, когда места ещё много, а файлы создавать уже нельзя из-за исчерпанных inode.

4. Пинг как индикатор доступности

Пинг полезен как вспомогательная проверка, но не как основной сигнал. Пользователь не пингует сервер — он открывает сайт, авторизуется, платит, читает данные. Поэтому пинг должен лишь дополнять проверки HTTP, DNS, БД и бизнес-операций.

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

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

Шаг 1. Определите критичные пользовательские действия

Спросите себя: что пользователь делает чаще всего? без чего сервис считается недоступным? какие операции приносят деньги или влияют на SLA? где самый дорогой сбой? Для интернет-магазина это оформление заказа. Для API — авторизация и ключевые методы. Для SaaS — логин, загрузка данных, сохранение настроек.

Шаг 2. Опишите цепочку зависимости

Например: пользователь → DNS → CDN → веб-сервер → приложение → БД → кэш → внешние API. Мониторить нужно не только конечную страницу, но и узкие места по цепочке, потому что сбой на любом звене ломает весь пользовательский путь.

Шаг 3. Разделите метрики на уровни

• пользовательские;
• сервисные;
• системные;
• инфраструктурные;
• внешние зависимости.

Шаг 4. Определите норму и пороги

Порог без нормы бесполезен. Например: latency больше 500 мс в течение 5 минут; ошибки 5xx выше 1%; заполнение диска выше 80%; рост очереди более чем на 30% за 10 минут; репликационный лаг выше допустимого окна. Пороги должны отталкиваться от реальных ожиданий пользователя и бизнеса, а не от абстрактных «красивых» значений.

Шаг 5. Добавьте алерты только на то, что требует действия

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

Практический набор метрик для типового сервера

Если нужен минимальный, но рабочий набор, начинайте с этого:

• доступность ключевого сервиса;
• время ответа основных запросов;
• доля ошибок 4xx/5xx;
• CPU user/system/iowait;
• available memory;
• swap activity;
• disk usage;
• disk latency;
• network traffic;
• packet loss / retransmits;
• состояние процесса приложения;
• логические ошибки приложения;
• состояние БД и очередей.

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

Типовые ошибки в мониторинге

Слишком много алертов

Когда всё красное каждый день, команда перестаёт реагировать. В итоге реальный инцидент тонет в шуме. Лучше иметь десять точных алертов, чем двести «на всякий случай».

Нет привязки к сервису

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

Нет истории и трендов

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

Нет разделения на симптомы и причину

Симптом: «сайт медленный». Причина: «закончились соединения к БД». Мониторинг должен помогать пройти этот путь быстро. Если между симптомом и причиной приходится долго копаться, система мониторинга работает плохо.

Слепая вера в проценты

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

Чек-лист: хороший мониторинг сервера

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

Когда нужны расширенные метрики

Базового набора хватает не всегда. Углубляться стоит, если:

• высокая нагрузка и частые пики;
• микросервисная архитектура;
• несколько дата-центров или облаков;
• сложная БД с репликацией;
• использование CDN, очередей, брокеров;
• контейнеризация и оркестрация;
• строгие SLA/SLO;
• дорогой простой, где минуты стоят денег.

Тогда уже полезны распределённая трассировка, метрики по каждому микросервису, методики RED/USE, синтетические проверки, бизнес-метрики и корреляция логов, метрик и трассировок. Это позволяет разбирать сложные сценарии, где проблема может плавать между сервисами и дата-центрами.

Что считать «достаточным» мониторингом

Достаточный мониторинг — это не тот, где собрано больше всего графиков. Это тот, где авария замечается рано, причина локализуется быстро, команда не тонет в шуме, метрики помогают принимать решения и видно, улучшается система или деградирует. Если после инцидента приходится гадать, какой узел виноват и когда началась проблема, значит, мониторинг пока слабый. Если же по графикам можно восстановить картину за 5–10 минут, система уже контролируется нормально.

Вывод

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

FAQ

Какие метрики серверов самые важные в первую очередь?

Доступность сервиса, latency, доля ошибок, CPU, память, диск, сеть, состояние БД и очередей. Это минимальный костяк, который закрывает большинство реальных инцидентов.

Почему CPU не всегда показывает проблему?

Потому что узкое место может быть в диске, сети, блокировках, базе данных или очередях. CPU может быть низким, а сервис уже тормозить из-за ожидания I/O или исчерпанных соединений.

Что важнее: аптайм или latency?

Для пользователя часто важнее latency. Сервис может быть формально доступен, но настолько медленным, что это воспринимается как сбой. Поэтому задержку нужно отслеживать не менее тщательно, чем доступность.

Нужно ли мониторить пинг?

Да, но только как вспомогательную метрику. Он не заменяет проверку HTTP, DNS, БД и бизнес-операций. Пинг лишь показывает, что узел отвечает на ICMP, и не более того.

Как не перегрузить команду алертами?

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