Monitoramento de Docker Swarm: guia técnico de produção

O Docker Swarm continua vivo. Apesar de Kubernetes ter dominado o discurso de orquestração, muitos times mantêm clusters Swarm em produção por escolha consciente: menor sobrecarga operacional, curva de aprendizado curta e nativo no Docker Engine. Quando o caso de uso comporta dezenas de nós em vez de centenas, Swarm ainda entrega valor com fricção mínima.

O problema é que a maturidade do ferramental de observabilidade não acompanhou esse uso silencioso. Tutoriais aprofundados ficaram datados, dashboards públicos somem dos repositórios e o time precisa montar a stack peça por peça. Sem visibilidade adequada, o cluster vira uma caixa-preta: services oscilam entre réplicas saudáveis e degradadas, o raft sofre latência sob carga e o ingress mesh perde pacotes silenciosamente.

Este guia consolida o essencial para monitorar um cluster Swarm em produção. Inclui a stack open source recomendada, a configuração do service discovery nativo do Prometheus e os alertas que evitam descobrir o incidente pelo cliente. Por fim, traz a comparação honesta com Kubernetes para quem ainda decide se vale a pena migrar.

O que é Docker Swarm e por que ainda monitorá-lo

Docker Swarm é o orquestrador nativo do Docker Engine. Ele agrupa múltiplas máquinas em um cluster lógico, distribui containers como tasks e mantém o estado desejado de cada service. Diferente de instalar um plano de controle separado, Swarm vive dentro do daemon Docker. Basta executar docker swarm init em um nó e juntar os outros via token.

Esse modelo agrada equipes pequenas e médias. Não há kube-apiserver, etcd separado, controllers, kubelet, kube-proxy nem CNI plugins para gerenciar. O raft consensus interno cuida do estado distribuído, o ingress mesh roteia tráfego para qualquer task disponível e o overlay network conecta containers entre nós sem configuração extra.

Apesar disso, Swarm tem componentes que falham silenciosamente quando ninguém olha. Quorum perdido em managers, services com réplicas pendentes há horas, raft com latência crescente sob pressão e overlay network com perda de pacotes. Por isso o monitoramento é menos opcional do que muitos times assumem.

Arquitetura: o que precisa ser observado em um cluster Swarm

Antes de instalar exporter, vale mapear as camadas que merecem visibilidade. Cada uma tem sintomas próprios e métricas distintas. Misturar tudo em um único dashboard genérico esconde sinais importantes.

A primeira camada é o plano de controle: managers, raft consensus e o estado do cluster. Aqui aparecem latência de raft, mudanças de líder, perda de quorum e tempo de resposta da Docker API. Quando essa camada degrada, todo o cluster fica em risco. Services não conseguem ser atualizados e novos deploys travam.

A segunda camada cobre services e tasks: réplicas desejadas vs disponíveis, restarts inesperados, falhas de health check e tempo entre rollouts. Em seguida, vem a camada de recursos por container, com CPU, memória, I/O de disco e rede. Por fim, a camada de infraestrutura: nós Swarm, capacidade de hardware, overlay networks e ingress mesh.

Métricas essenciais por camada do cluster

Aplicar uma metodologia ajuda a evitar dashboards inflados. O método RED (Rate, Errors, Duration) funciona bem para services que recebem requisições, enquanto a USE (Utilization, Saturation, Errors) cabe nas camadas de infra. A tabela abaixo organiza o mínimo viável por camada.

 
Vale destacar que a métrica de working set memory difere de RSS. Working set conta apenas memória ativa, enquanto RSS inclui páginas que ainda não foram reclamadas. Para alertar sobre OOM iminente, a primeira é mais confiável. Cada uma delas se conecta aos pilares da observabilidade moderna (métricas, logs e traces) que precisam coexistir no mesmo plano para diagnóstico rápido.

Stack open source recomendada para Docker Swarm

A combinação Prometheus + cAdvisor + Node Exporter + Grafana cobre 90% dos casos sem custo de licença. O Prometheus coleta métricas como série temporal. Já o cAdvisor expõe dados de containers, o Node Exporter cobre o nível do nó e o Grafana visualiza tudo. Para logs, Loki + Promtail integram com o mesmo Grafana.

A vantagem dessa stack em Swarm é que cada componente roda como service com modo global, garantindo uma instância por nó automaticamente. Não precisa de operator, controller ou Helm chart: apenas um docker-compose declarativo aplicado via docker stack deploy.

Snippet: cAdvisor e Node Exporter como global services

O trecho abaixo mostra como declarar os exporters em modo global. Cada nó do cluster recebe automaticamente uma réplica e o Prometheus consegue scrapear todos os endpoints via service discovery nativo.

version: "3.8"

services:
  cadvisor:
    image: gcr.io/cadvisor/cadvisor:v0.49.1
    deploy:
      mode: global
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:ro
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro

  node-exporter:
    image: prom/node-exporter:v1.8.2
    deploy:
      mode: global
    command:
      - '--path.rootfs=/host'
    volumes:
      - /:/host:ro,rslave

 
Como alternativa pronta, projetos como Swarmprom empacotam todos esses componentes em um único stack file. Ainda assim, conhecer os blocos individuais ajuda quando precisa adaptar o setup para um requisito específico de produção.

Service discovery nativo do Prometheus

O Prometheus suporta Docker Swarm como provider de service discovery desde a versão 2.20. Isso elimina a necessidade de manter listas estáticas de targets: o coletor descobre nós, services e tasks dinamicamente conforme o cluster muda. Existem três roles de descoberta: nodes, services e tasks.

A role mais útil no dia a dia é tasks, pois cada container vira um target individual. Em seguida, nodes serve para coletar métricas do Node Exporter por host. Já services raramente é usado isoladamente, pois agrega informações que tasks já entrega com mais granularidade.

scrape_configs:
  - job_name: 'swarm-tasks'
    dockerswarm_sd_configs:
      - host: unix:///var/run/docker.sock
        role: tasks
    relabel_configs:
      # Mantém apenas tasks rodando
      - source_labels: [__meta_dockerswarm_task_desired_state]
        regex: running
        action: keep
      # Usa label do service como nome do job
      - source_labels: [__meta_dockerswarm_service_label_prometheus_job]
        target_label: job

 
Para aprofundar nos detalhes de relabel e filtros, consulte a documentação oficial do Prometheus sobre integração com Swarm. Ela cobre os labels disponíveis, conexão via socket vs HTTPS e padrões avançados de filtragem.

Logs distribuídos: drivers e centralização

Métricas mostram quando algo quebrou. Logs explicam o porquê. O Docker Swarm suporta vários logging drivers nativos (json-file, syslog, fluentd, gelf, journald, entre outros). A escolha define o quão fácil será correlacionar incidentes depois.

O driver padrão json-file guarda logs localmente em cada nó. Funciona bem para clusters de uma máquina, mas vira um pesadelo com 10+ nós. Por isso, em produção a recomendação é centralizar. As opções mais comuns hoje são Loki (parcear bem com Grafana e Prometheus), Fluentd encaminhando para Elasticsearch ou Graylog quando a busca textual avançada importa.

Independentemente da escolha, três práticas se mantêm: padronize em JSON estruturado quando possível, inclua service e task_id em todos os eventos e correlacione logs com métricas usando o mesmo timestamp. Sem isso, debugar um incidente vira arqueologia.

Alertas críticos para clusters Swarm

Dashboards são para humanos. Alertas são para silêncios. Sem uma estratégia de alertas bem calibrada, o time vira refém de notificações ou descobre o incidente pelo SLA quebrado. A regra para Swarm é começar com poucos alertas acionáveis. Expanda só quando aparecer um padrão de falha recorrente.

A lista mínima inclui cinco alertas. O primeiro detecta perda de quorum nos managers. Em seguida, vem services com réplicas desejadas diferentes das prontas por mais de cinco minutos. Outro alvo é container reiniciando mais de três vezes em uma janela de quinze minutos. Já a quarta regra sinaliza nó Swarm fora da rede por mais de dois minutos. Por fim, o quinto avisa quando o Prometheus para de coletar targets críticos.

# Réplicas pendentes há mais de 5 minutos
(swarm_service_replicas_desired - swarm_service_replicas_running)
  > 0

# Container reiniciando demais (CrashLoop)
rate(container_restart_count[15m])
  > 0.2

# Memória working set acima de 90% do limite
container_memory_working_set_bytes
  / container_spec_memory_limit_bytes > 0.9

Docker Swarm vs Kubernetes em observabilidade

Comparar Swarm e Kubernetes em produção ajuda a justificar a permanência ou a migração com dados (não com modismo). Em observabilidade, há diferenças reais que pesam dependendo do tamanho da operação. A tabela abaixo foca em dimensões práticas, não em popularidade.

 
A leitura honesta é: para clusters de até algumas dezenas de nós com workloads relativamente estáveis, Swarm continua entregando. Em cenários multi-tenant, com mil pods e times distintos, Kubernetes ganha porque o ferramental de observabilidade evoluiu mais. A decisão não é técnica isoladamente: também depende da capacidade do time.

Boas práticas de produção

Mesmo com a stack rodando, alguns ajustes evitam dor de cabeça em escala. Para começar, configure retenção do Prometheus consciente do disco. Em geral, 15 dias bastam para incidentes recentes, com Thanos ou VictoriaMetrics como tier longo prazo se houver requisito de compliance. A guia oficial de administração de Swarm também recomenda nunca rodar com menos de três managers em produção, pelo quorum do raft.

Em segurança, proteja os endpoints de métricas com Basic Auth ou mTLS: eles expõem dados sensíveis de infraestrutura. Adicionalmente, separe a rede de monitoramento da rede de aplicações via overlay distinto, evitando que tráfego de scrape concorra com tráfego produtivo.

Por fim, faça backup do diretório /var/lib/docker/swarm dos managers e dos volumes persistentes do Prometheus e Grafana. Sem isso, recuperação após falha de hardware vira reconstrução do zero. Ninguém quer fazer isso às três da manhã.

Conclusão

Manter um cluster Docker Swarm em produção sem observabilidade é apostar que nada vai falhar. Infraestrutura, no entanto, não funciona assim. Por outro lado, com a stack certa (Prometheus, cAdvisor, Node Exporter, Grafana, Loki) e alertas calibrados, o time recupera o controle do ambiente. Não precisa migrar para Kubernetes apenas por causa do ferramental.

A decisão entre permanecer no Swarm ou migrar deve ser orientada por dados concretos, não por modismo. Se o cluster atual entrega disponibilidade, o time domina o stack e a observabilidade está bem estabelecida, Swarm continua sendo uma escolha racional. Em contrapartida, quando a operação cresce em complexidade e a comunidade fica isolada, vale reavaliar.

Se você precisa estruturar ou amadurecer a estratégia de monitoramento da sua infraestrutura de containers, o time da OpServices pode ajudar com consultoria de observabilidade e implementação. Fale com nossos especialistas e descubra como elevar a visibilidade do seu cluster sem reinventar a roda.