Падение производительности сервера на 30% часто остаётся незамеченным, пока не приводит к обрыву сессий пользователей или отказу базы данных. Первым сигналом становится задержка ответа выше 500 мс — это означает, что один из ключевых ресурсов (CPU, RAM, диск или сеть) работает на пределе. Например, load average выше количества ядер процессора на Linux или Memory\Available MBytes ниже 10% от общего объёма в Windows — это уже повод для экстренных действий, а не просто предупреждение.

Но мониторинг не ограничивается базовыми метриками. Apache или Nginx могут выдавать ошибки 502 Bad Gateway из-за перегруженного бэкенда, а MySQL — «зависать» на запросах из-за блокировок таблиц, хотя CPU загружен всего на 40%. В 60% случаев причиной простоя становятся недооценённые параметры: количество открытых файлов (ulimit -n), время ответа DNS или ошибки в логах /var/log/syslog. Далее разберём, что именно отслеживать, какие инструменты использовать и как отличать ложные срабатывания от реальных угроз.

1. Загрузка процессора (CPU): как отличить нормальную нагрузку от критической

Средняя загрузка CPU выше 70% в течение 5+ минут — это не всегда проблема. Например, рендеринг видео или компиляция кода закономерно потребляют ресурсы, но не должны блокировать другие процессы. Опасность представляют два сценария:

  • 🔥 Длительная 100% нагрузка одним процессом (например, php-fpm или java): проверьте утечки памяти или бесконечные циклы.
  • ⚡ Высокий iowait (более 20%): CPU простаивает, ожидая данные с диска — сигнал о проблемах с хранилищем.
  • 🧩 Неравномерная загрузка ядер: одно ядро загружено на 99%, остальные — на 5%. Причина: процесс не оптимизирован для многопоточности.

Для диагностики на Linux используйте:

top -c # Просмотр процессов с сортировкой по CPU

mpstat -P ALL # Нагрузка по каждому ядру


htop # Интерактивный мониторинг (установите пакет)

⚠️ Внимание: На виртуальных серверах (VPS) высокий steal time (более 5%) указывает на «кражу» ресурсов соседними ВМ. Это проблема хостинга, а не вашей конфигурации.
💡

Для Windows используйте Performance Monitor (перфмонитор) с счётчиками \Processor(_Total)\% Processor Time и \System\Processor Queue Length. Значение последнего выше 2 на ядро — критический сигнал.

2. Оперативная память (RAM): утечки, своп и скрытые «пожиратели»

Ошибка многих администраторов — ориентироваться только на free -m, где строка available показывает «свободную» память. На самом деле Linux активно использует кеш и буферы, поэтому даже при 10% available система может работать стабильно. Реальные проблемы начинаются, когда:

  • 📉 Своп используется регулярно (проверьте vmstat 1 5 — колонка si/so не должна показывать активность).
  • 🐌 Очистка кеша не помогает: после sync; echo 3 > /proc/sys/vm/drop_caches память освобождается на 10-15 минут, затем снова забивается.
  • 👻 Невидимые процессы: ps aux --sort=-%mem не показывает «пожирателей», но память утекает (проверьте slabtop для ядерных утечек).
ПараметрНормаКритическое значениеИнструмент проверки
Своп (swap)0% использовано>5% в течение часаfree -h, vmstat 1
Available memory>10% от общего объёма<5%free -m
Active memoryСтабильный уровеньРост на 100+ МБ/минsmem -r
Slab cache<10% от общей RAM>20%slabtop -sc

На Windows следите за счётчиками \Memory\% Committed Bytes In Use (не должен превышать 80%) и \Memory\Pages/sec (значения выше 20 указывают на активное своппирование). Для поиска утечек используйте Process Explorer от Microsoft.

Как найти утечку памяти в Docker-контейнерах

Выполните docker stats и отсортируйте контейнеры по колонке MEM %. Если контейнер потребляет больше лимита (--memory), проверьте логи приложения на ошибки OutOfMemoryError (Java) или allowed memory size exhausted (PHP).

3. Дисковое пространство и I/O: почему 10% свободного места — это уже мало

Ошибка No space left on device может возникать даже при 20% свободного места на диске. Причины:

  • 📁 Inode исчерпаны: проверьте df -i. Частая проблема на хостингах с миллионами мелких файлов (например, кеш WordPress).
  • 🐢 Высокая задержка I/O: iostat -x 1 показывает await > 20 ms — диск не справляется с нагрузкой.
  • 🔄 RAID деградировал: проверьте cat /proc/mdstat (для программного RAID) или megacli -LDInfo -Lall -aALL (для аппаратного).

Критические пороги для дисков:

  • 🚨 Свободное место: <15% на ext4/XFS, <20% на NTFS (фрагментация!).
  • ⚡ Задержка записи: latency > 100 ms (проверяйте iotop -o).
  • 💥 Ошибки SMART: smartctl -a /dev/sdX | grep -i error. Даже 1 ошибка Reallocated_Sector_Ct — повод для замены диска.

Удалите старые логи (journalctl --vacuum-time=7d)

Очистите кеш пакетов (apt clean или yum clean all)

Найдите крупнейшие файлы (ncdu /)

Проверьте удалённые, но занятые файлы (lsof +L1)

-->

4. Сетевая активность: как выявить DDoS и «тихие» атаки

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

  • 🕵️ Скрытым сканированием портов: проверьте netstat -tulnp на неожиданные соединения.
  • 🌊 SYN-флудом: ss -s покажет тысячи соединений в состоянии SYN-RECV.
  • 📦 Перегрузкой канала: iftop или nethogs помогут найти процесс, потребляющий трафик.

Ключевые метрики для мониторинга:

ПараметрНормаКритическое значение
Пропускная способность<80% от максимума канала>90% в течение 10+ минут
Потери пакетов (ping)0%>1%
Задержка (latency)<50 мс до ближайшего хоста>200 мс
Количество соединений<1000 для веб-сервера>10 000 (возможен DDoS)

Для Windows используйте Resource Monitor (вкладка «Сеть») или Wireshark для глубокого анализа. Обратите внимание на необычные порты (например, 4444, 3389) — они могут указывать на ботнет или бэкдор.

Раз в неделю|Только при жалобах пользователей|Ежедневно|Автоматизированный мониторинг 24/7-->

5. Логи сервера: где искать первые признаки бедствия

90% проблемют о себе в логах за часы до сбоя. Ключевые файлы для мониторинга:

  • 📜 /var/log/syslog или /var/log/messages: ошибки ядра, аппаратные сбои.
  • 🌐 /var/log/nginx/error.log (или apache2/error.log): HTTP-ошибки 5xx, таймауты.
  • 🗃️ /var/log/kern.log: проблемы с дисками, RAID, файловой системой.
  • 🔑 /var/log/auth.log: неудачные попытки входа (возможный брутфорс).

Ищите следующие паттерны:

grep -i"error\|fail\|warning\|timeout\|refused" /var/log/*

Для Windows проверяйте Event Viewer (разделы System, Application, Security>). Особое внимание уделите событиям с ID:

  • Event ID 6005 — некорректное завершение работы.
  • Event ID 7000 — сбой службы.
  • Event ID 4625 — неудачный вход (возможная атака).
💡

Настройте ротацию логов (logrotate), чтобы файлы не занимали всё дисковое пространство. Пример конфига для Nginx: /var/log/nginx/*.log { daily; missingok; rotate 14; compress; }

6. Температура и аппаратное здоровье: когда сервер «закипает»

Перегрев — одна из самых недооценённых причин сбоев. Нормальные температуры для компонентов:

  • 🖥️ CPU: до 70°C под нагрузкой (максимум для большинства процессоров — 90-100°C).
  • 💾 HDD/SSD: до 50°C (предел — 60°C, но риск потери данных растёт уже после 55°C).
  • 🖼️ Чипсет материнской платы: до 80°C.

Проверка на Linux:

sensors # Температуры (установите пакет lm-sensors)

smartctl -a /dev/sdX | grep Temperature # Для дисков


ipmitool sensor reading # Для серверного железа (IPMI)

На Windows используйте HWiNFO или Open Hardware Monitor. Особое внимание уделите:

  • ⚠️ Резким скачкам температуры (например, с 40°C до 80°C за 5 минут) — признак неисправности кулера.
  • 🔋 Напряжению: отклонение от номинала (±5%) может указывать на проблемы блока питания.
⚠️ Внимание: Если сервер находится в дата-центре, температура входящего воздуха не должна превышать 27°C (стандарт ASHRAE). При 30°C+ риск перегрева возрастает в 3 раза.

7. Процессы и службы: как выявить «зомби» и висящие задачи

«Зомби-процессы» (defunct) не потребляют ресурсы, но занимают PID и могут блокировать новые задачи. Проверьте их наличие:

ps aux | grep'Z'

Другие опасные сценарии:

  • 🧟 Висящие службы: systemctl list-units --state=failed (Linux) или sc query | find"STOPPED" (Windows).
  • 🔄 Бесконечные рестарты: journalctl -u servicename --no-pager | grep"restarting".
  • 🕳️ «Чёрные дыры»: процессы, потребляющие 0% CPU, но висящие в памяти (например, python или node после краха).

Для Windows критично отслеживать зависшие сессии RDP (проверяйте через qwinsta или Task Manager → вкладка «Пользователи»). Одна висящая сессия может блокировать новые подключения.

Как убить «неубиваемый» процесс в Linux

Если kill -9 не работает, процесс может быть в состоянии D (Uninterruptible Sleep). Попробуйте:

1. Найдите PID: ps aux | grep D

2. Проверьте, не связан ли он с NFS или диском: ls -l /proc/PID/fd

3. Перезагрузитесь (если это возможно) или используйте echo 1 > /proc/sys/kernel/sysrq + echo t > /proc/sysrq-trigger (осторожно!).

8. Безопасность: признаки взлома, которые нельзя игнорировать

Сервер может быть скомпрометирован месяцами, прежде чем вы это заметите. Красные флаги:

  • 🚪 Неизвестные пользователи: cut -d: -f1 /etc/passwd (Linux) или net user (Windows).
  • 🔑 Подозрительные SSH-ключи: ls -la ~/.ssh/authorized_keys.
  • 🕰️ Изменённые системные файлы: debsums -c (Debian) или rpm -Va (RHEL).
  • 📡 Неожиданные исходящие соединения: ss -tulnp | grep ESTAB.

Проверьте последние выполненные команды:

history | tail -20 # Для текущего пользователя

grep"COMMAND=" /var/log/auth.log # Для всех пользователей (Linux)

На Windows ищите подозрительные задачи в Планировщике заданий (schtasks /query /fo LIST /v) и проверяйте автозагрузку (wmic startup list full).

💡

Настройте оповещения о новых пользователях в системе. Например, в Linux добавьте в /etc/pam.d/sshd строку: session required pam_exec.so /path/to/script.sh, где скрипт будет отправлять уведомление при каждом новом логине.

FAQ: Частые вопросы о мониторинге серверов

Как часто нужно проверять сервер, если на нём нет критических задач?

Минимальная частота — раз в сутки для проверки дискового пространства, загрузки CPU и доступности ключевых служб. Автоматизированный мониторинг (например, Zabbix или Prometheus) должен работать круглосуточно с оповещениями о:

  • Загрузке CPU > 80% в течение 10 минут.
  • Свободной памяти < 10%.
  • Дисковом пространстве < 15%.
  • Недоступности портов (80, 443, 22).
Какие инструменты мониторинга бесплатны и подходят для небольших проектов?

Для Linux:

  • Netdata — реальный мониторинг в браузере (bash <(curl -Ss https://my-netdata.io/kickstart.sh)).
  • Grafana + Prometheus — для визуализации метрик.
  • Glances — альтернатива top с веб-интерфейсом.

Для Windows:

  • PRTG Free (до 100 сенсоров).
  • Nagios Core + плагин NSClient++.
Что делать, если сервер «лагает», но все метрики в норме?

Проверьте:

  1. Время ответа DNS: dig example.com | grep"Query time". Задержка > 100 мс — проблема с резолвером.
  2. MTU сети: большие пакеты фрагментируются, что тормозит соединение. Проверьте ping -M do -s 1472 google.com.
  3. Конфликты IRQ (актуально для физических серверов): cat /proc/interrupts.
  4. Настройки TCP: sysctl net.ipv4.tcp_* — неправильные значения tcp_keepalive_* могут вызывать задержки.
Как мониторить сервер, если к нему нет доступа по SSH/RDP?

Используйте внешние сервисы:

  • UptimeRobot — проверка доступности HTTP/TCP/Ping.
  • Pingdom — мониторинг времени ответа.
  • StatusCake — проверка SSL-сертификатов и содержимого страниц.

Для глубокого анализа без доступа:

  • Настройте SNMP (если поддерживается хостингом).
  • Используйте IPMI (для выделенных серверов).
  • Попросите поддержку хостинга предоставить скриншоты из консоли управления (например, VMware vSphere или SolusVM).
Какие метрики мониторить в первую очередь для игрового сервера?

Для Minecraft, CS:GO или Rust критичны:

  • Tickrate: для CS:GO должен быть стабильно 64+ (проверяйте net_graph 1 в игре).
  • Задержка сети: ping между сервером и клиентами < 50 мс.
  • Потоковые ошибки UDP: netstat -su (ищите packet receive errors).
  • Использование RAM: игровые сервера часто страдают от утечек (например, Spigot на Minecraft).
  • Дисковый ввод-вывод: карты в CS:GO или мира в Minecraft при загрузке создают пики I/O.

Используйте плагины для мониторинга внутри игры (например, ServerStats для Minecraft).