Bancos de dados

MySQL, MariaDB e PostgreSQL são monitorados pelo agente do próprio host, com um usuário de privilégio mínimo e sessão somente leitura. A senha fica num arquivo no host e nunca passa pelo Argus. O servidor do Argus nunca conecta no banco.

O que o Argus não faz

Nada de failover, reset de replicação, skip de evento, KILL, VACUUM, REINDEX, purge, tuning, CREATE EXTENSION ou restart. A única escrita possível é o heartbeat de replicação, opcional e desligado por padrão.

Versões suportadas

Fora da matriz, o que for compatível funciona e o resto aparece como capacidade não suportada.

Usuário de monitoramento

Nunca use root ou superuser. No detalhe do host, o botão Configurar credencial gera o SQL e o bloco de configuração prontos. Referência:

MySQL 8.x

CREATE USER 'argus_monitor'@'<host do agente>' IDENTIFIED BY '<senha forte>' WITH MAX_USER_CONNECTIONS 5;
GRANT PROCESS, REPLICATION CLIENT ON *.* TO 'argus_monitor'@'<host do agente>';
GRANT SELECT ON performance_schema.* TO 'argus_monitor'@'<host do agente>';

MariaDB 10.5.2+

CREATE USER 'argus_monitor'@'<host do agente>' IDENTIFIED BY '<senha forte>' WITH MAX_USER_CONNECTIONS 5;
GRANT PROCESS, REPLICA MONITOR, BINLOG MONITOR ON *.* TO 'argus_monitor'@'<host do agente>';
GRANT SELECT ON performance_schema.* TO 'argus_monitor'@'<host do agente>';  -- se performance_schema=ON

Antes da 10.5.2, use REPLICATION CLIENT. Sem performance_schema não há ranking de consultas.

PostgreSQL 13+

CREATE ROLE argus_monitor WITH LOGIN PASSWORD '<senha forte>' CONNECTION LIMIT 5;
GRANT pg_monitor TO argus_monitor;
-- opcional: confirma a topologia pelo system_identifier
GRANT EXECUTE ON FUNCTION pg_control_system() TO argus_monitor;
GRANT EXECUTE ON FUNCTION pg_control_checkpoint() TO argus_monitor;

O ranking de consultas exige a extensão pg_stat_statements (decisão do DBA). Inclua uma linha no pg_hba.conf para o usuário vindo do host do agente; prefira socket local.

Configuração no agente

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, único por empresa, 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 }   # ou pid_file / container
    - 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

• O agente recusa arquivo de senha legível por outros usuários.
• TLS: socket e loopback sem TLS; qualquer outro endereço TCP usa verificação completa por padrão.
• Sessão somente leitura com timeout por consulta (5 s) e por coleta (20 s); um banco travado não atrasa os outros nem o heartbeat do host.
• Recursos do serviço: CPU, memória, I/O e OOM vêm do cgroup da unit systemd ou do container quando existe.

Depois de editar, sudo systemctl restart argus-agent e confira a instância em Bancos de Dados.

Heartbeat de replicação (opcional)

Sem heartbeat, o atraso é o informado pelo motor. Com ele, o atraso é medido de ponta a ponta e revela réplicas paradas que o motor mostra como NULL ou 0. Exige uma tabela argus_heartbeat.heartbeat no primary com SELECT, UPDATE para o usuário de monitoramento, e relógios sincronizados.

# primary (grava só enquanto é primary; um UPDATE por intervalo)
heartbeat: { enabled: true, table: argus_heartbeat.heartbeat, write: true, write_interval_seconds: 60 }
# réplicas (só leem)
heartbeat: { enabled: true, table: argus_heartbeat.heartbeat, source_id: mysql-p1, write_interval_seconds: 60 }

Evidência de backup (opcional)

O Argus não executa backup nem restore. A ferramenta de backup grava um JSON apontado em backup.status_file:

{"tool": "xtrabackup", "last_success_at": "2026-10-08T03:00:00Z", "last_failure_at": null,
 "duration_seconds": 600, "size_bytes": 10737418240,
 "last_restore_test_at": "2026-10-01T03:00:00Z", "last_restore_test_result": "ok"}

A política de idade máxima é definida por instância no painel; sem política, não há alerta.

Cadastro e topologia

A instância aparece no primeiro envio do agente, ou pode ser cadastrada à mão para que uma réplica que nunca reportou apareça como esperada. Na aba Configuração (papel operador) define-se o papel esperado, o primary de cada réplica, aliases de NAT, atraso intencional, limites próprios, política de backup e manutenção. O vínculo entre primary e réplica é confirmado por evidência (server_uuid, system_identifier, endereço). Uma instância removida do config.yml é aposentada e tem os alertas resolvidos, sem perder o histórico.

Alertas

Réplica quebrada com o primary fora do ar e instância em manutenção ficam com o alerta suprimido (visível, sem notificação).

Consultas e privacidade

• A aba Consultas tem dois rankings: por tempo total e mais lentas (maior média por execução). Exportar CSV baixa as mais lentas, pronto para Excel/LibreOffice em pt-BR.
• O SQL é sanitizado no agente (literais, listas IN, comentários) antes do envio. Isso reduz, mas não elimina, o risco de dado sensível no texto.
• SQL nunca entra em alerta, notificação ou log do Argus.