Какие метрики сервера смотреть каждый день, а какие раз в месяц

MAATRIX

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

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

Логика проста: частота проверки метрики должна соответствовать скорости, с которой она может измениться и потребовать вашего вмешательства. Загрузка CPU может подскочить с 20% до 95% за одну минуту из-за зависшего процесса — это метрика для ежедневной, а лучше вообще для алертинга в реальном времени. А вот соотношение стоимости инфраструктуры к реально обрабатываемой нагрузке меняется медленно, за месяцы — проверять его каждый день бессмысленно, вы просто не увидите разницы между вчера и сегодня.

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

Решение — разделить метрики на три группы по темпу изменения и завести под каждую свою частоту проверки. Дальше — конкретный список для каждой группы.

Ежедневно: что может измениться быстро и потребовать реакции сейчас

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

Загрузка CPU и памяти относительно типичного уровня. Важна не абсолютная цифра, а отклонение от вашей нормы. Если сервер обычно работает на 30-40% CPU, а сегодня утром показывает 85% — это сигнал разобраться, даже если формально «ничего не упало». Быстрый способ посмотреть текущее состояние:

# Загрузка CPU и памяти прямо сейчас
top -bn1 | head -20

# Более читаемо, с историей load average
uptime
cat /proc/loadavg

Load average стоит сравнивать с числом ядер: значение 4.0 на сервере с 4 ядрами — это уже полная загрузка, а на сервере с 16 ядрами — просто фоновая работа. Если не уверены, какой у вас типичный уровень — заведите привычку смотреть на это число неделю подряд в спокойное время, чтобы знать свою норму. Точной цифры «нормальной нагрузки» для всех серверов не существует — она зависит от профиля вашей нагрузки, и ориентироваться нужно на собственную историю, а не на чужие бенчмарки.

Свободное место на диске — особенно если известна тенденция к быстрому заполнению. Диск, который заполняется на 2-3% в день из-за логов или временных файлов, может дойти до 100% за две недели, и тогда откажут запись в базу данных, ротация логов и иногда сама возможность зайти по SSH. Проверка:

df -h

Если видите раздел, растущий быстрее обычного, — не ждите ежемесячного разбора, разбирайтесь сразу. Про то, что происходит при полном заполнении диска, мы подробно разбирали в статье что отвалилось первым, когда диск заполнился на 100%.

Состояние критичных сервисов — запущены или остановлены. Это самая простая и самая важная ежедневная проверка: работает ли то, ради чего сервер вообще существует. Для systemd:

systemctl list-units --type=service --state=failed
systemctl status nginx postgresql redis

Для Docker-окружений:

docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'

Сервис, упавший ночью и не поднявшийся автоматически, — это худший вариант «медленной» проблемы: она уже произошла, просто вы о ней не знаете. Если у сервисов настроен Restart=on-failure, обязательно проверяйте не только «работает ли сейчас», но и число перезапусков (systemctl show <service> -p NRestarts) — сервис может формально работать, упав и подняв себя пять раз за ночь.

Количество ошибок за последние сутки относительно обычного уровня. Здесь важна не абсолютная величина («5 ошибок» ничего не говорит), а сравнение с фоном. Быстрый способ прикинуть динамику по логам:

# Ошибки за последние 24 часа
journalctl --since "24 hours ago" -p err | wc -l

# То же самое для конкретного юнита
journalctl -u nginx --since "24 hours ago" -p warning | wc -l

Если вчера было 3 ошибки, а сегодня 300 — это сигнал даже без единого «упавшего» сервиса. Как читать логи и находить в них первопричину сбоя, мы разбирали отдельно — см. как читать логи и находить причину сбоя.

Еженедельно: метрики с более медленной динамикой

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

Общий тренд роста использования ресурсов за неделю. Здесь важна не точка, а линия: растёт ли использование диска, памяти, CPU неделя к неделе, и с какой скоростью. Если у вас настроен Prometheus с Grafana или Netdata — смотрите недельные графики напрямую. Без готового дашборда можно снять срез вручную и сравнить с прошлой неделей:

# Снимок использования диска с датой — удобно копить в файл раз в неделю
echo "$(date +%F): $(df -h / | tail -1 | awk '{print $5}')" >> /var/log/disk-weekly.log

Даже такой примитивный лог за 4-8 недель покажет, растёт ли занятое место линейно, скачками или вообще стабильно — и это уже основание для решений, которые не имеет смысла принимать по одной ежедневной точке.

Статистика по объёму трафика и нагрузки за неделю. Задача — заметить медленное смещение паттерна использования: например, постепенный рост числа запросов к API, смену пикового времени нагрузки или рост среднего размера ответа. Для веб-сервера базовый разбор логов доступа:

# Число запросов по дням за последнюю неделю (nginx)
awk '{print $4}' /var/log/nginx/access.log | cut -d: -f1 | sort | uniq -c

Если у вас Graylog или Grafana Loki — там это делается сводным запросом за 7 дней вместо ручного парсинга; про выбор между ними есть отдельный разбор — Graylog или Grafana Loki: что выгоднее и когда. Смысл именно в недельном окне: суточные колебания трафика (будни/выходные, дневной/ночной цикл) — это нормальный шум, а вот смещение недельного среднего — уже тренд, который стоит учитывать при планировании.

Ежемесячно: стратегические и плановые показатели

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

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

Обзор стоимости инфраструктуры относительно объёма реально обрабатываемой нагрузки. Раз в месяц стоит закрыть глаза на CPU и диск и посмотреть на цифры по-другому: сколько вы платите за серверы и сколько реального трафика/пользователей/запросов это обслуживает. Если нагрузка стоит на месте, а счёт растёт (докупили ещё один VPS «на всякий случай» и забыли про него), — это сигнал провести ревизию. Простая табличка для ежемесячного разбора:

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

Актуальность версий ПО относительно доступных обновлений безопасности. Это классический пример метрики, которая не «горит» сегодня, но накапливает риск месяц за месяцем. Проверка раз в месяц:

# Debian/Ubuntu — список пакетов с доступными обновлениями
apt list --upgradable 2>/dev/null

# Отдельно проверка на обновления безопасности
apt-get -s dist-upgrade | grep -i security

Для CentOS/AlmaLinux — dnf check-update и dnf updateinfo list security. Проверять это ежедневно избыточно: патчи безопасности выходят не каждый день, а вот пропустить месяц-два и накопить десяток непроставленных обновлений, среди которых окажется критичный CVE, — уже настоящий риск.

Как организовать регулярность так, чтобы не забывать

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

Практический совет — не полагаться на память, а завести явное календарное напоминание:

• Еженедельная проверка — повторяющееся событие в календаре на понедельник утро, с чек-листом из двух пунктов (тренд ресурсов, статистика трафика за неделю).
• Ежемесячная проверка — повторяющееся событие в календаре на 1-е число месяца, с чек-листом из трёх пунктов (долгосрочный тренд, стоимость vs нагрузка, обновления безопасности).

Если у вас несколько серверов и вы уже используете cron для других задач, можно автоматизировать хотя бы сбор данных — например, cron-задачу, которая раз в неделю пишет снимок df -h и free -m в отдельный лог-файл, чтобы к моменту ежемесячного разбора данные уже были накоплены, а не собирались вручную задним числом:

# crontab -e — снимок ресурсов каждый понедельник в 9:00
0 9 * * 1 (echo "=== $(date) ==="; df -h; free -m) >> /var/log/resource-snapshot.log

Именно ежемесячные и еженедельные проверки чаще всего выявляют по-настоящему дорогие проблемы — постепенный рост счёта за инфраструктуру, который никто не замечал, потому что смотрели только на сегодняшний CPU, или приближение к пределу диска, которое видно исключительно на графике за несколько месяцев, а не в срезе за один день. Ежедневные метрики защищают от простоя завтра; еженедельные и ежемесячные — от куда более неприятного сюрприза через полгода.

Частые вопросы