cAdvisor: Usam Docker? Querem otimizar recursos e poupar dinheiro em subscrições cloud?

Higgs

Olá a todos,

Hoje vou falar-vos de uma ferramenta que considero absolutamente essencial para qualquer pessoa que trabalhe com containers Docker, seja no vosso homelab, em ambientes on-prem, ou na cloud.
Estou a falar do cAdvisor (Container Advisor), uma solução open-source desenvolvida pela Google que nos permite ter visibilidade total sobre o consumo de recursos dos nossos containers.

E sim, antes que perguntem: isto não é só mais uma ferramenta de monitoring. O cAdvisor é o primeiro passo de eficiência, para identificarmos desperdícios, afinarmos limites de recursos, e potencialmente pouparmos centenas ou milhares de euros por mês em infraestrutura cloud. Para quem tem homelab, é a diferença entre ter um servidor a consumir 100W constantemente versus 40W. Se vale a pena? Acreditem que sim.

 

O que é o cAdvisor e porque importa?

O cAdvisor (Container Advisor) é um daemon que recolhe, agrega, processa e exporta informação sobre containers em execução. Desenvolvido pela Google e open-source desde o início, esta ferramenta oferece aos utilizadores de containers uma compreensão detalhada sobre a utilização de recursos e características de performance dos seus containers.
Mas sejamos honestos: há dezenas de ferramentas de monitorização por aí. Porque é que o cAdvisor se destaca?

  • Visibilidade Granular: O cAdvisor não se limita a dizer “este container está a usar 50% de CPU”. Ele diz-vos exatamente quais os cores que está a usar, qual o throttling que está a acontecer, quantas context switches estão a ocorrer, e muito mais. É a diferença entre saber que o carro gasta gasolina e saber exatamente quantos litros aos 100km, em que tipo de estrada, e com que padrão de condução.
  • Zero Configuration para Docker: Apontam o cAdvisor para o Docker socket e pronto. Busca, Busca. Não precisam de modificar containers, adicionar sidecars, ou fazer magia negra com configurações. Simplesmente funciona.
  • Performance Mínima: O cAdvisor foi desenhado para ter overhead mínimo. Estamos a falar de consumo negligível de CPU e memória. É como ter um contador de eletricidade – consome uma fração da energia que mede.
  • Integração Nativa com Ecosistemas de Monitoring: O cAdvisor expõe métricas no formato Prometheus, o que significa integração imediata com toda a stack CNCF (Prometheus, Grafana, Alertmanager, etc.). Para quem usa outras soluções, também suporta exportação para InfluxDB e outros sistemas, ou outputs em json que facilmente podem ser integrados em Zabbix ou Nagios.

Mas porque é que isto importa na era do cloud computing?

Aqui está uma realidade extremamente desagradável que as empresas aprendem quando migram para a cloud: a maioria das empresas está a desperdiçar dinheiro na cloud.
Não por má gestão ou incompetência, mas simplesmente por falta de visibilidade.
Deixem-me dar-vos um exemplo real. Trabalhei com uma empresa-cliente que tinha cerca de 200 containers a correr em AWS ECS. O custo mensal era de aproximadamente €8.000. Depois de implementarem monitoring adequado com cAdvisor e analisarmos os dados durante duas semanas, descobriu-se que:

  • 40% dos containers tinham memory limits definidos para 2GB mas nunca ultrapassavam 512MB
  • 30% dos containers estavam a pedir 2 vCPUs mas usavam consistentemente menos de 0.5 vCPU
  • Cerca de 15% dos containers eram instâncias antigas de serviços já substituídos mas que ninguém tinha desligado

Resultado? Custos mensais reduzidos em €3.200 sem afetar performance. Sim, leram bem. Uma redução de 40% apenas por termos visibilidade adequada e agirmos com base em dados reais.
Para ambientes on-prem ou homelab, a história é semelhante. Cada container que está sobre-provisionado está a consumir recursos que poderiam ser usados para outros serviços. Cada watt desperdiçado é dinheiro que sai do vosso bolso todos os meses, direitinho para a EDP.

O que o cAdvisor realmente mede?

O cAdvisor não é apenas mais um “top” ou “htop” glorificado. É um sistema sofisticado que recolhe métricas detalhadas em múltiplas dimensões:

  • Métricas de CPU: Utilização total, utilização por core, tempo de sistema vs utilizador, throttling (quando o container atinge o seu CPU limit e é forçado a esperar), número de períodos throttled, context switches, e muito mais.
  • Métricas de Memória: Utilização actual, cache, RSS (Resident Set Size), working set (memória ativa), swap usage, page faults, memory pressure indicators, e limites configurados.
  • Métricas de Rede: Bytes transmitidos e recebidos, packets, errors, drops por interface de rede. Isto é crucial para identificar gargalos de rede ou containers que estão a gerar tráfego inesperado.
  • Métricas de Disco: I/O reads e writes, bytes lidos e escritos, operações por segundo. Para aplicações intensivas em I/O (bases de dados, por exemplo), estas métricas são ouro.
  • Métricas de Filesystem: Utilização de espaço, inodes disponíveis, e capacidade total. Já viram um container falhar porque ficou sem inodes, mesmo tendo espaço disponível? Eu já. O cAdvisor permite-vos antecipar estes problemas.
  • Informação de Processo: Número de processos em execução, threads, file descriptors abertos. Útil para detectar resource leaks ou comportamentos anómalos.

Esta granularidade permite-nos não apenas saber o que está a acontecer, mas entender o porquê está a acontecer. E mais importante: permite-nos tomar decisões baseadas em dados, não em gut feelings ou “best practices” genéricas que podem não se aplicar ao nosso caso específico.

cAdvisor vs outras soluções: A comparação honesta

Há muitas ferramentas de monitoring por aí. Então porque escolher o cAdvisor? O que o destaca?

Docker Stats: O docker stats é útil para verificações rápidas, mas é efémero. Não guarda histórico, não permite correlações temporais, e não se integra facilmente com dashboards. É como olhar para o velocímetro do carro versus ter um sistema de telemetria completo.

  • Prometheus + Node Exporter: Excelente solução, mas o Node Exporter dá-vos métricas ao nível do host, não ao nível do container. Conseguem saber que o servidor está a usar 80% de CPU, mas não sabem qual dos 50 containers é o culpado.
  • Datadog, New Relic, etc.: Soluções comerciais fantásticas, mas com custos significativos. Para empresas com orçamentos generosos, são excelentes. Para homelabs, startups, ou empresas conscientes de custos, o cAdvisor oferece 80% da funcionalidade a 0% do custo.
  • Kubernetes Metrics Server: Se estão em Kubernetes, o metrics server é essencial, mas complementar ao cAdvisor. O metrics server fornece métricas agregadas para o scheduler, o cAdvisor fornece métricas detalhadas para observabilidade.

O cAdvisor preenche um nicho específico: visibilidade detalhada ao nível do container, com zero custo, zero lock-in, e integração standard com o ecossistema open-source. Para 90% dos casos de uso, é exatamente o que precisam.

Como fazer deploy do cAdvisor em ambientes docker

Agora a parte prática. Irei  mostrar-vos como fazer deployment do cAdvisor, desde a instalação mais básica até configurações mais avançadas.

Deployment Básico

A forma mais simples de correr o cAdvisor é usar Docker diretamente:

docker run \
--detach \
--name=cadvisor \
--volume=/:/rootfs:ro \
--volume=/var/run:/var/run:ro \
--volume=/sys:/sys:ro \
--volume=/var/lib/docker/:/var/lib/docker:ro \
--volume=/dev/disk/:/dev/disk:ro \
--publish=8080:8080 \
--privileged \
gcr.io/cadvisor/cadvisor:latest

Vamos dissecar o que está escrito acima:

  • Volumes Montados: O cAdvisor precisa de acesso read-only a várias partes do filesystem do host para recolher métricas. O /rootfs dá acesso ao filesystem completo do host, /var/run é onde o Docker socket reside, /sys contém informação do kernel sobre recursos, /var/lib/docker tem dados sobre os containers, e /dev/disk fornece informação sobre dispositivos de armazenamento.
  • Modo Privileged: Sim, o container precisa de correr em modo privileged. Isto é necessário para aceder a certas métricas de sistema. Se estão preocupados com segurança (e deviam estar), vejam a secção de security considerations mais à frente.
  • Porta 8080: O cAdvisor expõe uma UI web na porta 8080 e as métricas Prometheus no endpoint /metrics da mesma porta.

Após executarem este comando, podem aceder a http://localhost:8080 e ver imediatamente métricas de todos os vossos containers. É assim tão simples.

Deployment com docker compose

Para ambientes mais permanentes, recomendo usar Docker Compose. Aqui está um exemplo de docker-compose.yml muito semelhante ao que eu uso pessoalmente:

services:
  cadvisor:
    image: gcr.io/cadvisor/cadvisor:latest
    container_name: cadvisor
    restart: unless-stopped
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:ro
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro
      - /dev/disk/:/dev/disk:ro
    ports:
      - "8080:8080"
    privileged: true
    devices:
      - /dev/kmsg

Para fazer deploy:

docker-compose up -d

A vantagem desta abordagem é a facilidade de gestão. Querem parar o cAdvisor? docker-compose down. Querem ver logs? docker-compose logs -f. Querem atualizar? docker-compose pull && docker-compose up -d.

Integração com Prometheus e Grafana

O verdadeiro poder do cAdvisor vem da integração com Prometheus e Grafana. Aqui está um setup completo:

version: '3.8'

services:
  cadvisor:
    image: gcr.io/cadvisor/cadvisor:latest
    container_name: cadvisor
    restart: unless-stopped
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:ro
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro
      - /dev/disk/:/dev/disk:ro
    ports:
      - "8080:8080"
    privileged: true
    networks:
      - monitoring

  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    restart: unless-stopped
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus-data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
    ports:
      - "9090:9090"
    networks:
      - monitoring

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    restart: unless-stopped
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin
    volumes:
      - grafana-data:/var/lib/grafana
    networks:
      - monitoring

volumes:
  prometheus-data:
  grafana-data:

networks:
  monitoring:
    driver: bridge

E o ficheiro prometheus.yml:

global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'cadvisor'
    static_configs:
      - targets: ['cadvisor:8080']

Com este setup, têm um stack completo de monitoring: o cAdvisor recolhe métricas, o Prometheus armazena-as e permite queries, e o Grafana visualiza tudo com dashboards todos bonitos.

Após fazer deploy deste stack:

  1. Acedam ao Grafana em http://localhost:3000 (user: admin, pass: admin)
  2. Adicionem o Prometheus como data source (URL: http://prometheus:9090)
  3. Importem um dashboard do cAdvisor (recomendo o dashboard ID 14282 do Grafana.com)

E pronto, têm monitoring enterprise-grade sem gastar um cêntimo.

Casos de uso práticos: onde o cAdvisor brilha

Deixem-me partilhar alguns cenários reais onde sei que o cAdvisor salvou o dia:

Identificação de Memory Leaks: Um container Node.js que crashava aleatoriamente a cada 2-3 dias. O docker logs não mostrava nada óbvio. Com o cAdvisor, consegui ver que o memory usage estava a crescer linearmente até atingir o limit e ser killed. Isto levou a equipa de desenvolvimento a investigar memory leaks no código, que eventualmente descobriram e corrigiram.

Otimização de Resource Limits: Uma API em Go que tinha memory limit de 2GB mas nunca ultrapassava 300MB. Reduziu-se o limit para 512MB, libertando 1.5GB por instância. Com 20 replicas, foram 30GB de RAM devolvidos ao cluster para outros usos.

Detecção de CPU Throttling: Um container que processava imagens estava com performance degradada. O cAdvisor mostrou que estava a sofrer CPU throttling severo – estava a atingir o CPU limit e a ser forçado a esperar. Aumentámos o limit em 50% e o throughput duplicou.

Identificação de Noisy Neighbors: Num servidor shared com múltiplos containers, um deles estava a dominar o I/O do disco, afetando todos os outros. O cAdvisor permitiu identificar o culpado e aplicar I/O limits apropriados.

Capacity Planning: Antes de fazer scale-up de infraestrutura, usámos dados do cAdvisor para perceber quais os recursos realmente necessários. Descobrimos que não precisávamos de mais CPU, mas sim de mais RAM. Poupámos dinheiro fazendo um upgrade direcionado em vez de um scale-up genérico.

Métricas que realmente importam: O que devem observar e procurar

Há literalmente centenas de métricas disponíveis no cAdvisor. Quais é que realmente importam? Aqui está o meu top de métricas essenciais:

container_memory_working_set_bytes: Esta é a métrica que o Kubernetes usa para decisões de eviction. Não é a mesma que memory usage total – é a quantidade de memória que realmente está a ser ativamente usada. Se esta métrica está consistentemente abaixo do vosso memory limit, podem reduzi-lo.
container_cpu_usage_seconds_total: CPU usage acumulado. A rate desta métrica dá-vos o CPU usage percentual. Se está consistentemente abaixo de 50% do vosso CPU limit, há margem para otimização.
container_cpu_cfs_throttled_seconds_total: Tempo que o container passou throttled. Se este valor está a crescer significativamente, o vosso container precisa de mais CPU ou tem um problema de performance.
container_network_transmit_bytes_total e container_network_receive_bytes_total: Tráfego de rede. Útil para identificar containers que estão a gerar tráfego inesperado ou para capacity planning de rede.
container_fs_usage_bytes: Uso de filesystem. Crucial para containers que escrevem dados localmente. Já viram aplicações crasharem porque ficaram sem espaço? Esta métrica previne isso.
container_memory_failures_total: Número de vezes que o container tentou alocar memória e falhou. Se este número não é zero, têm um problema sério.

Alertas inteligentes: Transformar dados em acção

Ter métricas é bom. Ter alertas baseados nessas métricas é melhor. Aqui estão algumas regras de alerta que uso e recomendo:

High Memory Usage:

- alert: ContainerHighMemoryUsage
  expr: (container_memory_working_set_bytes / container_spec_memory_limit_bytes) > 0.9
  for: 5m
  annotations:
    summary: "Container {{ $labels.name }} using over 90% of memory limit"

CPU Throttling Excessivo:

- alert: ContainerCPUThrottling
  expr: rate(container_cpu_cfs_throttled_seconds_total[5m]) > 0.3
  for: 10m
  annotations:
    summary: "Container {{ $labels.name }} is being heavily throttled"

Disk Space Crítico:

- alert: ContainerDiskSpaceCritical
  expr: (container_fs_usage_bytes / container_fs_limit_bytes) > 0.85
  for: 5m
  annotations:
    summary: "Container {{ $labels.name }} using over 85% of disk space"

Estes alertas devem ser o vosso early warning system. Não esperem que containers se atirem ao chão para agir.

Security considerations: Sim, o privileged mode é preocupante

Vamos endereçar agora a questão de segurança: o cAdvisor precisa de correr em modo privileged. Isto dá-lhe acesso praticamente ilimitado ao host. É uma preocupação de segurança legítima.
Aqui estão as minhas recomendações:

  • Network Isolation: Corram o cAdvisor numa rede dedicada de monitoring. Não exponham a porta 8080 publicamente – usem reverse proxies com autenticação se precisarem de acesso remoto.
  • Read-Only Volumes: Notem que todos os volumes são montados como read-only (:ro). O cAdvisor não precisa de escrever no host.
  • AppArmor/SELinux: Se o vosso ambiente suporta, usem profiles AppArmor ou políticas SELinux para limitar ainda mais o que o container pode fazer.
  • Imagem Oficial: Usem sempre a imagem oficial do Google (gcr.io/cadvisor/cadvisor). Não usem imagens random do Docker Hub.
  • Updates Regulares: Mantenham a imagem atualizada. A Google mantém o projeto ativamente e lança patches de segurança.

Para ambientes extremamente sensíveis, considerem alternativas que não requerem modo privileged, como o Prometheus Node Exporter combinado com outras ferramentas. Mas para 95% dos casos, o cAdvisor com as precauções acima é perfeitamente aceitável.

Performance e overhead: Quanto custa monitorizar?

Uma pergunta legítima: quanto overhead o cAdvisor adicionado um host possivelmente já sobrecarregado?

Na minha experiência, o overhead é mínimo:

  • CPU: Tipicamente menos de 1% de 1 core, mesmo com dezenas de containers
  • Memória: 50-100MB dependendo do número de containers monitorizados
  • Disco: Negligível – o cAdvisor não escreve dados, apenas os expõe

Foi aplicado em servidores com 50 containers e o cAdvisor consumia consistentemente menos de 80MB de RAM e picos de CPU inferiores a 0.1 core. É completamente negligível comparado com os recursos que está a monitorizar.

Troubleshooting: Quando as coisas correm mal

Claro que nem tudo são rosas e as coisas as vezes correm mal. Aqui estão problemas comuns e como resolvê-los:

  • cAdvisor não mostra alguns containers: Verificar se o Docker socket está corretamente montado (/var/run/docker.sock). Verificar permissões.
  • Métricas não aparecem no Prometheus: Confirmar que o Prometheus consegue alcançar o cAdvisor. Testar com curl http://cadvisor:8080/metrics dentro da rede do Prometheus.
  • Performance degradada após instalar cAdvisor: Raro, mas pode acontecer em sistemas com I/O extremamente limitado. Considerar aumentar o housekeeping_interval no cAdvisor.
  • UI web não carrega: Verificar se não há conflitos de porta. Verificar logs com docker logs cadvisor.

O futuro: cAdvisor e kubernetes

Para quem está em Kubernetes ou planeia migrar, é importante saber que o cAdvisor está integrado no kubelet. Não precisam de o instalar separadamente em cada node – o kubelet já o executa, não fosse ele desenvolvido por quem é.

No entanto, a versão standalone do cAdvisor ainda tem o seu lugar para:

  • Development local com Docker Compose
  • Ambientes on-prem sem Kubernetes
  • Debugging específico onde precisam de mais granularidade
  • CI/CD pipelines onde querem monitorizar builds containerizados

O cAdvisor não é a ferramenta mais sexy ou com mais hype. Mas informação e visiblidade é poder. Não há conferências inteiras dedicadas a ele. Não há certificações ou cursos de €5.000. Mas é absolutamente essencial para qualquer pessoa que leve containers a sério.
Com zero configuração, obtêm visibilidade total sobre o que os vossos containers estão realmente a fazer. Esta visibilidade traduz-se diretamente em:

  • Custos de cloud reduzidos através de right-sizing/Custos energéticos em ter os servidores on-prem sempre a prego
  • Melhor performance através de identificação de bottlenecks
  • Maior reliability através de detecção precoce de problemas
  • Capacity planning baseado em dados reais, não em guesswork

Para homelabs, significa hardware usado eficientemente e contas de eletricidade mais baixas. Para empresas, significa potencialmente milhares de euros poupados por mês.
Se já se têm uma infraestrutura Docker e ainda não instalaram o cAdvisor, façam-no hoje. Levam 5 minutos e os insights que vão obter valem cada segundo.
E para quem já usa o cAdvisor, espero que este post vos tenha dado algumas ideias novas sobre como extrair ainda mais valor desta ferramenta fantástica.
Até ao próximo post, e como sempre, se tiverem dúvidas, sugestões, ou quiserem partilhar as vossas experiências com o cAdvisor, sabem onde me encontrar.

Abraço, Nuno

PS: Para os que não sabem já, o blog tem um rss feeder para nunca perderem um artigo quando sai. Podem o adicionar ao vosso favorito RSS reader através do endereço https://blog.nuneshiggs.com/feed/rss

Related Posts