Marcio Cunha

Como monitorar logs no Kubernetes com Loki e Promtail sem gastar muito

Aprenda a reduzir os custos de armazenamento de logs em clusters Kubernetes combinando o Grafana Loki com o Promtail de forma eficiente.

Marcio Cunha•6 min
Também disponível em:EnglishEspañol
Resumo
  • A indexação baseada em labels no Loki reduz drasticamente o consumo de armazenamento e memória em comparação com ferramentas tradicionais.
  • O Promtail atua como coletor de logs nos nós do Kubernetes, anexando metadados cruciais sem sobrecarregar o cluster.
  • O uso excessivo de rótulos de alta cardinalidade gera explosão de índices e degrada o desempenho do sistema de monitoramento.
  • A definição rigorosa de fluxos de logs evita a duplicação de dados desnecessários enviados para o armazenamento de longo prazo.
  • O alinhamento entre práticas de observabilidade e políticas de infraestrutura como gestão de configurações de infraestrutura com OPA e Rego garante custos previsíveis.

Por que o armazenamento de logs explode no Kubernetes

Gerenciar logs em ambientes de microsserviços modernos costuma ser um desafio financeiro e operacional. Quando centenas de pods geram gigabytes de texto bruto a cada hora, guardar tudo em bancos de dados tradicionais baseados em índices completos consome recursos absurdos de disco e memória. Na prática, isso significa que grande parte do orçamento de infraestrutura é queimada apenas mantendo registros que raramente serão consultados. A promessa de centralizar a observabilidade muitas vezes esbarra na realidade da fatura do provedor de nuvem ao final do mês, exigindo abordagens mais inteligentes de engenharia.

Para contornar esse gargalo, ferramentas modernas como o Grafana Loki mudam radicalmente o paradigma de indexação. Em vez de criar um índice para cada palavra ou caractere dentro das linhas de log, o Loki indexa apenas metadados específicos chamados labels, como o nome do namespace, o pod ou o container. O restante do log é compactado em arquivos brutos chamados chunks e armazenado em serviços de object storage baratos, como o Amazon S3. Essa arquitetura separa o custo de armazenamento do volume de dados processados, tornando o monitoramento viável mesmo em clusters de grande escala.

No entanto, essa liberdade traz uma armadilha silenciosa conhecida como alta cardinalidade. Se você adicionar rótulos dinâmicos demais, como IDs de usuários ou endereços IP únicos, o sistema criará milhões de combinações de índices, anulando a economia de memória proposta pela ferramenta. É exatamente aqui que entra a necessidade de planejar estratégias rigorosas de filtragem e estruturação, garantindo que apenas as informações vitais recebam rótulos, enquanto dados secundários viajam apenas como parte do corpo da mensagem sem inflar o índice principal.

Como o Promtail coleta e enriquece os logs na ponta

O Promtail é o agente responsável por coletar os registros gerados pelas aplicações e enviá-los ao Loki. Na prática, ele roda como um DaemonSet, ou seja, uma cópia do agente é executada automaticamente em cada nó do seu cluster Kubernetes. Ele monitora os arquivos de log que o próprio motor do container grava no sistema de arquivos do servidor, lê essas linhas em tempo real e aplica transformações antes de realizar o envio oficial pela rede. Esse funcionamento descentralizado impede que o aplicativo principal precise se preocupar com a entrega dos dados de auditoria.

Além de ler os arquivos, o Promtail possui um mecanismo poderoso de descoberta de serviços integrado à API do Kubernetes. Isso significa que ele identifica automaticamente quando um novo pod sobe ou desce, capturando metadados dinâmicos como o rótulo do aplicativo, o nome do arquivo de origem e o namespace correspondente. O trecho a seguir demonstra um exemplo básico de configuração do Promtail para mapear esses metadados iniciais de forma limpa e direta:

scrape_configs:  - job_name: kubernetes-pods    kubernetes_sd_configs:      - role: pod    pipeline_stages:      - docker: {}      - labeldrop:        - stream

Esse mapeamento automático evita o esforço manual de reconfigurar agentes toda vez que uma nova aplicação entra em produção. Contudo, deixar o Promtail absorver absolutamente tudo o que o Kubernetes cospe para fora pode sobrecarregar a rede interna e o próprio Loki. É fundamental estabelecer estágios de processamento para descartar logs ruidosos, como pings de health check repetitivos ou mensagens de depuração desnecessárias, aplicando a mesma disciplina que aplicamos na implementação de isolamento de tráfego com VLANs em clusters Kubernetes para evitar ruído desnecessário na rede.

Evitando a armadilha da alta cardinalidade nos labels

O erro mais comum ao configurar o Loki é tratar os labels como se fossem tags livres de banco de dados relacional. Cada rótulo novo e exclusivo que você cria expande a tabela de índices em memória mantida pelos servidores de ingestão do Loki. Quando essa tabela cresce além da capacidade da memória RAM, o consumo de recursos dispara, provocando lentidão nas buscas e potenciais falhas de estabilidade no cluster de monitoramento. Na prática, um único desenvolvedor desatento pode derrubar o sistema de logs inteiro ao injetar UUIDs dinâmicos diretamente no campo de labels.

Para proteger o ambiente, a regra de ouro é manter os rótulos estáticos e limitados a um conjunto pequeno de valores conhecidos, como o ambiente de execução (produção, homologação), a equipe dona do serviço ou o nome lógico do componente. Qualquer dado variável, como um token de sessão, o corpo de uma requisição HTTP ou o ID de um cliente específico, deve permanecer estritamente dentro do fluxo de texto da linha de log. O Loki permite buscar esses conteúdos textuais usando filtros baseados em expressões regulares ou casamento de substrings durante a consulta, sem a necessidade de criar índices pesados.

Quando a volumetria de logs exige um isolamento severo de redes ou de cargas sensíveis, as equipes também precisam cruzar essas diretrizes com políticas rígidas de segurança corporativa. Garantir que dados sensíveis não vaze para o armazenamento centralizado é uma obrigação regulatória que caminha lado a lado com a otimização de custos. Assim, manter o pipeline limpo protege tanto o orçamento da empresa quanto a conformidade com leis de privacidade de dados.

Passo a passo para configurar a coleta eficiente

Se você deseja colocar essa arquitetura para funcionar no seu cluster sem desperdiçar recursos, siga estas etapas práticas de configuração do coletor e do armazenamento:

  1. Crie um ConfigMap dedicado no Kubernetes contendo as regras de descoberta do Promtail, garantindo que apenas os pods essenciais sejam monitorados ativamente.
  2. Adicione estágios de pipeline no arquivo de configuração para extrair apenas os metadados estáticos fundamentais, descartando rótulos de alta cardinalidade logo na origem.
  3. Implante o Promtail como DaemonSet utilizando um manifesto validado, configurando limites estritos de CPU e memória para proteger os nós do cluster contra picos de leitura.

Esses procedimentos formam a base operacional para manter um ecossistema de observabilidade saudável a longo prazo. Monitorar logs de forma inteligente não significa apenas acumular dados, mas garantir que a informação certa esteja acessível no menor tempo possível e pelo menor custo de infraestrutura. Para complementar essa implementação em produção, vale conferir também nossas análises técnicas sobre Como criar agentes de IA autônomos com LangGraph e Python e Por que o Garbage Collector do Go falha sob alta carga?.

Considerações finais sobre custos e escalabilidade de logs

Adotar o Grafana Loki e o Promtail com uma estratégia restrita de labels transforma radicalmente a eficiência financeira de qualquer operação baseada em Kubernetes. Ao compreender que nem todo dado precisa de um índice dedicado, as equipes de engenharia conseguem escalar o armazenamento de registros de forma linear e previsível, mantendo o foco analítico estritamente no que importa para a resolução de incidentes. O equilíbrio entre automação, filtragem na origem e uso consciente de metadados garante que a observabilidade continue sendo uma aliada estratégica da estabilidade dos sistemas, e não um peso morto no orçamento de tecnologia.