Containers, clusters e VMs
Docker, Docker Swarm, Kubernetes, Proxmox VE e libvirt são lidos sempre em modo somente leitura. Nada aqui reinicia, remove, escala ou migra container, serviço, pod ou VM.
Docker: saúde por container
Tudo pela API do Docker no socket local. Só container com problema vira check; os demais entram no resumo do host.
| Situação | Quando | Severidade |
|---|---|---|
| OOM | o container foi morto por falta de memória | crítico |
| Restart loop | reiniciou 3 vezes em 10 min, ou está em restarting | crítico |
| Unhealthy | healthcheck falhando | alerta; crítico com 5 falhas seguidas |
| Saiu com erro | parado com exit code ≠ 0 nas últimas 24 h (paradas por sinal, como docker stop, não contam) | alerta |
Preso em created | há mais de 5 min | alerta |
| Recursos | CPU, memória ou PIDs acima de 85/95 %, 85/95 % e 80/95 % do limite por 2 ciclos | alerta / crítico |
- Para ignorar um container:
ignored_containers(nome ou glob) ou a labelargus.monitor=false. - A primeira observação só grava a linha de base: um contador de restarts antigo não vira restart loop.
- Container de task do Swarm que parou é ignorado aqui; a falha aparece nos checks do Swarm.
- Quando o container se recupera ou é removido, o alerta é resolvido sozinho.
Docker Swarm
Além dos checks de nó, quorum, serviço e rede overlay, os managers reportam:
| Check | Quando |
|---|---|
| Task presa | task que deveria estar rodando parada em pending/preparing/starting… há mais de 5 min, com a mensagem do scheduler (ex.: no suitable node). Crítico se o serviço está com 0 réplicas. |
| Falhas de task | 3 tasks failed/rejected em 15 min; crítico se as réplicas estão abaixo do desejado. |
| Quorum | tolerância a falhas zero ou número par de managers (alerta). |
| Resumo do cluster | nós, managers, leader, serviços degradados e tasks presas, que alimentam a página Clusters. |
Por padrão só o leader emite os checks de cluster, para que N managers não gerem N alertas. Use o mesmo
cluster_name em todos os nós para o nome aparecer igual no painel.
Kubernetes
O agente lê o cluster pela API com uma ServiceAccount somente leitura: só GET, sem acesso a secrets,
logs, exec ou proxy de nó. Um único nó é eleito para reportar o cluster, sem coordenação entre os agentes.
Instalação
O time do Argus aplica o RBAC somente leitura no cluster e instala o token e a CA nos nós que vão reportar, em
/etc/argus-agent/k8s/ (modo 0600). No config.yml desses nós:
collectors:
kubernetes:
enabled: true
api_server: https://127.0.0.1:6443 # RKE2/k3s server: apiserver local
cluster_name: rke2-prod # nome na página Clusters
# node_name: cp-1 # só se o nome do nó K8s for diferente do hostnameEleição do reporter
- Candidatos: nós com a label
argus.io/k8s-reporter=true; sem nenhum, os control-planes. - Eleito: o primeiro candidato
Readyem ordem de nome. - Sem candidato
Ready: o primeiro nóReadydo cluster.
Ligue o coletor em pelo menos dois nós para ter failover. Os alertas são do cluster, não do agente: a troca de reporter atualiza o mesmo alerta, sem duplicar nem notificar de novo.
Checks e alertas
| Check | Quando |
|---|---|
| API | token ausente, CA inválida, 401/403, apiserver inacessível, listagem com falha |
| Nó | NotReady (crítico); MemoryPressure, DiskPressure, PIDPressure, NetworkUnavailable (alerta) |
| Workload | réplicas disponíveis abaixo do desejado além do tempo limite (fora de rollout) ou ProgressDeadlineExceeded; crítico com zero disponível |
| Pod | CrashLoopBackOff, erro de imagem, erro de configuração, OOMKilled recente, Pending sem nó, restart loop; agrupado pelo workload dono |
| Eventos | os 200 eventos mais recentes do cluster, só para a seção “Eventos do cluster” (nunca abre alerta) |
Pods são agrupados pelo workload dono: um Deployment com 10 pods em CrashLoop gera um alerta, e um rollout não abre e fecha alertas por nome de pod.
Página do cluster
- Eventos do cluster: tabela com filtro por tipo, namespace e busca. Clicar num evento abre um pop-up com a mensagem completa, objeto, namespace, ocorrências e datas; eventos
Warningtêm o botão Analisar com IA. - Agente IA: o histórico das análises de IA dos alertas e eventos deste cluster, com as leituras que o agente fez e o resumo do relatório.
Proxmox VE, KVM e libvirt
A descoberta identifica hosts de virtualização (/dev/kvm, processos, unidades systemd, /etc/pve,
portas 8006/8007) e liga o coletor quando a confiança é suficiente. Todo comando externo (pvesh,
qm, pct, virsh, systemctl) passa por uma lista de leitura com timeout,
que recusa qualquer verbo de alteração.
- Proxmox: serviços do PVE, quorum e nós do cluster, uso e estado dos storages, VMs, LXC, HA e a API.
- libvirt/KVM: disponibilidade do KVM e do daemon do libvirt.
- VM ou LXC parado não vira crítico por padrão. Só escala se o VMID/CTID estiver em
required_vms/required_lxc, se a VM tiver a tagmonitoredou se o HA do Proxmox reportar erro.
O resultado aparece na seção Virtualização do detalhe do host.