Настройка мониторинга сервера: алерты CPU, RAM и диск

Хороший мониторинг сервера — это не набор красивых графиков, а предсказуемые алерты, которые помогают реагировать до инцидента. Для большинства инфраструктур достаточно базового набора метрик: CPU, оперативная память и дисковое пространство (плюс несколько уточнений вроде инодов и I/O). Дальше вы настраиваете правила с порогами и логикой срабатывания, подключаете уведомления и доводите всё до стабильной эксплуатации.

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

Архитектура мониторинга: метрики, сбор, алертинг и уведомления

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

Типовая схема выглядит так:

Агент или exporter на хосте собирает метрики (CPU, RAM, диски).
Сервер сбора (например, Prometheus) периодически запрашивает метрики или принимает их (Push).
Хранилище и дашборды (часто Grafana) показывают динамику.
Алертинг вычисляет правила и отправляет события в диспетчер уведомлений (например, Alertmanager) или напрямую в каналы связи.

Если у вас уже есть готовая платформа, например Zabbix, Nagios или cloud-мониторинг (CloudWatch, Azure Monitor), вы всё равно пройдёте те же этапы: определить метрики, выставить пороги, выбрать длительность подтверждения и настроить маршрутизацию алертов.

Ключевой момент: алерт — это не просто “если метрика выше X”. Почти всегда нужна логика устойчивости к шуму, иначе система быстро превращается в поток ложных сигналов.

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

Дальше важно не “всё подряд”, а набор метрик, которые реально коррелируют с проблемами на уровне приложения и ОС. Ниже — базовая опорная карта, от которой удобно отталкиваться.

CPU: что собирать для корректных алертов

Для CPU чаще всего используют:

Доля использования CPU (например, user/system/idle или общая загрузка).
Load average (load1/load5/load15) — полезно, но требует осторожности: он зависит от числа ядер и может меняться иначе, чем “процент CPU”.
Метрики по ожиданиям и задержкам: iowait (в процентах), либо косвенно через latency диска.
Для контейнеров: throttling и лимиты CPU (если используете cgroups/Kubernetes). Это помогает отличать реальную перегрузку от ограничения лимитом.

Если вы настраиваете алерты по CPU без учёта ожиданий I/O, можно получить ситуацию “CPU не высокий, но сервис тормозит”. Тогда проблема может быть не в вычислениях, а в диске или сети.

RAM: что собирать для алертов по памяти

Для оперативной памяти минимум нужен:

Доступная память или свободная память (mem_available или аналог).
Использование swap (swapused, swapin/out).
События и счётчики о проблемах памяти: OOM killer (для Linux), либо эквивалентные события для вашей ОС.

Особенно полезна идея “memory pressure”: когда доступная память падает, система начинает активно использовать swap, а затем возможны падения процессов. Поэтому алерт по RAM обычно эффективнее делать не только по “проценту заполнения”, но и по swap/событиям.

Диск: что собирать для алертов по диску

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

Использование файловой системы: freebytes/usedpercent по каждому важному mount point.
Проекция скорости заполнения: насколько быстро растёт used (или изменение свободного места за интервал).
Иное “скрытое” ограничение: иноды (inode usage). На некоторых системах иноды исчерпываются раньше места.
I/O показатели: latency чтения/записи и/или iowait, а также ошибки устройства.

Важно отдельно мониторить mount points, где живут данные приложения, логи, временные файлы. Алерт “диск почти полный” на /var/log полезен, но если у вас всё важное лежит в /data, он не заменяет мониторинг /data.

Алгоритм настройки алертов: порог, длительность, уровни и логика подавления

Чтобы алерты по CPU, RAM и диску работали в реальной эксплуатации, используйте простой алгоритм.

Определите, что именно должно считаться проблемой

Для CPU это может быть “постоянная нагрузка”, для RAM — “память уходит в swap” или “низкий запас доступной памяти”, для диска — “опасное заполнение” или “растущая деградация I/O”.

Выберите тип правила

Чаще всего используют:

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

Добавьте длительность подтверждения

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

делайте условия “выше порога дольше N минут” (для кратких пиков это отключит лишние сигналы);
для критических сценариев длительность можно уменьшать, для предупреждений — увеличивать.

Разведите уровни severity

Обычно полезны как минимум два уровня:

warning: “скоро будет проблема, проверьте и подготовьтесь”;
critical: “вмешательство нужно сейчас”.

Учтите ситуации, где алерт не должен срабатывать

Примеры подавления:

диск, который намеренно заполняется загрузкой (и вы знаете периодичность);
узлы на обслуживание;
хосты, где метрики временно отсутствуют (в зависимости от логики платформы это лучше трактовать как “невозможно оценить”, а не как “проблема”).

Снабдите алерт действием (runbook)

Алерт без подсказки “что делать” теряет ценность. В runbook достаточно указать: где смотреть детали, какие команды/дашборды открыть, и какие типовые действия предпринять.

Алерты по CPU: настраиваем пороги и избегаем ложных сигналов

Алерты по CPU часто настраивают слишком грубо: берут один процент “загрузка выше 90” и получают срабатывания на пиках. Правильный вариант зависит от характера нагрузки: бывает, что пиковая загрузка допустима, а проблема начинается только при длительном удержании.

CPU usage vs load average

CPU usage говорит, сколько вычислительных ресурсов занято. Load average показывает общее число задач в очереди и на исполнение. На многопроцессорных системах load может быть выше 1 просто из-за того, что ядер несколько, и этот показатель нужно интерпретировать аккуратно.

Практика настройки:

Для алертов “высокая загрузка” обычно выбирают CPU usage.
Load average используют как вспомогательную метрику, чтобы понять, что очередь растёт.

Пороговые уровни для CPU: ориентиры без догм

Если у вас нет исторической базы, стартуйте с ориентиров и обязательно откорректируйте после наблюдения:

warning: устойчиво высокая загрузка на горизонте нескольких минут;
critical: длительное удержание очень высокого процента загрузки или резкий переход в режим постоянной перегрузки.

Конкретные цифры зависят от количества CPU, типа задач и того, есть ли лимиты (например, в контейнерах). Поэтому корректнее задавать пороги как “уровни относительно нормального поведения” вашего сервиса, а не как универсальные значения.

Для контейнеров и cgroups отдельно учитывайте throttling

В Kubernetes и подобных средах CPU может быть ограничен. Тогда вы можете видеть ситуацию:

CPU usage не такой высокий, как ожидали,
но процесс постоянно простаивает из-за throttling.

Если ваша среда поддерживает метрики cgroup throttling, алерт по throttling обычно более точный, чем “просто процент CPU”.

Проверяйте контекст: CPU высокий или это I/O-ожидания

Когда CPU повышается, иногда причина — не вычисления, а ожидания и обработка. Наличие iowait и рост latency диска помогают понять взаимосвязь. Если вы видите рост iowait вместе с CPU, имеет смысл держать в голове, что “узкое место” часто в диске.

Типичная ошибка: настроить только CPU алерт и пропустить деградацию I/O. В результате команда начинает искать баги в коде, хотя проблема в файловой системе или устройстве.

Алерты по RAM: как поймать опасный сценарий до OOM

Алерты по RAM стоит настраивать так, чтобы они реагировали не на “процент использовано”, а на уменьшение доступного запаса и признаки, что система входит в режим деградации.

Метрика выбора: доступная память и swap

Для многих Linux-систем удобнее ориентироваться на доступную память (mem_available) вместо “просто используемой”. Доступная память отражает реальный запас под будущие аллокации, а “использование” может выглядеть пугающе из-за кэшей.

В связке с этим:

watch swap_used или активность swap-in/out;
watch события OOM killer (если у вас такие события собираются метриками).

Сигнал “память заканчивается” чаще выглядит как:

доступная память падает,
затем растёт swap,
потом возможно падение процессов или резкие задержки.

Warning и critical по памяти: логика с подтверждением

Хорошая модель:

warning срабатывает, когда доступная память заметно падает и сохраняет тренд;
critical срабатывает, когда swap включился/растёт или когда есть признаки приближения к OOM.

Почему важно “тренд” и длительность:

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

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

Важный нюанс: учёт кешей и поведения приложений

Разные приложения по-разному используют память. Если сервис держит большой кэш (например, файловый или свой буфер), “использование RAM” может быть стабильным и не означать проблему. Тогда ориентируйтесь на:

доступную память,
swap,
OOM и деградацию latency.

Типичная ошибка: выставить алерт “RAM > 90%” и годами получать сигналы от сервиса, который постоянно так работает. В итоге алерт перестаёт вызывать доверие.

Алерты по диску: пространство, иноды и скорость заполнения

Диск — один из самых “практичных” источников проблем. С ним часто всё просто: место заканчивается, и приложение перестаёт писать логи или новые данные. Но на практике есть несколько подводных камней: иноды, временные каталоги, а также деградация I/O до того, как место закончится.

Разделяйте mount points и критичные пути

Настройка алертов по диску должна быть по каждому важному файловому разделу:

корневой раздел,
раздел с данными приложения,
раздел с логами,
раздел под временные файлы (включая /tmp, если он на отдельном mount).

Если вы мониторите только один “общий диск”, вы пропустите ситуацию, когда свободное место закончилось именно на нужном mount point, а общий диск ещё “нормальный”.

Порог по свободному месту: два сценария

У диска два распространённых “сценария”:

“Порог по абсолютной свободе” (сколько осталось байт/ГБ).
“Порог по проценту заполнения” (сколько используется).

Оба подхода работают, но часто лучше сочетать:

процент помогает при разном размере разделов,
абсолютные байты важны, когда разделы разного масштаба, и ошибка “%” может привести к слишком позднему срабатыванию.

Если у вас есть статистика потребления, добавьте третий элемент:

алерт по скорости заполнения или проекциям на будущий момент.

Почему полезна скорость заполнения диска

Факт, что диск сейчас заполнен на 80%, не всегда означает срочность. Если заполнение растёт медленно, можно спокойно планировать. Если же рост быстрый, нужен алерт “скоро закончится место”.

Практическая логика:

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

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

Иноды: когда место ещё есть, а файловые операции уже падают

Исчерпание инодов происходит, когда файлов слишком много (мелкие файлы, временные артефакты, логи с ротацией и ошибками). Тогда приложение может начать получать ошибки записи, даже если байт “ещё хватает”.

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

директории с логами,
папки с кэшем,
временные рабочие директории.

I/O деградация: алерт не только про место

Иногда диск начинает работать хуже: растёт latency, растёт iowait, происходят таймауты. В этом случае алерт “used_percent” может ещё не сработать, потому что место заполнено не полностью.

Для диска полезны дополнительные условия:

высокий iowait длительно (как индикатор ожиданий),
рост latency операций (если метрики доступны),
ошибки устройства или filesystem error events.

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

Как сделать алерты по CPU, RAM и диску устойчивыми к шуму

Даже правильно выбранные пороги могут давать “шум”, если алерт срабатывает на каждом кратковременном отклонении. Устойчивость достигается не сложной теорией, а набором инженерных приёмов.

Подтверждение условий на интервале

Самый универсальный механизм:

правило должно выполняться непрерывно N минут;
N для warning чаще больше, чем для critical.

Если ваша платформа поддерживает for/until или аналог “держать условие”, используйте его. Это снижает долю ложных срабатываний на всплесках.

Алерт не должен “дребезжать”

Дребезг — когда метрика пересекает порог туда-сюда и алерт постоянно стартует/заканчивается. Чтобы этого избежать:

используйте разнесение порогов для входа и выхода (hysteresis), если поддерживается;
либо используйте длительность подтверждения и отдельно критерии “сброса” (для некоторых систем это настраивается логикой).

Группируйте алерты и ограничивайте дубликаты

Если у вас много узлов, критично:

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

При отсутствии дедупликации команда может получать десятки одинаковых уведомлений при одном событии. Диспетчер алертов обычно решает это через grouping и inhibition.

Включайте “информативность” в алерт

Один алерт должен содержать контекст:

какой хост и какой mount point (для диска),
текущее значение и порог,
интервал, за который условие было истинным.

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

Уведомления и маршрутизация: как довести алерты до действий

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

Разнесите каналы по severity

Обычно делают так:

warning идёт в канал для дежурных/инженеров (или в чат с уведомлениями);
critical уходит в пейджинг (если есть) или в более жёсткий канал.

Это не обязательное правило, но общий принцип — минимизировать шум и при этом не терять срочные события.

Настройте правила маршрутизации в диспетчере алертов

В диспетчере логично использовать:

routing по меткам (environment, service, team, severity);
grouping, чтобы не слать пять уведомлений подряд;
inhibit правила, чтобы если есть критический алерт, не дублировать предупреждения от той же причины (и наоборот, в некоторых случаях предупреждение может подавляться при критике).

Если у вас есть несколько систем алертинга, держите правила согласованными, чтобы критичность не “переезжала” между платформами.

Добавьте runbook внутрь алерта

Самый практичный формат:

ссылка на страницу с диагностикой;
3-5 пунктов “что посмотреть” и “что сделать”;
какие метрики проверять в первую очередь: CPU usage, mem_available, swap, свободное место, иноды, iowait.

Команда перестаёт изобретать план действий каждый раз заново.

Тестирование: как проверить, что алерты по CPU, RAM и диску работают

Без тестов вы не узнаете, сработают ли алерты в нужный момент и не будет ли “шторма” уведомлений. Тестирование можно сделать практичным и поэтапным.

Тест логикой условий (без вреда продакшену)

Сначала проверьте на тестовом стенде:

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

Если в системе есть возможность “simulate alert” или тестовые генераторы метрик, используйте их. Это быстро и безопасно.

Тест по нагрузке для CPU

Для CPU обычно делают контролируемый сценарий:

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

Важно не просто “получить сработку”, а проверить длительность: предупреждение должно появляться раньше, чем критическое, если вы так настроили.

Тест по памяти для RAM

Сценарий для RAM обычно осторожнее из-за риска OOM. Лучше проверить:

падение mem_available в ограниченных рамках,
включение swap в безопасной конфигурации,
реакцию на рост swap_used и отсутствие резких ложных критик.

Если вы можете тестировать в пределах staging или на отдельном узле, это предпочтительнее.

Тест диска: место, иноды и I/O

Диск тестируют как минимум в двух измерениях:

исчерпание места или достижение порога свободного объёма (в пределах контролируемой тестовой файловой системы);
рост числа файлов для инодов (на тестовом mount).

Отдельно проверьте I/O метрики: если вы добавляете алерт по latency или iowait, убедитесь, что он действительно появляется при деградации и не срабатывает “в пустоту”.

После теста проверьте качество алертов

Смотрите на три вещи:

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

Распространённые ошибки при настройке алертов по CPU, RAM и диску

Ниже список типичных проблем, из-за которых мониторинг сервера перестаёт работать как инструмент.

Слишком короткая длительность условия

Алерты срабатывают на пиках и кратких лагов. Результат: команда начинает игнорировать всё подряд.

Один порог для всех сервисов и всех узлов

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

Игнорирование swap и событий OOM для RAM

Ориентация только на “процент заполнения” часто даёт неверные выводы. Опасные сценарии обычно проявляются через swap и OOM.

Нет отдельного мониторинга mount points

Падает критичный раздел, а алерт смотрит на “средний диск”. Следствие — задержка реакции.

Мониторинг диска без инодов

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

Неправильная интерпретация CPU load average

Load average сам по себе без контекста числа ядер может вводить в заблуждение.

Алерт без runbook

Если в уведомлении нет “что делать прямо сейчас”, оно превращается в тикет без начала диагностики.

Нет маршрутизации и группировки

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

Итоговый чек-лист: настройка алертов, которые реально помогают

Если собрать всё в практический план, получится следующий “минимальный стандарт” для мониторинга сервера с алертами по CPU, RAM и диску.

Определите источники метрик и проверьте, что они реально обновляются

Агент/экспортер должен отдавать метрики, а сбор — не падать молча.

Для CPU настройте алерты по устойчивой загрузке и, при необходимости, throttling

Используйте подтверждение на интервале и не полагайтесь на один load average.

Для RAM настройте алерты по доступной памяти и по swap

Добавьте реакцию на OOM killer или аналогичные события, если они доступны.

Для диска настройте алерты по свободному месту и по росту заполнения

Отдельно включите мониторинг инодов и I/O деградации (если это значимо для ваших сервисов).

Разведите warning и critical

warning — раннее предупреждение, critical — сигнал к немедленным действиям.

Настройте устойчивость к шуму

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

В каждый алерт добавьте контекст и runbook

Хост, mount point (для диска), значение/порог и куда смотреть дальше.

Если сделать эти шаги и потом 1-2 раза пересмотреть пороги по реальным данным за период, алерты по CPU, RAM и диску обычно перестают быть “шумом” и начинают работать как система раннего предупреждения. Начните с базового набора правил, подключите уведомления, протестируйте на стенде и дальше улучшайте по факту эксплуатации.