Мониторинг VPS для WordPress: CPU/RAM метрики и настройка алертов

WordPress на VPS чаще всего “проседает” не из-за одной причины, а из-за сочетания нагрузки и ограничений железа: PHP начинает дольше считать, процессы копят очередь, растёт задержка запросов, а затем сервер упирается в CPU или память. Мониторинг по CPU и RAM нужен, чтобы увидеть проблему до жалобы пользователей и понять, почему она случилась.

Хороший мониторинг решает две задачи. Первая — заранее заметить рост нагрузки и предотвратить каскад: таймауты, ошибки 5xx, рост времени ответа. Вторая — дать опорные точки для диагностики: что именно было “узким местом” — CPU, нехватка памяти, своп или некорректная работа PHP-FPM.

Ниже — практичный подход к выбору метрик CPU/RAM и настройке алертов для WordPress на VPS, без привязки к конкретному бренду хостинга.

Какие метрики CPU и RAM стоит отслеживать на VPS

Чтобы алерты были полезными, важно понимать, что именно измеряется. CPU и RAM — это не только “процент загрузки” и “сколько свободно”. На VPS есть нюансы виртуализации, различие между общей загрузкой и загрузкой процессов, а также поведение swap при нехватке памяти.

Использование CPU: загрузка, очереди, виртуализация

Для CPU на практике важны несколько групп метрик.

• Процент CPU по состояниям: user, system, idle.
• user показывает вычисления в пользовательском пространстве (часто PHP, Nginx, части системы).
• system — время на ядро (файловые операции, сеть, драйверы).
• idle помогает понять, есть ли реальная нехватка ресурсов или проблема в другом.

1. Load average и его интерпретация.

Load average отражает среднее количество процессов в очереди на выполнение и процессов, ждущих CPU. Его нельзя сравнивать с “процентом” напрямую, но он полезен для понимания долгих очередей. Для систем с несколькими ядрами ориентируются на нагрузку относительно количества CPU.

1. iowait (время ожидания ввода-вывода).

Даже если тема статьи CPU и RAM, iowait помогает отличить ситуацию “CPU действительно не справляется” от ситуации “сервер ждёт диск/сеть”. Иначе можно настроить алерт по CPU на ошибочной гипотезе.

1. steal (если есть метрики от гипервизора).

steal показывает, сколько времени виртуальная машина “ждёт” CPU, предоставляемый хостом. Если steal растёт, проблема может быть не в вашем WordPress, а в загрузке физического сервера. Это особенно важно для VPS на shared-инфраструктуре.

1. Пиковая нагрузка и длительность.

Если вы реагируете только на средние значения, можно пропустить краткие всплески, которые ломают PHP-FPM. Поэтому полезны и средние, и максимумы, и “сколько минут подряд” порог превышался.

Память RAM: доступная память, своп и признаки давления

Для RAM важнее “доступная” память, чем просто свободная. Linux активно использует кэш файловой системы, и “free” может выглядеть оптимистично, даже когда приложения реально стеснены.

1. Available memory.

Эта величина показывает, сколько памяти реально можно выделить приложениям без активного сброса кэшей. Именно она чаще всего коррелирует с тем, что PHP-FPM будет упираться в лимиты.

1. Своп: usage swap и активность.

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

1. Пики RSS у важных процессов.

Полезно смотреть не только агрегированную память, но и динамику по процессам: php-fpm (мастер/воркеры), очереди, количество процессов. Даже при достаточном RAM можно получить ситуацию, когда несколько воркеров раздуваются из-за конкретных запросов (тяжёлые плагины, экспорты, крон).

1. Признаки OOM (out of memory).

Когда система начинает “убивать” процессы из-за нехватки памяти, WordPress может резко переходить в нестабильность. Для алертов критично фиксировать события OOM и перезапуски сервисов.

1. Длительность давления на память.

Как и по CPU, важна устойчивость: единичный пик на доли минут — не всегда причина отказов. А вот длительный спад available memory или рост swap на десятки минут чаще заканчивается деградацией.

Связь метрик с нагрузкой WordPress

WordPress обычно создаёт нагрузку через PHP и работу с базой данных. Но даже не заглядывая в MySQL/Redis, CPU и RAM часто показывают “поведение приложения”.

• Рост CPU вместе с ростом времени ответа: обычно это вычисления в PHP, тяжелые запросы в шаблонах, плагины, импорт/обновления, фоновые задачи.
• Рост CPU без роста iowait: чаще вычислительная проблема (или слишком много одновременных воркеров).
• Падение available memory и рост swap: нехватка памяти на уровне процессов, обычно из-за числа воркеров PHP-FPM, тяжёлых объектов, больших массивов в PHP или неэффективных плагинов.
• OOM и резкие перезапуски: почти всегда “грубая” нехватка памяти или аномальный запрос, который раздувает процесс.

Практический вывод простой: алерт должен быть привязан не только к значению, но и к “сценарию”: сколько времени длится, что ещё меняется (например, рост запросов или перезапуски).

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

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

Варианты стека для VPS

Самый распространённый подход для Linux-серверов:

• Сбор метрик: node_exporter, Telegraf или встроенный агент (например, Netdata).
• Хранение и запросы: Prometheus (часто в связке с Alertmanager), InfluxDB или облачное хранилище.
• Визуализация: Grafana.
• Алерты: Alertmanager/встроенные правила или отправка в Telegram/почту/PagerDuty.

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

Что собирать на уровне системы

Для CPU и RAM минимальный набор метрик обычно включает:

• загрузку CPU по состояниям и/или общую загрузку;
• load average;
• iowait;
• (если возможно) steal;
• available memory, swap usage;
• RSS/количество процессов php-fpm (или хотя бы агрегированная статистика по процессам);
• события OOM и перезапуски сервисов (через системный журнал).

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

• uptime сервера;
• количество рестартов php-fpm/nginx (если nginx и php-fpm отдельно);
• доступность порта приложения (хотя бы TCP-check).

Дашборд для WordPress: минимум панелей

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

• CPU: user/system/idle + load average + iowait (и steal, если доступно).
• RAM: available memory + swap + OOM/perезапуски (или хотя бы график available и swap).
• php-fpm: число процессов и их память (если собираете).
• “Сводка по инцидентам”: когда алерт сработал и как менялись метрики до этого.

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

Настройка алертов по CPU на VPS

Алерт по CPU должен отвечать на вопрос: “что делать, если CPU растёт?”. Поэтому правило формулируют так, чтобы оно было:

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

Выбор порогов для CPU: проценты не всегда главный ориентир

Единый “правильный” порог для всех VPS не существует. Причина проста: количество vCPU, тип нагрузки, планировщик, и даже поведение виртуализации меняют картину.

Практика, которая обычно работает:

1. Отталкиваться от load average и числа ядер.

Если на VPS 2 vCPU, нагрузка, которая выглядит приемлемой на 8 vCPU, может быть критичной. Поэтому load average часто удобнее для универсальных порогов.

1. Использовать длительность превышения.

Вместо “CPU выше X” задавайте “CPU выше X в течение N минут”. Это резко снижает ложные срабатывания от коротких всплесков.

1. Учитывать iowait.

Если CPU высокий из-за iowait, вероятнее узкое место в диске/сети. Тогда алерт “CPU высокий” может быть информативным, но действия будут другие: проверка диска, latency, очередей.

1. Для steal реагировать осторожно.

Если steal растёт, масштабировать WordPress на вашем уровне может быть недостаточно. Тут полезнее алерт, который сигналит о деградации инфраструктуры, а не о проблеме в коде.

Пример формулировки правила (как отправная точка):

• срабатывание, если доля user/system растёт и держится выше заданного уровня несколько минут подряд;
• отдельное правило на “CPU + высокий iowait” (чтобы отличать вычисления от ожидания ввода-вывода).

Если вы пока не знаете пороги, начните с наблюдения. В течение нескольких дней зафиксируйте типичные дневные пики и ночные интервалы. Алерты, настроенные на “плохие” значения заранее, часто ломают команду шумом.

Примеры алертов по CPU и ожидаемое действие

Хороший алерт содержит контекст, чтобы он не превращался в “пинг ради пинга”. Ниже — набор сценариев, которые обычно связывают с WordPress.

• CPU высокий длительно.
• Срабатывание: CPU превышает порог в течение нескольких минут.
• Действие: проверить, растёт ли время ответа, нет ли роста очередей, и какие процессы разогрелись (php-fpm, nginx).

• Load average высокий без пропорционального роста user.
• Срабатывание: load растёт, а вычислительная нагрузка умеренная.
• Действие: проверить iowait, сеть, блокировки, планировщик. Часто это признак проблем ввода-вывода или зависших процессов.

• Steal высокий.
• Срабатывание: steal растёт и держится.
• Действие: проверить, есть ли корреляция с проблемами у других услуг/серверов у того же хостера (если есть доступ), оценить стабильность VPS. Масштабирование внутри WordPress может не помочь.

• Быстрый всплеск CPU с ростом ошибок.
• Срабатывание: быстрый рост CPU плюс рост 5xx/таймаутов.
• Действие: смотреть логи запросов, фоновые задачи, крон, плагины, и время этих задач относительно пика.

Важно: алерт не должен быть “только по метрике”. Он должен быть “метрика + окно + связка с последствиями” (например, ростом ошибок или таймаутов).

Как снизить ложные срабатывания по CPU

Ложные алерты по CPU чаще всего появляются из-за трёх причин.

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

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

1. Слишком широкий порог.

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

1. Игнорирование сезонности нагрузки.

У WordPress пики могут быть в определённые часы. Порог, который корректен ночью, может быть шумным днём. В этом случае помогают разные профили или хотя бы ручная настройка по реальным данным.

Технически помогают также:

• гистерезис (например, алерт включается при одном пороге и выключается при более низком);
• cool-down (не повторять алерт каждые пару минут на одном и том же состоянии);
• группировка уведомлений (чтобы не прислать десять одинаковых сообщений при одном инциденте).

Настройка алертов по RAM для WordPress

RAM — более “коварная” метрика, чем CPU. Слишком ранние алерты дают шум, слишком поздние — приводят к OOM и падению функциональности.

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

Пороговые уровни: available memory и swap

Ориентироваться стоит не на “свободно” в абстракции, а на available memory и swap.

Практика:

• Если available memory падает и держится ниже заданного уровня несколько минут — это сигнал к действию.
• Если swap начинает заметно использоваться или растёт скачками — это почти всегда предвестник проблем с задержками.
• Если есть доступ к метрикам перезапусков php-fpm — полезно привязать алерт к ним (или сделать отдельный алерт).

Как выбирать порог, если опыта мало:

1. Соберите статистику “нормы” по доступной памяти за неделю.
2. Отметьте нижние значения, которые случались без инцидентов.
3. Настройте порог ниже “нижней границы нормы”, с окном продолжительности.

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

Алёрты на угрозу OOM и перезапуски сервисов

OOM-подобные события лучше ловить напрямую по логам или event-метрикам:

• сообщения системы о killer’е;
• рост счётчика OOM;
• перезапуск php-fpm или nginx (если сервис уходит в рестарт).

Отдельно стоит рассмотреть алерт на рост количества перезапусков за короткое время. Если php-fpm перезапускается стабильно раз в час — вероятно, есть конкретный триггер. Если перезапусков становится больше в период высокой нагрузки — это признак каскада проблем.

Полезный паттерн: делать два уровня уведомлений.

• Предупреждение по давлению памяти (available memory низкая, swap растёт).
• Критическое событие по OOM/перезапускам.

Так вы получаете время на диагностику до “жёсткого” падения.

Контроль памяти php-fpm: чтобы алерт вел к конкретному виновнику

В WordPress значительную часть RAM забирают PHP воркеры. Даже если общий график доступной памяти выглядит терпимо, можно наблюдать:

• рост RSS у php-fpm при неизменном общем потреблении (например, из-за утечки или тяжёлого запроса);
• увеличение количества воркеров или смена их поведения.

Если у вас есть метрики по php-fpm, алерт можно усилить:

• не просто “RAM низкая”, а “RAM низкая + растёт RSS php-fpm”;
• “swap растёт + php-fpm перезапускается”.

Тогда диагностика становится точнее: вы сразу смотрите воркеры и их поведение, а не строите догадки по всей системе.

Как уменьшить шум алертов по RAM

На практике ложные алерты по памяти появляются из-за “игры кэшей” Linux и из-за swap, который может включаться на коротких пиках.

Что помогает:

• Использовать available memory вместо free memory.
• Учитывать swap: если swap меняется на краткие значения, но затем возвращается, алерт можно делать по условию “swap устойчиво растёт” или “swap + падение доступной памяти”.
• Добавить требование по длительности превышения.
• Избегать слишком частых повторов уведомлений при одном и том же состоянии (cool-down).

Также важно периодически пересматривать пороги после обновлений WordPress или изменения конфигурации PHP-FPM (например, изменения количества воркеров или лимитов).

Что добавить сверх CPU/RAM, чтобы алерты по WordPress были действительно полезными

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

Минимальный набор дополнений:

• Диск: свободное место на файловой системе и время ответа диска/очереди (хотя бы косвенно через iowait).
• Сеть: ошибки интерфейса и резкие падения входящего трафика (иногда алерт выглядит как “CPU растёт”, потому что сервер обрабатывает больше ретраев).
• HTTP метрики (если есть): рост 5xx, рост таймаутов, p95 время ответа.
• Метрики базы данных (опционально): чтобы понять, не является ли CPU следствием запросов, которые упираются в MySQL.

Почему это важно: если CPU высокий одновременно с ростом iowait и ошибок диска, “оптимизация WordPress” может быть не первичной задачей. Может потребоваться замена диска или настройка лимитов.

Пример рабочего процесса: от алерта к устранению

Хороший мониторинг — это не только графики. Это ещё и короткий процесс, который повторяется от инцидента к инциденту.

1. Зафиксируйте факт и время.

Откройте алерт и посмотрите временное окно: когда CPU/RAM начал ухудшаться и сколько это длилось.

1. Проверьте “тип” проблемы по метрикам.

Если CPU вырос и держится, а iowait умеренный — фокус на вычислениях PHP. Если iowait растёт вместе с CPU — проверяйте диск и сеть. Если available memory падает и swap растёт — фокус на памяти и php-fpm.

1. Сопоставьте с событиями WordPress.

Смотрите, были ли в это время:

• крон-задачи;
• обновления плагинов/тем;
• массовые публикации или импорты;
• генерация кэшей;
• фоновые процессы, которые выполняются по расписанию.

1. Посмотрите поведение php-fpm.

Если RAM падает, смотрите RSS воркеров и количество процессов. Если CPU растёт, смотрите, что делает php-fpm в пики: обычно это видно по росту количества активных воркеров и нагрузке на конкретные endpoint’ы/операции.

1. Уточните по логам.

Логи php-fpm и nginx помогают связать метрику с конкретными запросами или ошибками. При OOM в логах будет ясная причина и момент убийства процесса.

1. После стабилизации оцените, что именно менять.

Чаще всего решения бывают трёх типов:

• правка конфигурации (лимиты, количество воркеров php-fpm, timeouts, настройки кэша);
• оптимизация WordPress/плагинов (уменьшение тяжёлых задач в пики, оптимизация запросов, отключение ненужных процессов);
• изменение инфраструктуры (увеличение RAM/CPU, замена диска, переход на другой тип VPS).

1. Пересоберите алерты.

Если инцидент случился, а алерт сработал слишком поздно (или не сработал вообще), это повод уточнить правила: порог, окно, условие по длительности, cool-down.

Типичные “ветки” диагностики

• CPU высокий, ошибок много: проверка тяжёлых endpoint’ов, плагинов и фоновых задач.
• CPU высокий, ошибок мало: может быть просто накопление очередей без критического влияния; алерт стоит сделать мягче или иначе формализовать критерий.
• RAM низкая, swap растёт: проверка php-fpm воркеров, утечек, тяжёлых запросов и количества одновременных задач.
• OOM: чаще всего срочное устранение причины и настройка лимитов/воркеров. После этого — отдельная проверка плагинов/кода, который может раздувать память.

Частые ошибки при мониторинге VPS для WordPress

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

1. Ориентироваться только на “CPU %”.

CPU в процентах без контекста может быть непоказательным. Нужны load average, iowait и (если есть) steal.

1. Ставить пороги “по ощущениям”.

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

1. Игнорировать длительность превышения.

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

1. Не разделять предупреждение и критическое состояние.

Два уровня сильно помогают: предупредить заранее и отдельно уведомить, когда уже есть симптомы падения (например, перезапуски или OOM).

1. Уведомлять слишком часто.

Если алерт отправляет сообщение каждые 2 минуты в любом состоянии, его начнут игнорировать. Cool-down, хистерезис и группировка — обязательны для работоспособности системы.

1. Не делать действий после алерта.

Алерт без сценария превращается в шум. Минимум нужен чек-лист: что проверить сначала, где смотреть логи, какие метрики “сопоставлять”.

1. Не пересматривать настройки после изменений.

Обновили PHP-FPM, изменили кэширование, подключили новый плагин — пороги и окна стоит проверять заново. Иначе система либо начнёт срабатывать на “норме”, либо пропустит новый паттерн нагрузки.

Итог: минимальный набор для запуска мониторинга и алертов по CPU/RAM

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

Проверьте, что у вас есть:

• Метрики CPU: user/system/idle, load average, iowait, (если доступно) steal.
• Метрики RAM: available memory, swap usage.
• Контекст по WordPress: число активных процессов php-fpm и признаки перезапусков (если собираете).
• Алерты:
• по CPU с длительностью (не мгновенно) и, при необходимости, с разделением “вычисления vs ожидание ввода-вывода”;
• по RAM на снижении available memory и на росте swap;
• отдельно на OOM/перезапуски php-fpm или критические события.
• Два уровня уведомлений: предупреждение и критика.
• Настройка шумоподавления: cool-down/гистерезис и разумный интервал повторов.

Дальше действуйте так: в течение нескольких дней смотрите графики и сравнивайте, как ведут себя метрики в “хорошие” и “плохие” периоды. Затем уточняйте пороги и правила длительности. Мониторинг VPS для WordPress по CPU и RAM должен становиться точнее после каждого инцидента, а не превращаться в статичную настройку “на века”.

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