Визуализация мониторинга Linux PSI с помощью Grafana: как правильно понимать и отслеживать нагрузку на ресурсы

Я показываю, как я linux psi с помощью Prometheus собирать данные и отображать их в Grafana, чтобы измерить нагрузку на ЦП, память и ввод-вывод как реальное время ожидания. Таким образом, я могу определить Узкие места на ранней стадии, присвойте им cgroups или контейнеры и, при необходимости, запустите автоматические меры противодействия.

Центральные пункты

• Показатели PSI: «some/full» для ЦП, памяти, ввода-вывода и скользящих средних
• cgroup — в центре внимания: Взгляд с точки зрения конкретных контейнеров и сервисов, а не только с глобальной точки зрения
• Триггер оповещения: Использование poll/epoll для обработки событий по пороговым значениям
• Grafana: Панели для трендов, пиковых значений и факторов, входящих в топ-N
• Лучшие практики: пороговые значения, временные интервалы, корреляция с системными показателями

Краткое объяснение PSI: понимание давления как реального времени ожидания

PSI отвечает на вопрос, сколько реальное время Задачи тщетно ожидают ресурсов ЦП, ОЗУ или ввода-вывода. Файлы в папке /proc/pressure/{cpu,memory,io,irq} представляют две точки зрения: несколько показывает фазы, в которых некоторые задачи находятся в режиме ожидания, полный обозначает моменты, когда все непассивные задачи блокируются. Я оцениваю оба значения отдельно, потому что несколько начинается раньше и полный выявляет реальные простои. Кроме того, я использую avg10, avg60 и avg300, чтобы отличать краткосрочные колебания от долгосрочных тенденций. О растущей всего-В этот момент я понимаю, насколько сильно нарастает давление с момента отправления на лодке и где Горячие точки ложь.

Системный уровень против cgroup-PSI: выбор правильного уровня

Я сознательно провожу различие между общими показателями давления и точкой зрения с точки зрения cgroup. Файлы, расположенные в папке /proc/pressure/ отражают систему в целом, тогда как cgroup v2 дополнительно cpu.pressure, нагрузка на память и io.pressure для каждой группы. В контейнерных средах я использую это для упорядоченного размещения печати в подках, сервисах или контейнеринг . Такое распределение позволяет избежать «полетов вслепую»: вместо того, чтобы гадать, я сразу вижу источник проблемы в группе. На многопользовательских хостах я таким образом разделяю общие и выделенные нагрузки и управляю Лимиты целевой.

Проверить условия: включить ядро, PSI и cgroup v2

Прежде чем приступить к сбору показателей, я убеждаюсь, что платформа подходит:

• Версия ядра: PSI доступно начиная с версии Linux 4.20. Я проверяю с помощью uname -r и проверяю через zcat /proc/config.gz | grep CONFIG_PSI, включена ли поддержка в компиляцию.
• Флаг времени выполнения PSI: В некоторых дистрибутивах допускается использование дополнительного флага загрузки psi=1, чтобы полностью активировать PSI. Я включаю его при необходимости и проверяю, что /proc/pressure/* предоставляет контент.
• cgroup v2: Для просмотра по службам/контейнерам я использую единая иерархия. Я проверяю с помощью mount | grep cgroup2 и ожидаю cgroup2-Mount (часто /sys/fs/cgroup). Если его нет, я включаю его с помощью параметра ядра systemd.unified_cgroup_hierarchy=1 (Требуется перезапуск).
• Разрешения: Экспортеры на хосте должны иметь права на чтение для /proc/pressure/* и, при необходимости, на /sys/fs/cgroup/*/*.pressure. В контейнерах я монтирую эти пути в режиме «только для чтения».

Использование триггеров PSI: автоматическое реагирование вместо пассивного наблюдения

Помимо временных рядов, я также описываю события с помощью опрос или epoll путем записи пороговых значений и временных интервалов в файлы PSI. Как только нагрузка на ресурс превышает пороговое значение в данном интервале, срабатывает событие, и я запускаю меры по устранению проблемы. Это может быть запуск дополнительного подпроцесса, очистка кэша или временное ограничение Пакетные задания быть. В модулях Systemd я напрямую привязываю эту реакцию к сервисам и свожу задержки к минимуму. Таким образом, мониторинг становится средством управления, а не просто средством Показать.

На практике я использую компактную программу-наблюдатель, которая отслеживает соответствующие *давление*-файлы открываются с помощью write() триггер (несколько или полный (включая пороговое значение и окно в мкс) и затем с помощью epoll блокирующим образом ожидает событий. Таким образом я экономлю циклы опроса и реагирую детерминированно. Я намеренно удлиняю интервалы (например, до 10–30 с), чтобы сгладить переходные процессы, и различаю ресурсы: память реагирует более чувствительно, чем io, процессор должно быть более четким, чтобы сработало.

Экспорт данных из PSI в Prometheus: агенты, метрики, метки

Для временных рядов я собираю данные PSI с помощью специального экспортера или интегрирую значения в существующие агенты, такие как Экспортер узлов. Важно использовать единообразные метки для хоста, cgroup и контейнера, чтобы запросы в Grafana корректно фильтровались. В Kubernetes я дополнительно использую метрики cAdvisor и Kubelet для *_давление_*_ожидание_секунд_всего, чтобы уровни узлов, подсистем и контейнеров оставались совпадающими. Для классических хостов я читаю /proc/pressure/* прямой и папка несколько и полный на отдельные имена метрик. Руководство по интеграции агентов поможет вам начать работу, например, по адресу Настройка Node Exporter.

Подробное описание вариантов экспорта: Node, cgroup и Kubernetes

В зависимости от обстановки я использую разные способы:

• Экспортер узлов (Уровень хоста): Я активирую давление-Collector (если он не включен по умолчанию), например, с помощью --collector.pressure. Он предоставляет такие показатели, как node_pressure_cpu_some_avg10, node_pressure_memory_full_avg60 и node_pressure_io_waiting_seconds_total{state="some|full"}. Последние подходят для rate()-анализы и «Top-N».
• Собственный экспортер cgroup (Уровень сервиса/контейнера): Для получения подробной картины я читаю /sys/fs/cgroup//{cpu,memory,io}.pressure и генерирую такие метрики, как cgroup_pressure_memory_waiting_seconds_total{state="full",cgroup="..."} и avg10/60/300‑Gauges. Я нормализую путь cgroup в качестве метки (cgroup) или папку на сервис/контейнер Метки.
• Kubernetes: На уровне узлов Prometheus собирает данные node‑exporter. Для просмотра контейнеров я использую экспортер DaemonSet с hostPID:true и монтирование в режиме «только для чтения» из /sys/fs/cgroup и /proc, чтобы я мог видеть файлы cgroup хоста. Кроме того, я использую метрики Kubelet/cAdvisor, если они выводят итоговые значения PSI; метки пространство имён, стручок и контейнер В этом я придерживаюсь последовательности.

Мне помогает чёткое Стратегия бренда: экземпляр (хост или имя узла), cgroup (путь), пространство имён/стручок/контейнер (для K8s), а также состояние (несколько/полный) и ресурс (процессор/память/io/irq). Таким образом, я могу выполнять агрегирование на высоком уровне и одновременно выполнять глубокий зум.

Задания по «Прометею», правила записи и примеры запросов

Для четкого анализа я использую два шаблона: процентные индикаторы (avg10/60/300) и производные rate()‑значения на *_общее_количество_секунд_ожидания_*‑счетчики.

• Скрап: 15 секунд — это хорошее начало. Более короткие интервалы увеличивают нагрузку, при этом avg10 но редко приносит дополнительную ценность.
• Правила записи: Я рассчитываю производные временные ряды, чтобы упростить работу с информационными панелями и оповещениями:
  • запись: psi:node_memory_full:avg60 = avg_over_time(node_pressure_memory_full_avg10[60s])
  • запись: psi:node_io_full:rate5m = rate(node_pressure_io_waiting_seconds_total{state="full"}[5m])
  • запись: psi:cgroup_memory_full:rate5m = сумма по (cgroup) (rate(cgroup_pressure_memory_waiting_seconds_total{state="full"}[5m]))

С помощью PromQL я создаю типичные представления:

• Тенденции в сфере хостинга: node_pressure_memory_full_avg60 по времени, с разбивкой по узлам.
• Крупнейшие N источники выбросов: topk(5, psi:cgroup_memory_full:rate5m) показывает самые «громкие» cgroups.
• Влияние на задержку: (increase(http_request_duration_seconds_sum[5m]) / increase(http_request_duration_seconds_count[5m])) против node_pressure_io_full_avg60 проанализировать, чтобы выявить корреляции.
• Распознавание плато: clamp_min(psi:node_io_full:rate5m, 0.0) в виде тепловой карты для каждого узла.

Панели инструментов Grafana: визуализация трендов и выявление проблемных мест

В Grafana я отображаю нагрузку на ЦП, память и ввод-вывод отдельно, соответственно для несколько и полный в виде отдельных графиков. Индикаторы в виде столбчатых диаграмм отображают текущее состояние, а панели временных рядов позволяют выявить пики и плато. Для анализа причин я использую представления «Top-N» по cgroup, контейнерам или под, а оттуда перехожу к панелям с подробными данными. Важное значение имеет сочетание avg10, avg60 и avg300, чтобы избежать перегрузок из-за кратковременных скачков. Тем, кто хочет заранее продумать дизайн информационных панелей, будут полезны идеи, связанные с Grafana и Prometheus Стек.

Оповещение на практике: правила, окна, эскалация

Я следую двухэтапной модели: предупреждение для ранних сигналов, Критический для постоянного узкого места. В качестве примера приведу:

• Память
  • Предупреждение: node_pressure_memory_full_avg60 > 0,01 в течение 10–30 с
  • Критически: node_pressure_memory_full_avg60 > 0,05 в течение ≥60 с
• ВВОД/ВЫВОД
  • Предупреждение: rate(node_pressure_io_waiting_seconds_total{state="some"}[5m]) > 0,02
  • Критически: node_pressure_io_full_avg60 > 0,02 в течение ≥120 с
• CPU
  • Предупреждение: node_pressure_cpu_some_avg60 > 0,05
  • Критически: node_pressure_cpu_full_avg60 > 0,01 (потому что полный (это особенно больно)

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

Пороги и оповещение: правильный выбор временного интервала

Я устанавливаю четкие пороговые значения для каждого ресурса и отделяю серьезные сбои от кратковременных пиков нагрузки. Например, я оцениваю память заполнена значения 5 %, превышающие 60 секунд, считаются критическими, тогда как значения 1–2 %, превышающие десять секунд, вызывают лишь предупреждение. Для ЦП я устанавливаю более строгие ограничения полный, поскольку повсеместные задержки там заметно замедляют работу. Дополнительную ценность приносит связь с показателями пропускной способности и задержки: когда нагрузка растет, а запросы обрабатываются медленнее, степень срочности повышается. Я всегда настраиваю оповещения на временные интервалы, а не на отдельные значения, чтобы избежать ложных срабатываний из-за Взрывы которых следует избегать.

Kubernetes: настройка сбора данных, права доступа и корреляция

В кластере я собираю PSI таким образом, чтобы уровни совпадали:

• Node-Exporter в качестве DaemonSet: Стандартный скрейп для каждого узла предоставляет глобальные значения PSI.
• cgroup-Exporter в качестве Sidecar/DaemonSet: Считывает файлы cgroup v2 хоста, присваивает метки в соответствии с ними пространство имён/под/контейнер. Я использую минимально необходимые права доступа и монтирование RO.
• Kubelet/cAdvisor: Я включаю вывод соответствующих метрик контейнеров и осуществляю скрапинг конечной точки Kubelet. Я сохраняю ключи соединения по меткам (например,. контейнер против. container_name) должны быть согласованы, чтобы соединения PromQL работали без сбоев.
• Join с метриками рабочей нагрузки: Я сопоставляю показатели Pod-PSI с задержками в приложениях (например, HTTP-метриками), превышениями ограничений ЦП и ошибками памяти. Так я определяю, являются ли причиной превышения ограничений, проблемы с планированием или узкие места в хранилище.

Файлы PSI, ключевые показатели и интерпретация: краткий обзор

В приведенной ниже таблице собраны основные файлы, ключевые показатели и области применения, чтобы я мог быстрее их интерпретировать и создавать соответствующие панели Grafana. Я использую её при анализе, чтобы спланировать следующий шаг: настройка, масштабирование или устранение неполадок. Особое значение имеют различия между несколько и полный а также три окна средних значений. Так я сопоставляю симптомы во времени и проверяю, возникает ли давление локально или по всей площади. Колонка „Применение“ помогает быстро Классификация.

Ресурс	Файл	Основные показатели	Значение	Используйте
CPU	/proc/pressure/cpu	некоторые, полностью; среднее 10/60/300; всего	Время ожидания свободного вычислительного времени	Перегруженные хосты, недостаточная производительность ЦПЛимиты
Память	/proc/pressure/memory	некоторые, полностью; среднее 10/60/300; всего	Время ожидания из-за операций Reclaim, Swap и приближения к пределу памяти (OOM)	Нехватка оперативной памяти, перегрузка кэша, неисправные Запросы
ВВОД/ВЫВОД	/proc/pressure/io	некоторые, полностью; среднее 10/60/300; всего	Время ожидания при работе с устройствами хранения/файловой системой	Медленные носители данных, пики синхронизации, Смыв-фазы
IRQ	/proc/pressure/irq	некоторые, полностью; среднее 10/60/300; всего	Печать посредством обработки прерываний	Сетевая нагрузка, настройка драйверов, Affinity
cgroup	*/{cpu,memory,io}.pressure	некоторые, полностью; среднее 10/60/300; всего	Давление на одну заправку/контейнер	Поиск первопричин, целенаправленный Лимиты

Практика: эффективная защита хостинга и стеков WordPress

На сильно загруженных хостингах WordPress PHP-FPM, база данных и кэш-слой регулярно конкурируют за оперативную память и ресурсы ввода-вывода, о чем я узнал из память и io сразу вижу. Поднимается полный Что касается памяти, я оптимизирую OpCache, плавно увеличиваю размеры пулов или сокращаю количество ресурсоемких плагинов. При нагрузке на ввод-вывод я проверяю планы запросов, настройки журналирования и асинхронную запись. Показатель PSI по cgroup позволяет определить, что именно вызывает узкое место: веб-сервер, рабочий процесс или база данных. Те, кто хочет углубиться в эту тему, найдут подсказки в Руководство по Linux-PSI, в котором обобщены введение и оценка.

Планирование мощностей и оптимизация: от цифр к конкретным действиям

Я сопоставляю показатели PSI с загрузкой ЦП, сбоями при обращении к странице, пропускной способностью ввода-вывода и задержками, чтобы выявить истинные причины. В случае продолжающегося память заполнена Я масштабирую объем оперативной памяти, оптимизирую параметры Reclaim или распределяю рабочие нагрузки. Показывает io full При длительных затишьях я увеличиваю глубину очередей, активирую стратегии отложенной записи или использую более быстрые носители. При нагрузке на ЦП я параллельно измеряю длину очередей Runqueue, настраиваю классы планирования и распределяю «горячие» потоки. Решения я принимаю только в том случае, если в avg60 и avg300 оставаться последовательным, а не просто Спайк доступен.

Устранение неполадок и валидация: от хоста до контейнера

Если значения PSI отсутствуют, я проверяю версию ядра, CONFIG_PSI и, при желании, параметр загрузки psi=1. Затем я проверяю вывод файлов в /proc/pressure/* введите их вручную и сверьте с показателями экспортера. В cgroup v2 я дополнительно контролирую *.pressure-файлы в каталогах групп. Я тестирую оповещения с помощью генераторов нагрузки и отслеживаю логику реакции с помощью epoll, чтобы своевременно выявлять ошибки в настройках. В заключение я сверяю панели Grafana с логами, трасами и результатами профилирования, чтобы диагностика и меры по устранению неисправностей были надежными подходит.

Типичные препятствия, которые я принимаю во внимание:

• Взаимодействие свопов: Легкие некоторое количество памяти- Эти значения являются нормальными при агрессивном реклайме. Ситуация становится критической, когда полный растет, а задержки при этом увеличиваются.
• Изоляция процессора и аффинность: Закрепленные/изолированные ядра могут локально процессор загружен на полную мощность генерировать, хотя у хоста в целом ещё есть запас мощности. Я проверяю irq-PSI дополнительно, если сеть/система хранения данных подвержены высокой нагрузке прерываний.
• Виртуальные среды: В виртуальных машинах значения PSI также отражают влияние гипервизора. Я измеряю показатели на уровне хоста и гостевой системы по отдельности, чтобы однозначно определить степень перегрузки.
• Накладные расходы на скрапинг: Сам по себе PSI не требует больших затрат ресурсов, но слишком короткие интервалы сбора данных увеличивают нагрузку на Prometheus. Оптимальным вариантом часто является интервал в 15 с.
• Кардинальность меток: пути cgroup могут разрастаться. Я регулирую это с помощью labeldrop/сохранить и отслеживаю только те уровни, которые я анализирую (например, сервис вместо каждой кратковременной task-cgroup).

Краткое резюме

PSI измеряет реальные время ожидания на ЦП, ОЗУ и ввод-вывод, что служит явным сигналом о нехватке ресурсов. С помощью экспорта данных из Prometheus и дашбордов Grafana я создаю представление, которое позволяет разграничить причины и быстро выявлять «горячие точки». Разделение несколько и полный плюс окна avg10/60/300 позволяет принимать обоснованные решения. Я настраиваю оповещения на определенные периоды, связываю их с задержками и управляю автоматическими реакциями с помощью триггеров. Таким образом, я принимаю обоснованные решения по вопросам пропускной способности, своевременно устраняю узкие места и обеспечиваю бесперебойную работу сервисов в повседневной деятельности отзывчивый.