Downloads do Argus Agent

Novidades

O que entrou no Argus nas últimas versões (outubro de 2026).

Instalação

Escolha um dos três caminhos. Todos baixam o binário certo para a arquitetura, conferem o SHA256SUMS e criam o serviço argus-agent no systemd.

curl -fsSL "https://argus-homolog.eulabs.net.br/install-argus-agent.sh?v=$(date +%s)" | sudo bash -s -- \
  --project "Empresa" \
  --site "Matriz" \
  --environment "production" \
  --group "linux" \
  --install-base-url "https://argus-homolog.eulabs.net.br" \
  --server-url "https://argus-api-homolog.eulabs.net.br" \
  --token "token-do-site"

curl -fsSL "https://argus-homolog.eulabs.net.br/install-argus-agent.sh?v=$(date +%s)" -o /tmp/install-argus-agent.sh
sudo bash /tmp/install-argus-agent.sh --interactive

Perfil do site

Quando o host é instalado com um token de site, o instalador busca o perfil daquele site e aplica no /etc/argus-agent/config.yml:

Para ver o que mudaria, sem gravar:

sudo argus-agent config merge --config /etc/argus-agent/config.yml --overlay /tmp/overlay.json --dry-run

Como o agente funciona

Configuração principal

Arquivos instalados no host:

/usr/local/bin/argus-agent
/etc/argus-agent/config.yml
/etc/argus-agent/argus-agent.env
/etc/systemd/system/argus-agent.service
/var/lib/argus-agent/spool

Atualizar o agente

Rode de novo o mesmo comando de instalação (o gerado no Admin, com o token do site). O instalador troca o binário pela versão publicada (veja VERSION), mantém o config.yml atual, aplica o que for novo no perfil do site e reinicia o serviço.

Sem o comando em mãos, use o modo interativo e responda “sim” para manter o token já configurado no host:

curl -fsSL "https://argus-homolog.eulabs.net.br/install-argus-agent.sh?v=$(date +%s)" -o /tmp/install-argus-agent.sh
sudo bash /tmp/install-argus-agent.sh --interactive
sudo systemctl status argus-agent

Coletores opcionais

O agente é instalado com uma configuração segura por padrão. Coletores adicionais podem ficar em auto (ligam se a tecnologia for detectada) ou ser habilitados só nos hosts onde forem necessários.

collectors:
  docker:
    enabled: auto
  docker_swarm:
    enabled: auto
  nginx:
    enabled: auto
    status_url: http://127.0.0.1/nginx_status
  proxmox_ve:
    enabled: auto
    mode: local_readonly

Proxmox VE, libvirt e Kubernetes só reportam em hosts que têm a plataforma instalada: ligados pelo perfil do site num host comum, ficam em silêncio em vez de abrir alerta falso.

Análise por IA (Docker e Swarm)

Em alertas de containers e do Swarm, o botão "Analisar com IA" pede ao agente do próprio host uma coleta somente leitura no Docker (inspect, tasks, nós e últimas linhas de log). O agente só faz consultas fixas no socket do Docker, envia as chaves das variáveis de ambiente (nunca os valores) e mascara segredos nos logs. Nada é alterado no host. Em Kubernetes, a análise lê o cluster com uma permissão própria, também somente leitura. Detalhes em Análise por IA.

ai_investigation:
  enabled: true        # padrão; false desliga a coleta neste host
  log_tail_lines: 60   # máximo 200

Bancos de dados

MySQL, MariaDB e PostgreSQL são monitorados pelo agente do próprio host, com um usuário de monitoramento de privilégio mínimo e sessão somente leitura. A senha fica num arquivo no host e nunca passa pelo Argus. No Host Detail, o botão Configurar credencial gera o SQL do usuário e o bloco abaixo.

sudo install -d -m 0700 /etc/argus-agent/db
sudo install -m 0600 /dev/stdin /etc/argus-agent/db/mysql-p1.pass <<<'senha'

databases:
  enabled: true
  instances:
    - id: mysql-p1                     # estável e sem credencial
      engine: mysql                    # mysql | mariadb | postgresql
      socket: /run/mysqld/mysqld.sock  # ou host + port
      user: argus_monitor
      password_file: /etc/argus-agent/db/mysql-p1.pass
      service: { systemd_unit: mysql.service }
    - id: pg-a
      engine: postgresql
      host: 10.0.0.20
      port: 5432
      database: postgres
      user: argus_monitor
      password_file: /etc/argus-agent/db/pg-a.pass
      tls_ca_file: /etc/argus-agent/db/ca.pem

Kubernetes

O agente lê o cluster pela API com uma ServiceAccount somente leitura (sem acesso a secrets, logs ou exec). Um único nó é eleito para reportar o cluster; ligue o coletor em pelo menos dois nós para ter failover. O token e a CA ficam em /etc/argus-agent/k8s/ (modo 0600), instalados pelo time do Argus. O nó eleito também envia os eventos recentes do cluster, mostrados na página do cluster.

collectors:
  kubernetes:
    enabled: true
    api_server: https://127.0.0.1:6443
    cluster_name: rke2-prod

Logs

A coleta de logs (journald e arquivos) é opcional e fica desligada por padrão. Os logs aparecem no Log Explorer do dashboard.

logs:
  enabled: true
  journald:
    enabled: true
  files:
    enabled: true
    paths:
      - /var/log/syslog
      - /var/log/auth.log
  minimum_severity: info

Alterar IP de teste do gateway

O card Rede e Conectividade do Host Detail usa o coletor network_probe. Para testar um IP fixo em vez do gateway detectado automaticamente, edite /etc/argus-agent/config.yml e configure:

collectors:
  network_probe:
    enabled: true
    target_mode: manual
    target_ip: 38.50.36.126
    target_name: gateway-argus
    ping_enabled: true
    mtr_enabled: false
    traceroute_enabled: false

Depois reinicie e valide:

sudo systemctl restart argus-agent
sudo grep -A10 "network_probe:" /etc/argus-agent/config.yml
ping -c 5 -W 1 38.50.36.126
sudo journalctl -u argus-agent -f

Rotinas e autonomia controlada

O Argus foi desenvolvido para detectar, explicar, notificar e agir com segurança. O agente não executa comandos remotos arbitrários. As rotinas automáticas devem utilizar uma lista explícita de ações permitidas, cooldown, revalidação do estado e registros completos de auditoria.

remediation:
  enabled: true
  default_mode: notify_only
  allow_arbitrary_commands: false
  allowed_actions:
    - docker_disk_cleanup_dry_run
    - docker_disk_cleanup_controlled
    - docker_swarm_save_node
    - journald_vacuum_dry_run
    - journald_vacuum

Quando uma ação exige aprovação, o plano aparece no painel do alerta com “Aprovar correção” e “Rejeitar”. O catálogo completo está em Rotinas e remediação.

As rotinas também podem ser ligadas por site, no perfil do site (Admin → Add Node → "Automático (runbook)"). O servidor nunca amplia o que o host permite em allowed_actions.

Testar limpeza controlada de Docker

Para a limpeza executar sozinha, o servidor e o agent precisam permitir a ação. No servidor, use esta base no .env:

REMEDIATION_ENABLED=true
REMEDIATION_DEFAULT_MODE=safe_auto
DOCKER_DISK_CLEANUP_ENABLED=true
DOCKER_DISK_CLEANUP_MODE=safe_auto
DOCKER_DISK_CLEANUP_ALLOW_VOLUME_PRUNE=false

No agent, o bloco fica fora de collectors::

remediation:
  enabled: true
  default_mode: safe_auto
  mode: safe_auto
  allow_arbitrary_commands: false
  allowed_actions:
    - docker_disk_cleanup_dry_run
    - docker_disk_cleanup_controlled

  docker_disk_cleanup:
    enabled: true
    mode: safe_auto
    partition: /
    threshold_percent: 90
    critical_threshold_percent: 95
    action_delay_seconds: 30
    cooldown_seconds: 86400
    revalidate_after_seconds: 10
    prune_images: true
    prune_build_cache: true
    prune_containers: true
    prune_volumes: false
    allow_volume_prune: false
    truncate_container_logs: true
    container_log_max_size_mb: 100
    truncate_only_if_disk_above_threshold: true

Para forçar um teste, reduza temporariamente os thresholds no host de teste:

collectors:
  filesystem:
    warning_percent: 50
    critical_percent: 60

remediation:
  docker_disk_cleanup:
    threshold_percent: 50
    critical_threshold_percent: 60
    cooldown_seconds: 300

Reinicie, acompanhe e valide:

sudo systemctl restart argus-agent
sudo systemctl status argus-agent
sudo journalctl -u argus-agent -f
df -h /
docker system df

Descoberta de serviços

O mecanismo de descoberta analisa o host e informa ao servidor quais serviços e tecnologias foram encontrados. A descoberta opera em modo somente leitura: não instala pacotes, não inicia ou reinicia serviços e não modifica configurações do sistema.

discovery:
  enabled: true
  mode: safe
  local_only: true
  network_scan_enabled: false
  auto_enable_collectors: true
  auto_enable_requires_credentials: false

Sobre o projeto

O Argus nasceu a partir de desafios reais enfrentados por equipes de NOC, SRE e infraestrutura. Muitas ferramentas de monitoramento conseguem identificar sintomas, mas poucas entregam contexto suficiente para que a equipe compreenda o impacto, encontre a causa provável e tome uma decisão rápida e segura.

A proposta do Argus é centralizar observabilidade, monitoramento, segurança e resposta operacional em uma única plataforma, reduzindo o tempo gasto alternando entre diferentes ferramentas durante um incidente.

O conceito é baseado em três componentes principais:

Mais do que informar que algo está com problema, o Argus busca responder:

O Argus foi projetado com foco em automação segura. A plataforma prioriza descoberta, coleta, correlação, diagnóstico e orientação operacional, evitando ações automáticas destrutivas ou alterações de infraestrutura sem políticas, validações e controles explícitos.

Guia completo

A documentação detalhada, página por página: