Todos os produtos
Search

Este produto

    Container Service for Kubernetes:Melhores práticas para observabilidade de contêineres

    Central de documentação

    Container Service for Kubernetes:Melhores práticas para observabilidade de contêineres

    Última atualização: Jul 04, 2026

    O Container Service for Kubernetes (ACK) integra-se nativamente aos serviços de observabilidade da Alibaba Cloud e oferece métricas, logs e traces em quatro camadas: infraestrutura, sistema operacional, contêiner/cluster e aplicação.

    image

    A configuração recomendada de observabilidade abrange três áreas essenciais à estabilidade do cluster:

    • Plano de controle — integridade e capacidade dos componentes principais do Kubernetes

    • Plano de dados — integridade dos nós, armazenamento e componentes de rede

    • Aplicações — status dos pods, logs, APM e rastreamento

    Visão geral dos sinais de observabilidade

    A tabela a seguir mostra as ferramentas que cobrem cada tipo de sinal no ACK:

    Sinal

    Ferramenta

    Cobertura

    Métricas do plano de controle

    Managed Service for Prometheus

    kube-apiserver, etcd, kube-scheduler, kube-controller-manager

    Logs do plano de controle

    Simple Log Service (SLS)

    Armazenamento centralizado de logs para componentes de clusters gerenciados

    Eventos de nó

    ack-node-problem-detector + SLS Event Center

    Retenção de 90 dias; intervalos de verificação de 1 minuto

    Métricas de processos do nó

    CloudMonitor

    Os 5 processos que mais consomem recursos por nó

    Logs de journal do SO do nó

    SLS

    Logs do kubelet, kernel e mecanismo de contêiner

    Métricas de contêiner/Pod

    Managed Service for Prometheus (kubelet + kube-state-metrics)

    CPU, memória, rede e armazenamento por Pod

    Métricas de armazenamento de contêiner

    Managed Service for Prometheus + csi-plugin

    Volumes NAS, CPFS, OSS e disco

    Métricas de rede de contêiner

    Managed Service for Prometheus (kubelet)

    Tráfego de entrada e saída por Pod

    Logs de aplicação

    SLS

    Coleta não intrusiva de logs via stdout ou arquivos de log

    APM / rastreamento distribuído

    Application Real-Time Monitoring Service (ARMS)

    Java, Python, Go, OpenTelemetry

    Monitoramento de frontend

    ARMS Real User Monitoring (RUM)

    Web, mobile, miniapp

    Métricas de GPU

    Managed Service for Prometheus + ack-gpu-exporter

    Métricas compatíveis com NVIDIA DCGM, GPU compartilhada e exclusiva

    Monitoramento de contêiner no nível do kernel

    SysOM

    Problemas de memória, page cache, visibilidade no nível do SO

    Alertas

    Gerenciamento de alertas do ACK

    Conjuntos de regras pré-configurados para nós, Pods, cargas de trabalho e rede

    Lista de verificação para configuração rápida

    Ative estes recursos básicos antes de prosseguir para cada seção:

    1. Implante o ack-node-problem-detector para monitorar eventos de nó.

    2. Ative o Managed Service for Prometheus para obter métricas do cluster e de contêineres.

    3. Conecte o SLS para coletar logs dos pods e dos componentes do plano de controle.

    4. Configure os alert rule sets para exceções em nós, Pods, cargas de trabalho e rede.

    5. Ative o plugin do CloudMonitor nos pools de nós ECS para obter métricas de processos no nível do host.

    Após ativar o monitoramento de eventos e o Prometheus, configure contatos e grupos de contatos para as equipes responsáveis pelos clusters ou aplicações. Em seguida, defina as regras de alerta correspondentes e associe os objetos de notificação a esses grupos.

    1. Plano de controle da infraestrutura do cluster

    image

    O plano de controle gerencia operações de API, agendamento de cargas de trabalho, orquestração de recursos do Kubernetes, provisionamento de recursos na nuvem e armazenamento de metadados. Os principais componentes incluem kube-apiserver, kube-scheduler, kube-controller-manager, cloud-controller-manager e etcd.

    O ACK gerencia totalmente o plano de controle dos clusters gerenciados ACK com garantias de Acordo de Nível de Serviço (SLA). Os recursos abaixo oferecem visibilidade em tempo real da integridade do plano de controle.

    Ative o monitoramento de componentes do plano de controle

    O ACK estende a API RESTful do Kubernetes para permitir que clientes externos e componentes internos ao cluster (como o Prometheus) coletem métricas do plano de controle.

    Colete logs dos componentes do plano de controle

    Os clusters ACK suportam logging centralizado em seus projetos do SLS. Consulte Coletar logs de componentes do plano de controle de clusters gerenciados ACK.

    Configure o gerenciamento de alertas

    O ACK inclui regras de alerta padrão para anomalias essenciais em contêineres. Para adicionar ou personalizar regras:

    2. Plano de dados da infraestrutura do cluster

    Nós do cluster

    Os nós workers do ACK fornecem o ambiente de recursos para executar cargas de trabalho. Embora o Kubernetes possua mecanismos nativos de agendamento, preempção e evicção para tolerar problemas transitórios nos nós, garantir estabilidade abrangente exige monitoramento proativo do estado e da carga de recursos dos nós.

    Monitoramento de eventos com ack-node-problem-detector

    O ack-node-problem-detector é o componente de monitoramento de eventos de nó do ACK. Ele oferece:

    • Compatibilidade total com o Node Problem Detector upstream do Kubernetes

    • Melhorias específicas do ACK para o ambiente de nós do cluster, compatibilidade com SO e mecanismo de contêiner

    • Plugins aprimorados de inspeção de nó com intervalos de verificação de 1 minuto

    • Retenção de dados de eventos por 90 dias via Deployment integrado do kube-eventer, que transmite eventos do Kubernetes para o SLS Event Center e contorna a retenção padrão de 1 hora do etcd

    Quando o ack-node-problem-detector identificar um estado anormal no nó, execute kubectl describe node ${NodeName} para inspecionar a Condition do nó ou visualize a lista de nós na página Nodes no console ACK.

    Para receber alertas sobre falhas na inicialização de pods e endpoints de serviço indisponíveis, configure o gerenciamento de alertas e assine as notificações baseadas em eventos. O monitoramento do SLS também suporta alertas de eventos.

    Itens de verificação suportados: Falhas de GPU detectadas pelo ack-node-problem-detector e Plugins de diagnóstico de nó.

    Monitoramento de processos ECS para nós do cluster

    Cada nó do ACK corresponde a uma instância ECS. Ative o recurso de monitoramento de processos no CloudMonitor para obter:

    • Análise histórica de processos: Os 5 processos que mais consomem recursos por consumo de memória, uso de CPU e descritores de arquivo abertos

    • Monitoramento do SO no nível do host: CPU, memória, rede, uso de disco, contagem de inodes, tráfego de rede e contagem de conexões simultâneas

    Importante

    As configurações de monitoramento de processos aplicam-se apenas aos nós adicionados após a ativação do CloudMonitor em um pool de nós.

    Métricas de host versus métricas de nó

    Ambas medem o uso de recursos, mas diferem em escopo e cálculo:

    Dimensão

    Métricas de host

    Métricas de nó

    Escopo

    Recursos da máquina física ou virtual

    Recursos do mecanismo de contêiner

    Numerador de memória

    Memória total usada por todos os processos (Usage)

    Memória de trabalho total (WorkingSet), incluindo memória alocada, memória usada e page cache

    Denominador de memória

    Capacidade de memória do host (Capacity)

    Memória total alocável (Allocatable), excluindo recursos reservados para o mecanismo de contêiner

    Fórmula

    Usage / Capacity

    WorkingSet / Allocatable

    Para mais informações, consulte Política de reserva de recursos.

    Gerenciamento de alertas para anomalias de nó

    Ative e assine conjuntos de regras de alerta para a integridade dos nós:

    • Alert Rule Set for Node Exceptions — condições anormais de nó

    • Alert Rule Set for Resource Exceptions — violações de limiar de uso de recursos

    Configure-os por meio do gerenciamento de alertas.

    Monitoramento de logs de journal do SO do nó

    O systemd atua como sistema init e gerenciador de serviços em nós Linux. Seu componente journal fornece coleta, armazenamento, consulta em tempo real e análise de logs do sistema.

    Colete e persista logs de journal do SO no SLS em cenários como:

    • Monitoramento de estabilidade do nó (kubelet, kernel do SO)

    • Cargas de trabalho sensíveis a alterações no SO ou no mecanismo de contêiner, como contêineres executados em modo privilegiado, nós com overcommit frequente de recursos ou cargas de trabalho que usam recursos do SO diretamente

    Consulte Coletar logs de journal do systemd do nó.

    Monitoramento de GPU e cargas de trabalho de IA

    Para tarefas de treinamento de IA e machine learning, o ACK oferece monitoramento de integridade da GPU e monitoramento de recursos no nível do pod.

    Componentes de sistema do plano de dados do cluster

    Armazenamento de contêiner

    O ACK suporta os seguintes tipos de armazenamento:

    • Armazenamento local do nó: Discos de sistema, discos de dados, volumes HostPath (não monitorados pelo Kubernetes — exigem monitoramento manual) e volumes emptyDir (gerenciados via Requests e Limits de armazenamento efêmero). O monitoramento de armazenamento efêmero cobre: volumes emptyDir não-tmpfs, arquivos de log de pods nos nós e camadas graváveis de todos os contêineres no pod.

    • Secret/ConfigMap: Usados para metadados de recursos do cluster; sem requisitos rigorosos de monitoramento de armazenamento.

    • Armazenamento externo via PersistentVolumes (PVs) e PersistentVolumeClaims (PVCs): Volumes de disco montados adicionalmente, volumes NAS (Network Attached Storage), volumes Cloud Parallel File Storage (CPFS) e volumes Object Storage Service (OSS).

    O componente csi-plugin expõe métricas de monitoramento para todos os tipos de armazenamento suportados, que o Managed Service for Prometheus coleta em painéis prontos para uso. Para uma visão completa dos tipos de armazenamento suportados e não suportados, consulte Visão geral do monitoramento de armazenamento de contêineres.

    Rede de contêiner

    CoreDNS

    O CoreDNS é o componente de descoberta de serviço DNS do cluster. Monitore:

    • Uso de recursos do CoreDNS no plano de dados

    • A métrica Responses (by rcode) — códigos de resposta de resolução anormais, incluindo NXDOMAIN, SERVFAIL e FormErr

    Configuração recomendada:

    • Usuários do Managed Service for Prometheus: Use os painéis de monitoramento do CoreDNS integrados.

    • Usuários de Prometheus autogerenciado: Configure a coleta de métricas usando métodos de monitoramento do CoreDNS da comunidade.

    • Ative o gerenciamento de alertas e assine:

      • Alert Rule Set for Network Exceptions — falhas no recarregamento de configuração do CoreDNS e anomalias de status

      • Alert Rule Set for Pod Exceptions — status do Pod CoreDNS e problemas de recursos

    • Analise logs do CoreDNS para diagnosticar resoluções lentas e solicitações de domínio de alto risco.

    Ingress

    Ao usar o Ingress para roteamento de tráfego externo, monitore os volumes de tráfego e detalhes das chamadas, além de configurar alertas para estados de roteamento anormais.

    Monitoramento básico de tráfego de rede de contêiner

    Os clusters ACK expõem métricas de contêiner padrão da comunidade por meio do kubelet do nó, cobrindo tráfego de entrada e saída do pod, detecção de tráfego anormal e monitoramento no nível de pacotes.

    Pods configurados com modo HostNetwork herdam o comportamento de rede do processo do host. Nesse caso, as métricas básicas de monitoramento de contêiner não refletem com precisão o tráfego de rede no nível do pod.

    Opções de monitoramento:

    • Managed Service for Prometheus: Visualize métricas de rede no nível do pod diretamente nos painéis de monitoramento de pods.

    • Prometheus autogerenciado: Colete métricas do kubelet usando métodos da comunidade.

    • Monitoramento de rede no nível ECS: Monitore a rede do ECS host no console ECS.

    3. Aplicações do usuário

    Monitoramento de pods de contêiner

    Os pods são a unidade fundamental de implantação de aplicações no ACK. Seu status e consumo de recursos afetam diretamente o desempenho da aplicação.

    Monitoramento de logs de aplicações em contêineres

    O ACK fornece coleta não intrusiva de logs para pods de aplicação. Colete logs de aplicação em clusters ACK e utilize os recursos de análise de logs do SLS para diagnóstico de anomalias e avaliação do status operacional.

    Se as aplicações de negócio não implementarem rotação de arquivos de log, utilize os logs de stdout do pod.

    Monitoramento refinado de memória

    No Kubernetes, o uso de memória do contêiner em tempo real é medido pelo Working Set Size (WSS) — a métrica que o Kubernetes usa para agendamento e alocação de recursos. O WSS inclui:

    • Componentes ativos de memória do kernel do SO (excluindo memória anônima inativa)

    • Componentes de memória da camada do SO

    image.png

    O crescimento anormal do WSS pode disparar eventos PodOOMKilled, pressão de memória no nível do nó e evicções de pod. Um padrão comum ocorre em aplicações Java que usam Log4J ou Logback com configurações padrão de nova I/O (NIO) e arquivos mapeados em memória (mmap):

    • Picos de memória anônima devido a operações frequentes de leitura/escrita sob alto volume de logs

    • Buracos negros de alocação de memória causando crescimento invisível do WSS

    O ACK oferece monitoramento de contêiner no nível do kernel baseado em SysOM para revelar detalhes de memória da camada do SO. Consulte Observar e resolver problemas de memória de contêiner através do SysOM.

    Integre métricas personalizadas de aplicação

    Se sua equipe desenvolve código de aplicação, use o cliente Prometheus para expor métricas específicas do negócio por meio de instrumentação. Colete e visualize essas métricas no Prometheus para criar painéis unificados para as equipes de infraestrutura e aplicação, acelerando a resposta a incidentes e reduzindo o tempo médio de recuperação (MTTR).

    APM e rastreamento distribuído

    O Application Real-Time Monitoring Service (ARMS) fornece monitoramento de desempenho de aplicação (APM) para múltiplos runtimes. Escolha o método de integração com base na linguagem da sua aplicação.

    Linguagem

    Tipo de instrumentação

    Capacidades

    Configuração

    Java

    Não intrusiva (zero alterações de código)

    Topologia da aplicação, mapas de dependência 3D, monitoramento de interface/JVM, captura de exceções e transações lentas

    Monitoramento de aplicação Java

    Python

    Intrusiva (código instrumentado)

    Suporte a Django/Flask/FastAPI; rastreamento de IA/LLM com LlamaIndex/Langchain; topologia, traces, diagnósticos de API

    Instale o ack-onepilot e ajuste o Dockerfile. Consulte Monitoramento de aplicação Python.

    Go

    Instrumentação binária

    Topologia da aplicação, análise de consultas de banco de dados, monitoramento de chamadas de API

    Instale o ack-onepilot e compile com instgo. Consulte Monitoramento de aplicação Go.

    OpenTelemetry

    Intrusiva

    Rastreamento distribuído ponta a ponta, análise de requisições, topologia e análise de dependências

    Managed Service for OpenTelemetry — consulte o Guia de integração para configuração específica por linguagem.

    Monitoramento de frontend

    Para aplicações web, aplicativos móveis e miniapps que atendem usuários externos, ative o recurso Real User Monitoring (RUM) no ARMS. O RUM oferece:

    • Reconstrução completa dos fluxos de interação do usuário

    • Métricas de desempenho: velocidade de carregamento da página e rastreamento de requisições de API

    • Análise de falhas: erros JavaScript e falhas de rede

    • Monitoramento de estabilidade: erros de carregamento JavaScript, travamentos e erros de Aplicação Não Respondendo (ANR)

    • Correlação de logs para acelerar o diagnóstico da causa raiz

    Consulte Integrar aplicações para começar.

    Observabilidade de Service Mesh

    O Alibaba Cloud Service Mesh (ASM) é uma plataforma de service mesh totalmente gerenciada e compatível com Istio open-source. Ele gerencia roteamento e divisão de tráfego, protege a comunicação entre serviços e fornece observabilidade da malha, reduzindo a sobrecarga de desenvolvimento e operações.

    O ASM suporta observabilidade de ciclo de vida completo em três fases operacionais:

    Fase

    Foco

    Dia 0 (planejamento)

    Validar estados de configuração de tráfego durante a liberação do sistema

    Dia 1 (implantação)

    Monitorar distribuição de tráfego em tempo real entre microsserviços

    Dia 2 (manutenção)

    Garantir estabilidade com base em métricas de Objetivo de Nível de Serviço (SLO)

    O ASM fornece capacidades unificadas de observabilidade de Service Mesh por meio de um pipeline de telemetria convergente:

    Observabilidade multicloud e hybrid cloud

    A Distributed Cloud Container Platform for Kubernetes (ACK One) é a plataforma empresarial da Alibaba Cloud para hybrid cloud, gerenciamento multicluster, computação distribuída e recuperação de desastres. Ela oferece:

    • Gerenciamento de clusters entre infraestruturas em qualquer região ou infraestrutura

    • Governança unificada para computação, rede, armazenamento, segurança, monitoramento, logging, jobs, aplicações e tráfego

    • APIs alinhadas à comunidade para integração perfeita

    Observabilidade para clusters registrados no ACK One

    Os clusters registrados no ACK One fornecem as mesmas capacidades de observabilidade que os clusters ACK padrão, incluindo integrações para SLS, Event Center, alertas, ARMS e Managed Service for Prometheus.

    Clusters registrados exigem configuração de rede e autorização adicionais devido a ambientes de rede heterogêneos e sistemas de permissões distintos.

    Monitoramento global do ACK One Fleet

    O ACK One Fleet agrega métricas do Prometheus de múltiplos clusters em um painel de monitoramento unificado por meio de instâncias de agregação global, eliminando a necessidade de comparação manual de métricas entre clusters. Ative o monitoramento global após criar uma instância do ACK One Fleet e associá-la a dois clusters.

    Gerenciamento unificado de alertas

    Gerencie regras de alerta no nível do Fleet para garantir consistência em todos os clusters associados:

    • Gerenciamento centralizado de regras: Crie ou atualize regras de alerta no nível do Fleet e sincronize-as automaticamente com os clusters associados.

    • Alertas diferenciados: Configure regras de alerta específicas por cluster quando clusters individuais exigirem limiares diferentes.

    Observabilidade GitOps

    Monitoramento do Argo Workflows

    O Argo Workflows é um mecanismo de fluxo de trabalho nativo da nuvem para processamento de dados em lote, pipelines de machine learning, automação de infraestrutura e CI/CD. Ao implantar o Argo Workflows no ACK ou usar clusters Kubernetes para fluxos de trabalho Argo distribuídos, ative o seguinte:

    • Persistência de logs com SLS: A coleta de lixo nativa do Kubernetes remove logs de pods e fluxos de trabalho após a limpeza de recursos. Integre o SLS aos clusters de fluxo de trabalho para coletar e persistir logs gerados durante a execução do fluxo. Visualize logs de fluxo de trabalho por meio do Argo CLI ou Argo UI.

    • Monitoramento com Prometheus: Ative o Managed Service for Prometheus para monitorar o status de execução do fluxo de trabalho e a integridade do cluster.

    Observabilidade de aplicações Knative

    O ACK Knative é o framework serverless do ACK construído sobre o Knative da comunidade. O Knative fornece dimensionamento automático orientado a requisições (incluindo scale-to-zero) e gerenciamento de versões com rollouts canário. O ACK Knative adiciona capacidades como redução de latência de cold start retendo instâncias e previsão de carga de trabalho por meio do Advanced Horizontal Pod Autoscaler (AHPA). Consulte Observabilidade do Knative para uma visão geral.