Кластер показывает 40% среднего CPU, но p99 растёт. Как проверить, не скрывает ли усреднение перегруженный экземпляр?
Нужно анализировать метрики по каждому экземпляру, а не только среднее значение по кластеру. Сравните максимальную и высокие квантили загрузки CPU, длину очередей, задержки, ошибки и число запросов на узлах с распределением трафика. Если один или несколько экземпляров перегружены, среднее значение по кластеру может выглядеть безопасным, пока именно эти узлы формируют высокий p99.
При переходе от одного сервера к горизонтально масштабируемым системам агрегированные метрики стали удобны для быстрого контроля общего состояния. Однако усреднение скрывает неоднородность: экземпляры могут получать разный объём трафика, иметь разную производительность или обслуживать разные типы запросов.
Поэтому практики наблюдаемости стали дополнять общие показатели метриками по отдельным узлам, зонам, группам запросов и временным интервалам. Исходная проблема заключалась в том, что среднее состояние кластера не всегда отражает состояние наиболее нагруженного компонента.
Среднее значение CPU 40% означает лишь, что суммарная загрузка распределена так, что её среднее по экземплярам равно 40%. Например, при четырёх узлах один может быть загружен на 100%, а остальные — примерно на 20%; среднее будет около 40%.
Перегруженный узел начинает накапливать очередь, дольше обслуживает запросы или отклоняет их. Балансировщик может продолжать направлять на него трафик, поэтому небольшая доля медленных запросов резко повышает p99, хотя средние показатели кластера остаются нормальными.
Сначала разбейте данные по экземпляру и синхронизируйте временные интервалы. Для каждого узла нужно сопоставить загрузку CPU, количество запросов, p50 и p95/p99 задержки, длину очередей, ошибки, тайм-ауты и признаки ограничений по пулу потоков или соединений.
Полезно сравнить следующие характеристики:
Если высокий p99 наблюдается одновременно с высокой загрузкой только отдельных экземпляров, нужно проверить распределение трафика. Возможные причины — неравномерная работа балансировщика, долгоживущие соединения, привязка сессий к узлу, различия в кэше или неодинаковый объём локального состояния.
Важно не считать сам факт высокой загрузки CPU доказательством узкого места. На узле могут быть высокие задержки из-за базы данных, блокировок, диска или внешнего сервиса, а CPU останется невысоким. Поэтому загрузку нужно коррелировать с задержками, очередями и изменением пропускной способности.
Практический компромисс состоит в выборе детализации метрик. Хранение показателей по каждому экземпляру повышает стоимость мониторинга, но без такой детализации невозможно надёжно выявлять перекос нагрузки. Агрегаты можно использовать для общего контроля, но решение о масштабировании и поиске узкого места следует принимать по распределению, а не только по среднему.
В тесте из шести экземпляров средний CPU кластера составлял 45%, но p99 вырос с 300 до 1800 миллисекунд. Команда рассматривала увеличение числа экземпляров, однако сначала построила графики по узлам и обнаружила, что один экземпляр получал почти вдвое больше запросов из-за длительно сохранявшихся соединений клиентов.
Рассматривались два варианта. Увеличение кластера могло временно снизить нагрузку, но не устраняло перекос и увеличивало расходы. Настройка распределения новых соединений и проверка сохранения сессий требовали дополнительного анализа, зато устраняли причину, а не только добавляли ресурсы.
Выбрали исправление распределения трафика и повторный тест с тем же профилем нагрузки. После выравнивания числа запросов по экземплярам максимальная загрузка стала ближе к средней, а p99 вернулся к целевому уровню без увеличения размера кластера.
Нет. Максимальный CPU показывает перекос или потенциальную перегрузку, но не доказывает причинность. Нужно проверить, что на том же экземпляре растут задержки или очередь, а изменение нагрузки приводит к ожидаемому изменению этих показателей. Если CPU высок, но задержка не меняется, ограничение может находиться в другом компоненте или загрузка может быть кратковременной и несущественной для SLA.
Запросы могут иметь разную стоимость. Один узел может получить больше операций записи, запросов с промахами кэша или больших ответов, хотя количество запросов одинаково. Поэтому нужно сравнивать не только RPS по экземплярам, но и состав операций, объём данных, время обработки и зависимые ресурсы.
Нужно анализировать временной ряд, а не единичную точку. Устойчивый перекос проявляется в нескольких последовательных интервалах и обычно сопровождается согласованными признаками: повышенной задержкой, очередью, ошибками или большей долей запросов на том же экземпляре. Единичный выброс может быть связан с перезапуском, фоновым процессом или сбором служебных данных и сам по себе не является основанием для изменения архитектуры.