Какое значение загрузки процессора (CPU utilization) считается малым, а какое большим?

Оценка загрузки CPU — это не просто взгляд на процент, а анализ в контексте. Нет универсальных цифр, но есть общепринятые диапазоны и важные нюансы.

Условные диапазоны (для общего случая):

• Низкая (0% — 30%): Система простаивает или слабо нагружена. Может быть нормой для фоновых сервисов, но для высокопроизводительных приложений может указывать на неоптимальное использование ресурсов или блокировки (например, ожидание ввода-вывода).
• Средняя / Нормальная (30% — 70%): Здоровая рабочая нагрузка. Система отзывчива, есть запас для обработки пиков. Идеальный диапазон для планирования capacity.
• Высокая (70% — 90%): Система активно работает, запас производительности мал. Могут начать расти latency (время отклика) и очереди. Требуется наблюдение и планирование масштабирования (горизонтального — больше нод, или вертикального — более мощные CPU).
• Критическая (90% — 100%): Система перегружена. Очереди растут, отклик сильно деградирует, могут начаться сбои. Требуется срочное вмешательство: поиск «горячих» процессов, масштабирование, оптимизация кода.

Критически важные нюансы для DevOps:

1. Пики vs. Усредненная нагрузка: Кратковременные пики до 100% (например, при старте JVM-приложения) — это норма. Опасно, если высокий процент держится продолжительное время (минуты). Мы смотрим на графики в Grafana (среднее за 5-15 минут), а не на мгновенные значения.
2. Load Average vs. CPU Utilization: На Linux важно смотреть load average (средняя длина очереди процессов, готовых к выполнению). Если load avg значительно превышает количество CPU ядер при умеренной утилизации CPU — это явный признак проблемы с I/O (диск, сеть). Процессы ждут, а не работают.
3. Контекст приложения:
   • Для CPU-intensive задач (видеокодирование, научные расчеты) высокая утилизация — это цель.
   • Для I/O-intensive сервисов (базы данных, веб-серверы) даже 50% утилизации CPU при высоком load avg — тревожный сигнал о bottleneck на диске или сети.
4. Контейнеры и Kubernetes: В K8s мы смотрим не только на утилизацию ноды, но и на Requests/Limits подов. Подам может не хватать CPU, даже если нода недогружена, из-за неправильных лимитов. Используем метрики container_cpu_usage_seconds_total в Prometheus.

Пример PromQL запроса для расчета утилизации CPU ноды (в процентах):

# Усредненная загрузка всех ядер ноды за 5 минут
100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle", instance="node-1"}[5m])) * 100)

# Загрузка по ядрам
100 - (avg by(instance, cpu) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

Главное правило: устанавливаем базельные значения (baseline) для своего сервиса в нормальном режиме работы и настраиваем алерты на значительные отклонения от этой базы, а не на абстрактные 80%.