Как понять, что сервер скоро упрётся в потолок

MAATRIX

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

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

Если посмотреть на дашборд прямо сейчас и увидеть «CPU 45%, память 60%, диск 55%» — это не даёт ответа на главный вопрос: сколько времени у вас есть до того, как эти цифры станут критическими. Снимок состояния в моменте ничего не говорит о скорости, с которой ситуация меняется. Сервер с CPU на 45% может держаться на этом уровне годами при стабильной нагрузке — а может дойти до 90% за полтора месяца, если нагрузка растёт на 10-15% в месяц.

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

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

Сигнал 1: растёт не пик, а базовый уровень

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

Как это увидеть на практике. Возьмите график использования CPU, памяти и диска не за последний день, а за 3-6 месяцев, и мысленно (или графически) проведите линию не через пики, а через минимумы — через ночные и рабочие «спокойные» часы. Если эта линия минимумов идёт вверх, значит растёт база.

В Zabbix это удобно смотреть через тренды (history агрегируется в trends с шагом в час), запрос вида:

-- Средний CPU load по часам за последние 90 дней, по дням для наглядности тренда
SELECT
  FROM_UNIXTIME(clock, '%Y-%m-%d') AS day,
  AVG(value_avg) AS avg_cpu,
  MIN(value_min) AS floor_cpu
FROM trends
WHERE itemid = <item_id_cpu_load>
  AND clock > UNIX_TIMESTAMP(NOW() - INTERVAL 90 DAY)
GROUP BY day
ORDER BY day;

Здесь важна колонка floor_cpu — минимальное значение за день. Именно её тренд, а не тренд среднего или максимума, показывает, растёт ли базовый уровень.

В Prometheus то же самое — через min_over_time с широким окном и последующее сравнение по неделям:

# Минимальная (не средняя!) загрузка CPU за неделю — это и есть "базовый уровень"
min_over_time(node_cpu_seconds_total{mode="idle"}[7d])

Практическое правило: если базовый уровень CPU вырос с 15% до 35% за три месяца при том же наборе сервисов — это не шум и не разовая аномалия, это тренд, который нужно экстраполировать (как именно — в разделе про методику ниже), а не игнорировать до момента, пока он не превратится в постоянные 90%.

То же самое справедливо для памяти (базовое потребление после прогрева кэшей и без учёта краткосрочных всплесков GC) и для дискового пространства — там особенно показательно, потому что диск почти никогда не «откатывается» вниз сам по себе: если занятое место растёт на 2 ГБ в неделю стабильно, это прямая линия к дате, когда диск закончится, и её несложно посчитать заранее.

Сигнал 2: сокращается запас между типичным пиком и лимитом

Второй сигнал — не про базовый уровень, а про то, сколько «воздуха» остаётся у вас на случай неожиданного всплеска. Если полгода назад типичный дневной пик CPU доходил до 50% от доступной ёмкости, а сейчас регулярно доходит до 80%, формально сервер «ещё не упал» — но запас, который раньше позволял пережить дополнительный неожиданный всплеск трафика (вирусный пост, DDoS-подобный наплыв ботов, резкий рост пользователей после интеграции с партнёром) без деградации, сократился с 50 процентных пунктов до 20. При прочих равных вероятность того, что случайный дополнительный всплеск выведет систему за предел, растёт нелинейно по мере того, как сокращается этот запас.

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

Запас = (Лимит ресурса − Типичный дневной пик) / Лимит ресурса × 100%

Например, если лимит по памяти — 16 ГБ, а типичный дневной пик потребления полгода назад составлял 8 ГБ (запас 50%), а сейчас — 13 ГБ (запас ~19%), это падение запаса вдвое с лишним за полгода — сильный сигнал, даже если прямо сейчас 13 из 16 ГБ формально работают штатно, без свопа и без OOM.

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

Важный нюанс: смотреть нужно именно на *типичный* пик (например, медиану или 90-й перцентиль дневных максимумов за неделю), а не на абсолютный разовый рекорд — иначе один нетипичный день исказит картину и создаст ложную тревогу или, наоборот, ложное спокойствие.

Сигнал 3: система всё дольше работает близко к пределу

Третий сигнал — не про величину пика, а про его продолжительность. Полгода назад сервер мог кратковременно, на 10-15 минут в районе полудня, работать на 85-90% CPU — и это было нормально, разовый эпизод. Если сейчас похожий уровень загрузки держится по 2-3 часа подряд каждый будний день, это значит, что «повышенная нагрузка» перестала быть исключением и стала новой нормой, просто ещё не дотянувшейся до постоянного максимума.

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

# Prometheus: доля времени за последние 7 дней, когда CPU был выше 80%
avg_over_time(
  (node_cpu_seconds_total{mode!="idle"} > bool 0.8)[7d:5m]
)

Если этот показатель вырос с «5% времени за неделю» до «25% времени за неделю» за пару месяцев — у вас всё больше окон, в которые дополнительный всплеск не встретит запаса вообще, и рано или поздно один из этих эпизодов совпадёт с реальным неожиданным пиком трафика.

Практическая методика: как отслеживать тренд и оценить время до предела

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

Шаг 1. Заведите ежемесячный ритуал просмотра долгосрочных графиков. Не реактивно («что-то тормозит, надо бы глянуть графики»), а по расписанию — раз в месяц, календарным напоминанием, вне зависимости от того, есть ли сейчас проблемы. Смотрите не последние сутки, а минимум 3-6 месяцев истории на одном графике для CPU, памяти, диска и, если релевантно, дискового I/O и сетевой полосы.

В Grafana это одна панель с диапазоном now-6M и агрегацией по дню (иначе график из точек за каждую минуту за полгода превратится в нечитаемый шум):

# Пример: недельный максимум занятого места на диске за последние 6 месяцев,
# по одной точке на день
max_over_time(node_filesystem_avail_bytes{mountpoint="/"}[1d])

Если метрики хранятся только 15-30 дней (частая настройка по умолчанию в Prometheus без remote storage или в Zabbix с коротким периодом хранения history), для капасити-планирования этого категорически не хватает — стоит увеличить retention хотя бы для агрегированных данных (в Zabbix это trends, которые по умолчанию и так хранятся дольше history; в Prometheus — включить remote_write в Thanos/Mimir/VictoriaMetrics или просто поднять --storage.tsdb.retention.time до 6-12 месяцев, если объём диска позволяет).

Шаг 2. Считайте базовый уровень, запас и долю времени у предела отдельно, а не смешивайте в одну метрику. Заведите три простых числа на каждый ключевой ресурс (CPU, память, диск) и фиксируйте их раз в месяц — например, в простой таблице или дашборде:

Ресурс: Память, сервер app-01
Месяц      | Базовый уровень | Типичный пик | Запас (пик/лимит) | % времени >85%
2026-04    | 4.2 ГБ          | 8.1 ГБ       | 49%                | 3%
2026-05    | 4.6 ГБ          | 8.9 ГБ       | 44%                | 5%
2026-06    | 5.3 ГБ          | 9.8 ГБ       | 39%                | 8%
2026-07    | 6.0 ГБ          | 10.9 ГБ      | 32%                | 14%
2026-08    | 6.9 ГБ          | 12.1 ГБ      | 24%                | 22%

(Цифры здесь условные, для иллюстрации методики — не воспринимайте как ориентир по абсолютным значениям для вашей нагрузки, у вас они будут другие.) Такая таблица по одному ресурсу за 4-5 месяцев уже даёт наглядную картину: все три показателя ухудшаются синхронно, и это куда убедительнее, чем разовый взгляд на текущее состояние.

Шаг 3. Экстраполируйте тренд, чтобы получить примерный срок до исчерпания ёмкости. Если базовый уровень или типичный пик растёт линейно (что для растущей пользовательской базы или растущего объёма данных — обычная картина на горизонте нескольких месяцев, хотя не гарантированная), простейшая оценка — линейная регрессия через точки за последние 3-6 месяцев с проекцией на лимит:

Скорость роста = (Значение_сейчас − Значение_N_месяцев_назад) / N
Оставшееся время = (Лимит − Значение_сейчас) / Скорость_роста

На примере из таблицы выше (память, апрель → август, 4 месяца): рост базового уровня с 4.2 до 6.9 ГБ — это скорость около 0.68 ГБ/мес. Если лимит сервера — 16 ГБ и уже сейчас база — 6.9 ГБ, а типичный пик — 12.1 ГБ, то по пику до лимита остаётся около 3.9 ГБ, что при скорости роста пика (примерно 1 ГБ/мес по этим цифрам) даёт грубую оценку в 3-4 месяца до момента, когда типичный пик станет упираться в лимит. Это не точный прогноз — реальный рост редко идеально линеен, и на него влияют сезонность, разовые события и изменения в самом приложении — но это разумное окно для планирования, которого достаточно, чтобы заказать апгрейд или начать оптимизацию до того, как проблема станет острой, а не после.

В Prometheus такую проекцию можно получить одной функцией без ручных расчётов:

# Прогноз использования диска через 90 дней при текущем тренде последних 4 недель
predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[4w], 90*24*3600) < 0

Такое правило, вынесенное в отдельный alert с низким приоритетом (не «пейджер разбудить ночью», а «завести тикет на капасити-ревью»), автоматизирует ежемесячный ритуал из шага 1 хотя бы частично — но полностью полагаться только на автоматический алерт не стоит: он реагирует на числа, а не видит контекст вроде запланированного роста базы пользователей в следующем квартале, который вы, в отличие от алерта, знаете заранее.

Что делать, когда тренд подтверждён

Если экстраполяция трёх сигналов сходится и показывает окно в 2-4 месяца до исчерпания одного из ресурсов — это не повод паниковать, а повод спокойно выбрать путь. Здесь два практических направления: увеличить текущий сервер (вертикальное масштабирование — больше CPU, памяти, диска на той же машине) или распределить нагрузку на несколько серверов (горизонтальное масштабирование). Какой путь выгоднее в вашей ситуации по стоимости и сложности — разбирали отдельно в статье про то, что выгоднее — масштабирование вверх или вширь.

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

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

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