Visualizar a monitorização do PSI no Linux com o Grafana: compreender e monitorizar corretamente a pressão sobre os recursos

Mostro como linux psi registar com o Prometheus e visualizar no Grafana, para medir a pressão sobre os recursos da CPU, da memória e das E/S como tempo de espera real. Assim, consigo identificar Estrangulamentos numa fase inicial, atribui-as a cgroups ou a contentores e, se necessário, ativa medidas de resposta automatizadas.

Pontos centrais

• Métricas PSI: some/full para CPU, memória, E/S e médias móveis
• Foco no cgroup: Uma perspetiva específica para contentores e serviços, em vez de apenas global
• Condições de ativação de alertas: Utilizar eventos com valores-limite através de poll/epoll
• Grafana: Painéis para tendências, picos e os principais N responsáveis
• Melhores práticas: Limiares, intervalos de tempo, correlação com métricas do sistema

O PSI explicado de forma sucinta: entender a pressão como tempo de espera real

O PSI responde à pergunta: quanto Tempo real As tarefas esperam em vão pela CPU, pela RAM ou pela E/S. Os ficheiros em /proc/pressure/{cpu,memory,io,irq} apresentam duas perspetivas: alguns mostra fases em que algumas tarefas ficam em espera, completo indica momentos em que todas as tarefas não inativas ficam bloqueadas. Avalio ambos os valores separadamente, porque alguns começa mais cedo e completo revela os verdadeiros pontos de paragem. Além disso, utilizo avg10, avg60 e avg300, para distinguir as oscilações de curto prazo das tendências de longo prazo. Através do crescente total-É nessa altura que percebo o quanto a pressão se tem acumulado desde o barco e onde Pontos de acesso mentira.

PSI a nível do sistema vs. PSI do cgroup: escolher o nível certo

Faço uma distinção deliberada entre os valores de pressão globais e a perspetiva por cgroup. Os ficheiros em /proc/pressure/ mostram o sistema como um todo, enquanto o cgroup v2, além disso, cpu.pressure, memory.pressure e io.pressure por grupo. Em ambientes de contentores, utilizo-o para organizar de forma organizada os pods, serviços ou Container . Esta atribuição evita voos às cegas: em vez de ter de adivinhar, vejo diretamente a origem do problema no grupo. Em hosts multi-tenant, separo assim as cargas partilhadas das dedicadas e controlo Limites direcionado.

Verificar os pré-requisitos: ativar o kernel, o PSI e o cgroup v2

Antes de recolher métricas, certifico-me de que a plataforma é adequada:

• Versão do kernel: O PSI está disponível a partir do Linux 4.20. Vou verificar com uname -r e controlo através de zcat /proc/config.gz | grep CONFIG_PSI, se o suporte está integrado.
• Sinalizador de tempo de execução do PSI: Algumas distribuições permitem a utilização de um sinalizador de arranque opcional psi=1, para ativar totalmente o PSI. Utilizo-o quando necessário e verifico se /proc/pressure/* Fornece conteúdos.
• cgroup v2: Para a perspetiva «por serviço/por contentor», utilizo a hierarquia unificada. Vou verificar com mount | grep cgroup2 e espero um cgroup2-Mount (muitas vezes /sys/fs/cgroup). Se não estiver presente, ativo-o através do parâmetro do kernel systemd.unified_cgroup_hierarchy=1 (É necessário reiniciar).
• Autorizações: Os exportadores no servidor precisam de direitos de leitura sobre /proc/pressure/* e, se for caso disso, em /sys/fs/cgroup/*/*.pressure. Nos contentores, monto esses caminhos em modo de leitura apenas.

Utilizar os gatilhos PSI: reagir automaticamente em vez de se limitar a observar

Para além das séries temporais, também apresento acontecimentos através de sondagem ou epoll ao definir valores-limite e intervalos de tempo nos ficheiros PSI. Assim que a pressão sobre os recursos ultrapassar o valor-limite definido nesse intervalo, é acionado um evento e eu inicio medidas corretivas. Isso pode ser um pod adicional, uma limpeza da cache ou a limitação temporária de um Tarefas em lote ser. Nas unidades do Systemd, associo esta reação diretamente aos serviços e mantenho as latências baixas. Assim, a monitorização torna-se um meio de controlo, e não apenas um Mostrar.

Na prática, utilizo um programa Watcher compacto que monitoriza os respetivos *pressão-abre ficheiros, através de write() um gatilho (alguns ou completo (incluindo o valor-limiar e a janela em µs) e, em seguida, com epoll aguarda eventos de forma bloqueante. Desta forma, poupo ciclos de sondagem e reajo de forma determinística. Mantendo as janelas deliberadamente um pouco mais longas (por exemplo, 10–30 s), para filtrar os transientes, e faço a distinção consoante o recurso: memória reage de forma mais sensível do que io, CPU tem de ser mais claro para poder disparar.

Exportar o PSI para o Prometheus: agentes, métricas, etiquetas

Para as séries temporais, recolho os valores PSI através de um exportador específico ou integro os valores em agentes já existentes, como o Exportador de nós. É fundamental utilizar etiquetas consistentes para o host, o cgroup e o contentor, para que as consultas no Grafana filtrem corretamente. No Kubernetes, utilizo também métricas do cAdvisor e do Kubelet para *_pressão_*_segundos_de_espera_total, para que os níveis de nó, pod e contentor permaneçam alinhados. No caso de hosts clássicos, consulto /proc/pressure/* direto e pasta alguns e completo em nomes de métricas separados. Um guia de integração de agentes ajuda na fase inicial, por exemplo, em Configurar o Node Exporter.

Variantes do Exporter em pormenor: Node, cgroup e Kubernetes

Dependendo do contexto, recorro a diferentes abordagens:

• Exportador de nós (Nível do anfitrião): Vou ativar o pressão-Collector (caso não esteja ativo por predefinição), por exemplo, através de --pressão do coletor. Ele fornece métricas como node_pressure_cpu_some_avg10, node_pressure_memory_full_avg60 e node_pressure_io_waiting_seconds_total{state="some|full"}. Estas últimas são adequadas para rate()-Análises e Top-N.
• Exportador de cgroups próprio (Nível de serviço/contentor): Para uma visão mais detalhada, consulto /sys/fs/cgroup//{cpu,memory,io}.pressure e gerar métricas como cgroup_pressure_memory_waiting_seconds_total{state="full",cgroup="..."} e o avg10/60/300‑Gauges. Normalizo o caminho do cgroup como etiqueta (cgroup) ou pasta em serviço/contentor Etiquetas.
• Kubernetes: Ao nível do nó, o Prometheus recolhe dados node‑exporter. Para a visualização de contentores, utilizo um exportador de DaemonSet com hostPID:true e montagens só de leitura de /sys/fs/cgroup e /proc, para que eu consiga ver os ficheiros cgroup do anfitrião. Além disso, recorro às métricas do Kubelet/cAdvisor, desde que estas apresentem os totais PSI; as etiquetas namespace, módulo e contentor Mantenho-me coerente nesse aspeto.

O que me ajuda é uma visão clara Estratégia da marca: instância (Host ou Nome do nó), cgroup (caminho), namespace/módulo/contentor (no caso dos K8) bem como estado (alguns/completo) e recurso (CPU/memória/io/irq). Assim, posso fazer uma agregação ampla e, ao mesmo tempo, ampliar bastante a imagem.

Tarefas do Prometheus, regras de registo e exemplos de consultas

Para obter análises precisas, utilizo dois modelos: medidores de percentagem (avg10/60/300) e derivadas rate()‑Valores nos *_segundos_de_espera_totais_‑contadores.

• Scrape: 15 s é um bom começo. Um tempo mais curto aumenta a carga, o que resulta em avg10 mas raramente acrescenta valor.
• Regras de gravação: Calculo séries temporais derivadas para simplificar os painéis e os alertas:
  • registo: psi:node_memory_full:avg60 = média ao longo do tempo(node_pressure_memory_full_avg10[60s])
  • registo: psi:node_io_full:rate5m = taxa(node_pressure_io_waiting_seconds_total{state="full"}[5m])
  • registo: psi:cgroup_memory_full:rate5m = soma por (cgroup) (taxa(cgroup_pressure_memory_waiting_seconds_total{state="full"}[5m]))

Com o PromQL, crio vistas típicas:

• Tendência de anfitriões: node_pressure_memory_full_avg60 ao longo do tempo, separados por nós.
• Os principais N responsáveis: topk(5, psi:cgroup_memory_full:rate5m) mostra os cgroups mais ruidosos.
• Impacto na latência: (incremento(http_request_duration_seconds_sum[5m]) / incremento(http_request_duration_seconds_count[5m])) contra node_pressure_io_full_avg60 estabelecer, para identificar correlações.
• Identificar platôs: clamp_min(psi:node_io_full:rate5m, 0,0) como um mapa de calor por nó.

Painéis do Grafana: identificar tendências e detetar pontos críticos

No Grafana, apresento separadamente a carga da CPU, da memória e das E/S, respetivamente para alguns e completo como gráficos independentes. Os indicadores de barra mostram-me o estado atual, enquanto os painéis de séries temporais revelam picos e platôs. Para a análise de causas, utilizo as visualizações «Top N» por cgroup, contentor ou pod e, a partir daí, acedo aos painéis de detalhes. O importante continua a ser a combinação entre avg10, avg60 e avg300, para evitar sobrecargas causadas por picos de curta duração. Quem quiser planear antecipadamente os painéis de controlo encontrará ideias úteis sobre o Grafana e Prometheus Pilha.

Alarmes na prática: regras, janelas, escalonamento

Sigo um modelo em duas etapas: Aviso para sinais precoces, Crítico para um estrangulamento permanente. A título de exemplo, coloco:

• Memória
  • Aviso: node_pressure_memory_full_avg60 > 0,01 durante 10–30 s
  • Crítico: node_pressure_memory_full_avg60 > 0,05 durante ≥60 s
• E/S
  • Aviso: rate(node_pressure_io_waiting_seconds_total{state="some"}[5m]) > 0,02
  • Crítico: node_pressure_io_full_avg60 > 0,02 durante ≥120 s
• CPU
  • Aviso: node_pressure_cpu_some_avg60 > 0,05
  • Crítico: node_pressure_cpu_full_avg60 > 0,01 (porque completo (é aqui que dói particularmente)

Nas anotações, associo contextos (top-cgroups, débito, latência) e inicio playbooks: Scale-Up, ajustar limites, ações de cache, limitação de processamento em lote. No caso de eventos recorrentes, dou prioridade às decisões relativas à capacidade.

Limites e alertas: escolher corretamente o intervalo de tempo

Defino valores-limite claros para cada recurso e distingo as falhas graves dos picos de carga de curta duração. Por exemplo, analiso memória cheia Mais de 5 % durante mais de 60 segundos são considerados críticos, enquanto 1–2 % durante mais de dez segundos apenas desencadeiam um aviso. Para a CPU, defino limites mais rigorosos completo, uma vez que o tempo de espera generalizado atrasa visivelmente o sistema. A combinação com métricas de débito e latência traz valor acrescentado: quando a pressão aumenta e os pedidos ficam mais lentos, a urgência aumenta. Defino sempre os alertas com base em intervalos de tempo, e não em valores isolados, para evitar falsos alarmes causados por Explosões a evitar.

Kubernetes: configuração do scraper, direitos e correlação

No cluster, recolho o PSI de forma a que os níveis fiquem alinhados:

• Node-Exporter como DaemonSet: O «Standard-Scrape» por nó fornece valores globais de PSI.
• cgroup-Exporter como Sidecar/DaemonSet: Lê os ficheiros cgroup v2 do anfitrião e atribui etiquetas com base neles namespace/pod/container. Utilizo apenas os direitos e as montagens RO estritamente necessários.
• Kubelet/cAdvisor: Ativo a exibição das métricas relevantes dos contentores e faço o scraping do ponto final do Kubelet. Guardo as chaves de junção de rótulos (por exemplo,. contentor vs. nome_do_contentor) de forma consistente, para que as junções PromQL funcionem sem problemas.
• Join com métricas de carga de trabalho: Estabeleço uma correlação entre o Pod-PSI e as latências das aplicações (por exemplo, métricas HTTP), os casos em que os limites da CPU são atingidos e os erros de memória. Desta forma, consigo identificar se a causa reside nos limites, no agendamento ou em estrangulamentos de armazenamento.

Ficheiros PSI, indicadores e interpretação: visão geral concisa

A tabela seguinte resume os ficheiros, indicadores e finalidades mais importantes, para que eu consiga interpretar mais rapidamente e criar painéis adequados no Grafana. Utilizo-a na análise para planear a próxima questão: afinação, escalabilidade ou resolução de problemas. As diferenças entre alguns e completo bem como as três janelas de média. É assim que organizo os sintomas cronologicamente e verifico se a pressão é localizada ou generalizada. A coluna „Intervenção“ ajuda a identificar rapidamente Classificação.

Recursos	Ficheiro	Números-chave	Significado	Utilização
CPU	/proc/pressure/cpu	algumas, total; média 10/60/300; total	Tempo de espera por tempo de computação disponível	Hosts sobrecarregados, CPU com pouca margem de manobraLimites
Memória	/proc/pressure/memory	algumas, total; média 10/60/300; total	Tempo de espera devido a Reclaim, Swap e situação próxima de OOM	Limitações de RAM, pressão na cache, erros Pedidos
E/S	/proc/pressure/io	algumas, total; média 10/60/300; total	Tempo de espera nos dispositivos de armazenamento/sistema de ficheiros	Suportes de dados lentos, picos de sincronização, Descarga-fases
IRQ	/proc/pressure/irq	algumas, total; média 10/60/300; total	Impressão através do processamento de interrupções	Carga da rede, ajuste dos controladores, Afinidade
cgroup	*/{cpu,memória,io}.pressão	algumas, total; média 10/60/300; total	Pressão por serviço/contentor	Identificação da causa principal, direcionada Limites

Na prática: proteger de forma eficiente os serviços de alojamento e as pilhas do WordPress

Em servidores WordPress com elevado tráfego, o PHP-FPM, a base de dados e a camada de cache competem regularmente pela memória RAM e pelas entradas/saídas (I/O), o que eu verifiquei através de memória e io vejo logo. Aumenta completo No que diz respeito à memória, otimizo o OpCache, aumentei os tamanhos dos pools de forma gradual ou reduzi os plugins mais onerosos. Em caso de pressão de E/S, verifico os planos de consulta, as definições de registo em diário e a gravação assíncrona. O PSI por cgroup permite identificar se o servidor web, o worker ou a base de dados estão a causar o estrangulamento. Quem quiser aprofundar o assunto encontrará orientações no Guia do Linux-PSI, que resume a introdução e a avaliação.

Planeamento de capacidade e otimização: dos números às ações

Associo o PSI à utilização da CPU, às falhas de página, ao débito de E/S e às latências, para identificar as causas reais. Se a situação persistir, memória cheia ajusto a RAM, otimizo os parâmetros de recuperação ou distribuo as cargas de trabalho. Mostra io completo Em períodos de picos prolongados, aumentei as profundidades das filas, ativei estratégias de «write-back» ou utilizei suportes de dados mais rápidos. Em caso de pressão na CPU, medi paralelamente os comprimentos das filas de execução, ajustei as classes de agendamento e redistribuí os threads mais ativos. Só tomo decisões quando se observam tendências no avg60 e avg300 manter a coerência e não ser apenas um Espiga está disponível.

Resolução de problemas e validação: do anfitrião ao contentor

Se faltarem valores PSI, verifico a versão do kernel, CONFIG_PSI e, opcionalmente, o parâmetro de arranque psi=1. Em seguida, verifico o conteúdo dos ficheiros em /proc/pressure/* manualmente e compare-as com as métricas do Exporter. No cgroup v2, controlo também o *.pressão-ficheiros dentro dos diretórios dos grupos. Estou a testar os alertas com geradores de carga e a observar a lógica de resposta através de epoll, para detetar precocemente erros de configuração. Por fim, comparo os painéis do Grafana com os registos, os traços e os resultados do profiler, para que o diagnóstico e as medidas corretivas sejam fiáveis apto.

Dificuldades típicas que tenho em conta:

• Interação de swap: Leve memória alguma- Os valores são normais numa recuperação agressiva. A situação torna-se crítica quando completo aumenta e, ao mesmo tempo, as latências aumentam.
• Isolamento da CPU e afinidade: Os núcleos fixos/isolados podem, localmente, CPU a funcionar a plena capacidade gerar, apesar de o anfitrião ainda ter capacidade disponível. Vou verificar irq-PSI adicional, se a rede/armazenamento estiverem sujeitos a um elevado número de interrupções.
• Ambientes virtuais: Nas máquinas virtuais, os valores PSI refletem também a influência do hipervisor. Medei separadamente os níveis do anfitrião e do convidado, para identificar com clareza o sobrecompromisso.
• Custo adicional do scraping: O PSI em si é económico, mas intervalos de scraping demasiado curtos aumentam a carga do Prometheus. 15 s é, muitas vezes, o ponto ideal.
• Cardinalidade das etiquetas: os caminhos dos cgroups podem ficar demasiado longos. Eu regulo-os com labeldrop/manter e mapeio apenas os níveis que estou a analisar (por exemplo, o serviço, em vez de cada cgroup de tarefas de curta duração).

Brevemente resumido

A PSI mede valores reais tempo de espera na CPU, na RAM e nas E/S, dando assim um sinal claro de pressão sobre os recursos. Com a exportação do Prometheus e os painéis do Grafana, crio uma visualização que distingue as causas e identifica rapidamente os pontos críticos. A separação entre alguns e completo mais as janelas avg10/60/300 torna as decisões mais sólidas. Defino alertas para intervalos de tempo, associo-os a tempos de latência e controlo reações automáticas através de gatilhos. Desta forma, tomo decisões fundamentadas sobre a capacidade, resolvo gargalos atempadamente e mantenho os serviços a funcionar no dia a dia reativo.