Метрики мониторинга инфраструктуры: что реально смотреть

Зачем выбирать метрики, а не собирать все подряд

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

Вторая проблема - оповещения. Когда алерты срабатывают по любому поводу, им быстро перестают доверять. Ложные тревоги съедают время, а настоящие инциденты тонут в шуме. Итог один: бизнес видит простои, пользователи видят «все тормозит».

Полезные метрики мониторинга инфраструктуры - те, которые помогают принимать решения и быстро восстанавливать сервис. Обычно они отвечают на простые вопросы:

• Влияет ли показатель на пользователя прямо сейчас (скорость, доступность, ошибки)?
• Можно ли по нему заранее заметить деградацию, а не только факт падения?
• Понятно ли, кто и что должен сделать, если метрика ухудшилась?
• Есть ли у метрики базовый уровень, чтобы отличать норму от проблемы?

Пример: в стойке с серверами (например, класса GSE S200) можно собрать десятки аппаратных датчиков. Но если у вас нет метрик задержек диска, загрузки CPU и ошибок сети, вы не поймете, почему бухгалтерия жалуется на медленную 1С, хотя «железо живое».

Есть и важное различие по смыслу. Мониторинг отвечает на вопрос «что сломалось и когда». Наблюдаемость шире: она помогает понять «почему сломалось», добавляя к метрикам логи и трассировки запросов.

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

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

Рабочий подход: отделяйте сигналы (симптомы) от причин. Симптомы стоит алертить, потому что они отражают проблему «здесь и сейчас». Причины полезнее держать под рукой для расследования, но не будить по ним ночью.

Сигналы, которые почти всегда работают

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

• Задержка (время ответа сервиса, задержка диска, сетевой RTT)
• Трафик (входящий и исходящий, запросы в секунду)
• Ошибки (5xx, timeouts, сбои задач)
• Насыщение (CPU, память, очередь диска, заполнение канала)

Дальше полезно разложить сервис по уровням: инфраструктура (серверы, сеть, СХД), платформа (БД, очереди, виртуализация) и само приложение.

Если пользователи жалуются на «медленно», алерт лучше ставить на рост задержки и ошибок на уровне сервиса, а CPU, iowait и задержку СХД использовать как подсказки, где искать причину.

Серверы: базовый набор метрик без лишнего

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

По CPU смотрите не только среднюю загрузку, но и пики. Короткие всплески до 100% могут быть нормой. А вот постоянные пики вместе с ростом load average часто означают, что задач больше, чем CPU успевает обработать, или процессы ждут диск. Здоровая картина - когда load не растет долго и не превышает число ядер на постоянной основе.

По памяти важно отличать реальную нехватку от кеша. Высокий used сам по себе не страшен, если растет cache и система не уходит в swap. Плохие признаки - стабильно высокий swap used, заметный swap in/out и деградация отклика.

Диск - частая причина состояния «все работает, но медленно». Смотрите заполнение, IOPS и главное - latency и очередь. Если задержки растут при умеренных IOPS, это сигнал про перегруз, проблемы в СХД или на уровне файловой системы.

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

Аптайм и факты reboot - не KPI, но важный контекст. Резкий рост ошибок сразу после перезагрузки часто указывает на неверную конфигурацию или проблемы с автозапуском.

В алертах по серверам обычно достаточно минимума:

• высокий swap и активный swap in/out
• рост disk latency или очереди выше привычного уровня
• заполнение диска с прогнозом «закончится скоро»
• частые перезапуски критичных процессов
• load average, который устойчиво растет вместе с деградацией сервиса

Сеть: что измерять, чтобы ловить деградации

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

Начните с интерфейсов: link up/down, потери пакетов, счетчики ошибок. Если линк «ап», это еще не значит, что по нему можно нормально работать. Потери 0,5-1% уже заметны для голоса, VPN и удаленных рабочих столов.

Задержка и джиттер иногда важнее пропускной способности. Канал может быть загружен на 30%, но при очередях на порту джиттер вырастет, и пользователи скажут, что «все тормозит». Поэтому полезно измерять RTT до ключевых точек (шлюз, ядро сети, внешний провайдер) и стабильность задержки.

По загрузке каналов смотрите вход/выход, пики и 95-й перцентиль. Среднее значение обманывает: перегрузка бывает короткими всплесками. 95-й перцентиль показывает, хватает ли емкости «почти всегда».

При разборе сетевых деградаций первыми обычно проверяют ошибки и потери на интерфейсе (errors, CRC), drops и queue drops, рост retransmits у TCP на пограничных узлах, а также асимметрию трафика (вход нормальный, выход забит). Collisions сегодня редки, но при проблемах с дуплексом их тоже стоит учитывать.

Не забывайте про DNS и DHCP. Пользователь воспринимает проблемы здесь как «интернет не работает», хотя сеть жива: DNS отвечает медленно, DHCP раздает адреса с задержкой, или заканчивается пул. Хороший ранний признак - рост времени ответа DNS и доли неудачных запросов.

СХД и хранилища: емкость, задержки и здоровье

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

Минимальный набор, который реально помогает

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

Дальше - производительность. Для пользователя «все медленно» чаще означает рост latency, а не падение IOPS. Поэтому смотрите задержки чтения и записи и длину очереди: когда очередь растет, сервисы начинают ждать диск даже при умеренной нагрузке.

Практичный минимум по хранилищам:

• емкость пула или томов: занято, свободно, тренд и прогноз до заполнения
• latency read/write и средняя очередь (queue depth)
• IOPS и пропускная способность, но только вместе с latency
• состояние массива: degraded, rebuild, hot spare, ошибки дисков
• тонкое выделение (thin) и риск overcommit по пулам и томам

Бэкапы и «скрытые» деградации

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

Типичный случай: ночной бэкап стал идти дольше, пересекся с утренним пиком, и latency на записи выросла в 2-3 раза. Пользователи жалуются на «тормоза», а CPU и сеть выглядят здоровыми. Алерт по росту latency и увеличению длительности бэкапа даст сигнал раньше, чем начнутся массовые заявки.

Сервисы и приложения: метрики, которые видит пользователь

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

Доступность лучше мерить внешней проверкой (синтетическим запросом), а не тем, что процесс жив. Процесс может работать, но отдавать 500 или зависать на запросах.

По задержке смотрите p50, p95 и p99. Среднее часто обманывает: большая часть запросов может быть быстрой, а «длинный хвост» создает жалобы и очереди в поддержке.

Ошибки измеряйте отдельно по 4xx и 5xx, плюс таймауты и ретраи. Иногда число 5xx низкое, но таймаутов много, и пользователю все равно плохо.

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

Чтобы зависимости не прятались, добавьте отдельные метрики по БД, очередям и внешним API: время ответа, процент ошибок, число ожиданий. Например, сервис на серверах (вроде S200 в корпоративном контуре) может «тормозить» из-за медленных запросов к БД. Это сразу проявится в p95 и росте таймаутов, даже если CPU почти пустой.

Платформа: БД, очереди, кэш, виртуализация и сертификаты

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

База данных, очереди и кэш

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

С очередями и брокерами смотрите не только глубину очереди, но и lag (отставание) и скорость обработки. Очередь может быть небольшой, но потребитель обрабатывает сообщения медленно, и задержка растет.

Кэш тоже дает быстрые подсказки: hit rate, evictions, latency и размер. Если hit rate падает, а evictions растут, пользователи видят «тормоза», хотя серверы по CPU могут быть в норме.

Виртуализация, контейнеры и сертификаты

Для контейнеров и виртуализации полезно следить за рестартами и ограничениями по ресурсам. Частая история: контейнеры начинают throttling по CPU или ловят memory pressure, а в графиках «железа» все выглядит спокойно.

Чтобы не пропускать неожиданные простои, держите минимум таких проверок:

• срок действия TLS-сертификатов (лучше заранее, за недели)
• рост ошибок TLS/handshake
• число рестартов контейнеров за период
• lag очередей и время обработки
• блокировки в БД и долю медленных запросов

Пример: в инфраструктуре на стойках с серверами уровня GSE S200 сервис резко стал медленным. Оказалось, проблема была не в CPU, а в блокировках в БД и падении hit rate в кэше после изменения лимитов памяти в контейнерах.

Логи и трассировки: что добавить к метрикам

Метрики хорошо показывают, что ресурс «жив». Но они не всегда объясняют, почему пользователю стало медленно. Типичный случай: CPU и память в норме, сеть без потерь, диски «зеленые», а веб-страница открывается 15 секунд.

Минимум логов, который реально помогает

Начните с логов, которые отвечают на вопросы «что именно сломалось» и «в какой момент». Полезнее всего те записи, которые можно связать с запросом и временем.

Минимальный набор обычно включает:

• ошибки и исключения с кодом и коротким сообщением
• таймауты (к БД, внешним API, очередям)
• старты и остановки сервисов, перезапуски, падения
• длительные операции (например, запросы дольше 1-2 секунд)
• изменения конфигурации и деплои (кто и когда)

Чтобы метрики и логи сходились в одном инциденте, нужна простая корреляция: одинаковая временная зона, точные метки времени и общий идентификатор (request_id, trace_id). Тогда вы видите: в 10:14 выросла задержка, а в логах в 10:14 начались таймауты к конкретной базе.

Когда трассировки дают максимум пользы

Трассировки особенно полезны в микросервисах и в цепочках «сервис -> БД -> внешний провайдер», где важно понять, на каком шаге теряется время. Они показывают путь запроса по компонентам и помогают отличить «медленно из-за кода» от «медленно из-за зависимостей».

Как настроить оповещения шаг за шагом

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

Удобно собрать настройку в несколько шагов:

• Составьте карту сервисов: что от чего зависит и что критично (платежи, почта, записи в ЕМИАС, портал для сотрудников).
• Выберите 1-2 SLI на сервис и посмотрите историю за 2-4 недели: задержка, доля ошибок, доступность, время ответа. Пороги берите от реальных данных, а не от «круглых чисел».
• Разделите алерты на два типа: page (будит дежурного, нужна реакция сейчас) и ticket (можно решить в рабочее время).
• Добавьте проверку «влияния на пользователя»: алерт по CPU не page, пока нет роста ошибок или времени ответа.
• Настройте эскалации, дежурства и «окно тишины» для плановых работ, чтобы не ловить ложные срабатывания.

Пример: на сервере растет нагрузка, но пользователи не жалуются. В этом случае лучше завести ticket с трендом и задачей на разбор, а page оставить только для сочетания сигналов (ошибки 5xx + рост p95 задержки).

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

Как уменьшить шум и не пропускать реальные проблемы

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

Быстрый эффект обычно дают такие правила:

• Дедупликация и группировка: объединяйте алерты по сервису, хосту и типу сбоя.
• Задержка перед алертом: срабатывание только если состояние держится N минут или N проверок подряд.
• Разделение уровней: предупреждение для тренда и критика для простоя.
• Фильтры по времени и событиям: отдельные правила на окна бэкапа, регламентные работы и ночные часы.
• Динамические пороги там, где статические вредят: например, для сетевого трафика или CPU в сервисах с выраженными пиками.

Небольшой пример: каждую ночь идет резервное копирование, диск загружается на 95%, и вы получаете шквал алертов по I/O. Решение: оставить предупреждение при росте задержек, но критический алерт включать только если высокая задержка держится дольше, скажем, 10 минут вне окна бэкапа. Так вы не теряете реальные проблемы и перестаете реагировать на ожидаемые процессы.

Полезная проверка: если алерт не подсказывает, что делать дальше (куда смотреть и насколько срочно), он почти всегда лишний.

Типовые ошибки в метриках и алертах

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

Ошибка номер один - алерт только по CPU, например «80% и выше». Высокая загрузка сама по себе не всегда беда. Важнее понять, выросли ли задержки, появилась ли очередь задач, начались ли таймауты. Бывает и наоборот: CPU нормальный, а сервис тормозит из-за ожидания диска или сети.

Вторая ошибка - следить за текущей емкостью, но игнорировать тренды. Место на СХД заканчивается не внезапно. «Внезапно» это когда никто не смотрел скорость роста и не настроил предупреждение заранее.

Третья ошибка - слишком общие проверки. Пинг есть, порт открыт, а приложение внутри зависло или отдает 500. В итоге мониторинг говорит «все зелено», а пользователи звонят.

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

Простой пример: ночью приходит алерт «CPU 85%». Дежурный перезапускает сервис, нагрузка падает, но через час все повторяется. Если бы рядом были метрики времени ответа и длины очереди, стало бы видно, что причина в медленном хранилище, а не в процессоре.

Чтобы исправить это без усложнений, держите базовые правила:

• Привязывайте алерты к влиянию на сервис: latency, ошибки, очередь, таймауты.
• Добавляйте ранние предупреждения по емкости и скорости роста, а не только «осталось 5%».
• Проверяйте не «хост жив», а «сценарий работает» (запрос, транзакция, ключевая операция).
• Назначайте владельца и понятный план действий прямо в описании алерта.
• После инцидента корректируйте пороги и условия, чтобы он не повторился.

Короткий чеклист: что проверить за 30 минут

За полчаса можно понять, мониторинг помогает или просто «рисует графики». Смысл этого чеклиста - убедиться, что закрыты базовые риски по железу и сервисам, а оповещения не превращаются в постоянный фон.

Проверьте пять вещей:

• Покрытие: есть ли метрики хотя бы по одному ключевому показателю для серверов (CPU, память, диск), сети (потери, задержка), СХД (задержка и заполнение) и 3-5 критичных сервисов (доступность и время ответа).
• Главные алерты: выделены ли 5-10 сигналов, которые точно требуют реакции (например, сервис недоступен, диск почти заполнен, резко выросла задержка СХД, высокий процент ошибок).
• Емкость с запасом: настроены ли оповещения «заранее», а не «когда уже все упало». Полезнее алерт «через 7 дней закончится место», чем «диск 100%».
• Проверка на реальности: запускали ли вы тестовый инцидент и увидели ли цепочку от алерта до действий. Простой вариант - временно остановить тестовый сервис или занять часть диска на некритичном сервере.
• Инструкции: есть ли короткая памятка к каждому алерту - где подтвердить проблему, что сделать первым шагом, когда эскалировать.

Если хотя бы два пункта проваливаются, на неделю сократите набор метрик и алертов до понятного минимума. Так мониторинг быстрее станет рабочим инструментом, а не источником шума.

Пример из практики: «все работает, но очень медленно»

Симптом простой: пользователи жалуются, что сервис «думает» по 5-10 секунд, но не падает. На дашборде все зеленое: ошибок почти нет, CPU на серверах держится на уровне 30-40%, память без свопа. Кажется, что проблема не в железе.

Первый сигнал дают метрики, ближе всего стоящие к пользователю: p95 времени ответа растет, а p50 почти не меняется. Это часто значит, что часть запросов упирается в редкую, но тяжелую задержку. Ошибок мало, потому что таймауты еще не наступили.

Дальше помогает короткая проверка по цепочке:

• сеть: растет RTT до БД или СХД, появляются микропотери пакетов
• СХД: увеличивается latency чтения и записи, очередь диска становится длиннее
• БД: растет p95 времени запросов, увеличивается число блокировок
• приложение: упирается в лимит пула соединений, растет длина очереди запросов

В одном таком случае причина была в СХД: раз в несколько минут latency подскакивала в 5-7 раз, и редкие запросы выпадали в «длинный хвост». Алерты не сработали, потому что пороги были по среднему значению и с длинным окном (например, «среднее за 10 минут»), которое сглаживало пики.

Что поменяли: пороги перевели на p95 (или p99) по latency и добавили один новый сигнал - долю запросов медленнее заданного SLA. Такой алерт срабатывает раньше и почти не шумит.

Следующие шаги: как внедрить и поддерживать мониторинг

Лучше внедрить понятный набор метрик за 1-2 недели и реально на него опираться, чем месяцами собирать все подряд и не доверять данным.

Практичный план:

• Выберите метрики первого уровня для каждой зоны (серверы, сеть, СХД, сервисы) и зафиксируйте, какие пороги считаются проблемой.
• Соберите простые дашборды по ролям: администратору важны CPU/память/диски, сетевику - потери и задержки, владельцу сервиса - время ответа и ошибки.
• Проведите ревизию алертов: уберите дубли, отключите оповещения без действий, оставьте только те, на которые команда действительно реагирует.
• Запланируйте тест отказа: выключите один узел или ограничьте канал и проверьте, кто получает алерт, что делает и сколько времени уходит до восстановления.
• Введите регулярность: раз в месяц короткий разбор инцидентов и корректировка порогов.

Ориентир простой: если алерт пришел, у дежурного должен быть понятный следующий шаг.

Если нужна опора по «железу» и внедрению, иногда помогает внешний взгляд на текущую инфраструктуру. У GSE.kz (gse.kz) как у производителя серверов S200 и системного интегратора есть практика подбора платформы под нагрузку и сопровождения с круглосуточной поддержкой, что удобно, когда мониторинг нужно не только настроить, но и поддерживать в рабочем состоянии.