Servidor de banco: Postgres, PgBouncer, Redis e MongoDB

01O que é monitorado

02Como funciona: o que é lido (lista fechada)

• A lista é conferida na sonda antes de escrever no socket: pedido fora dela nunca sai, nem por erro de programa.
• No Postgres a sessão ainda nasce com default_transaction_read_only=on e se identifica como evobits-sonda.
• Privacidade das consultas: do Postgres só sai o texto já normalizado pelo próprio Postgres (WHERE cliente = $1), só de SELECT, INSERT, UPDATE, DELETE, WITH, MERGE e VALUES, cortado em 600 caracteres e passado de novo por um filtro de literais. Do MongoDB só sai a forma da consulta (find {"email": ?}). Nunca um valor de parâmetro. As consultas do próprio usuário do evobits ficam de fora.
• A senha fica cifrada no evobits, presa ao endereço do dispositivo: trocar o endereço pede a senha de novo. Ela nunca volta para a tela.
• A sonda abre uma conexão por leitura, a cada 60 s por padrão. As taxas (por segundo, por minuto) saem da diferença entre duas leituras: a primeira só registra a base.

Por que o usuário com escrita é recusado

O teste da tela "Conectar servidor de banco" confere as permissões do usuário e não deixa conectar quem pode escrever:

• Postgres: recusa superusuário, CREATEROLE, CREATEDB, REPLICATION, BYPASSRLS, CREATE no banco e o papel pg_write_all_data.
• Redis: lê as regras com ACL GETUSER e recusa acesso total (+@all), as categorias @write, @dangerous, @admin, @scripting e comandos de escrita soltos. O usuário default com só requirepass tem acesso total e é recusado.
• MongoDB: lê os privilégios com connectionStatus e recusa qualquer ação que não seja de leitura (por exemplo insert, update, remove, createIndex, enableProfiler). Sem login, recusa.
• PgBouncer: o console não informa as permissões; o degrau fica "não conferido no PgBouncer". Use um usuário de stats_users, nunca um de admin_users.

O motivo: a credencial do evobits é guardada e usada por uma máquina. Se ela vazar, um usuário só de leitura de estatísticas não apaga, não altera e não lê os seus dados de negócio.

03Onde aparece

• Página do dispositivo de banco (Dispositivos > o servidor): os sensores de cada motor e a aba Consultas, com janelas de 1 h, 24 h e 7 d (as consultas ficam 8 dias). Em dispositivo do tipo Servidor ainda sem banco, a aba Consultas mostra o botão para conectar.
• "Quem chama": na aba Consultas do Postgres, cada consulta é casada pela forma normalizada com os spans de banco dos seus serviços instrumentados em Aplicações; aparece o nome dos serviços que fazem aquela consulta. Sem trace casando, aparece em cinza o usuário do banco como palpite.
• Os sensores entram nos dashboards e na lista de sensores como qualquer outro.

04Alertas

Limiares de partida (ajustáveis em cada sensor): consultas lentas, atenção 20 e fora 100 por minuto; esperando bloqueio, 1 e 10; acerto de cache abaixo de 95 % e 90 %; atraso da réplica, 5 s e 30 s; clientes esperando no PgBouncer, 1 e 20; espera máxima no pool, 100 ms e 1000 ms; acertos do Redis abaixo de 80 % e 50 %; chaves despejadas, 1 e 1000. As regras de alerta de dispositivo e sensor valem como sempre.

05Limites e privacidade

• Precisa de sonda 1.0.9 ou mais nova; a sonda tem de alcançar o endereço e a porta do banco (pela rede local, pela VPN ou pela sonda da nuvem, se o banco estiver na internet).
• TLS opcional; o certificado é verificado. Aceitar certificado sem verificar é uma opção explícita, desligada por padrão.
• Lido a cada 60 s; até 20 consultas por leitura na aba Consultas.

06Como conectar

Na página do dispositivo: Adicionar sensor > Servidor de banco (ou o botão da aba Consultas). Escolha o motor, crie o usuário pelo guia abaixo, cole usuário e senha, rode o Teste e escolha o que ler. O endereço é o do dispositivo.

Postgres

No servidor, com psql, como superusuário:

CREATE ROLE evobits_leitura
  LOGIN PASSWORD
  'troque-esta-senha';
GRANT pg_read_all_stats
  TO evobits_leitura;

Para a aba Consultas, ligue o pg_stat_statements: no postgresql.conf, shared_preload_libraries = 'pg_stat_statements', reinicie o Postgres e rode CREATE EXTENSION pg_stat_statements; no banco que você vai informar na tela. Sem ele, os sensores funcionam e a aba Consultas fica vazia. O pg_read_all_stats é o que deixa ver o texto das consultas dos outros usuários.

Deixe só a sonda entrar, no pg_hba.conf:

host all evobits_leitura <ip-da-sonda>/32 scram-sha-256

e recarregue (SELECT pg_reload_conf();). Troque <ip-da-sonda> pelo IP da sonda do dispositivo (a tela de conexão mostra o valor certo). Porta padrão 5432.

PgBouncer

No pgbouncer.ini:

stats_users = evobits

No arquivo de usuários (auth_file, normalmente userlist.txt), uma linha com o usuário e a senha (no formato SCRAM, ou a senha em texto se preferir):

"evobits" "SCRAM-SHA-256$4096:..."

Para gerar o segredo SCRAM, crie o usuário num Postgres qualquer com a mesma senha (SET password_encryption = 'scram-sha-256'; CREATE ROLE evobits LOGIN PASSWORD '...';) e copie SELECT rolpassword FROM pg_authid WHERE rolname = 'evobits';. Nunca ponha esse usuário em admin_users. Recarregue: systemctl reload pgbouncer. Porta padrão 6432. A sonda entra no banco virtual pgbouncer.

Redis

Redis 6 ou mais novo, com ACL, no redis-cli como administrador:

ACL SETUSER evobits on
  >troque-por-uma-senha-longa
  -@all +info +ping
  +acl|whoami +acl|getuser

(no redis-cli é uma linha só). Para guardar o usuário: se o Redis usa arquivo de ACL, ACL SAVE; senão, CONFIG REWRITE. Porta padrão 6379. O +acl|whoami +acl|getuser deixa o teste provar que o usuário não escreve.

MongoDB

No mongosh, como administrador (troque catalogo pelo banco que tem o profiler ligado):

use admin
db.createRole({ role: 'evobitsPerfil',
  privileges: [{ resource: { db: 'catalogo',
    collection: 'system.profile' },
    actions: ['find'] }], roles: [] })
db.createUser({ user: 'evobits',
  pwd: 'troque-por-uma-senha-longa',
  roles: ['evobitsPerfil'] })

O usuário é do banco admin (o login usa authSource=admin). Deixe o profiler ligado no banco, no nível que vocês já usam (por exemplo db.setProfilingLevel(1, { slowms: 100 })): o evobits só lê o nível, nunca liga nem desliga. Porta padrão 27017.

07Como conferir

O Teste da tela mostra os degraus:

• Conexão e login: o motor e a versão, com o tempo.
• Leitura: pg_stat_statements ativo, SHOW POOLS, INFO server ou find em system.profile.
• Sem escrita: "nenhuma" (ou "não conferido no PgBouncer").

Depois de criar os sensores, a primeira leitura só registra a base; os números aparecem na segunda (cerca de 1 minuto). Na aba Consultas, as consultas aparecem com $1 no lugar dos valores.

08Problemas comuns

09Texto para IA

Para pedir a um assistente de código (Claude Code ou afins) que escreva a mudança no seu servidor de banco. Ele só entrega os comandos; você decide quando rodar. Troque os marcadores entre < >; o token fica só na variável EVOBITS_TOKEN.

# Tarefa: preparar o servidor de banco para o evobits ler estatísticas, só leitura

## Objetivo
Criar no servidor de banco (<motor>) um usuário que o evobits usa para ler estatísticas, SEM nenhuma permissão de
escrita, e deixar só a sonda do evobits (<ip-da-sonda>) entrar com ele.

## Contexto
- O evobits lê por uma lista fechada e recusa usuário que possa escrever. O teste do painel confere isso.
- Postgres: `CREATE ROLE evobits_leitura LOGIN PASSWORD '<senha>'; GRANT pg_read_all_stats TO evobits_leitura;`,
  `shared_preload_libraries = 'pg_stat_statements'` no postgresql.conf (exige reinício), `CREATE EXTENSION
  pg_stat_statements;` no banco <banco>, e no pg_hba.conf
  `host all evobits_leitura <ip-da-sonda>/32 scram-sha-256` seguido de `SELECT pg_reload_conf();`.
- PgBouncer: `stats_users = evobits` no pgbouncer.ini, a linha `"evobits" "<segredo SCRAM ou senha>"` no auth_file,
  nunca em admin_users, e `systemctl reload pgbouncer`.
- Redis 6+: `ACL SETUSER evobits on ><senha> -@all +info +ping +acl|whoami +acl|getuser`, depois `ACL SAVE` (com
  arquivo de ACL) ou `CONFIG REWRITE`.
- MongoDB: em `admin`, `db.createRole({ role: 'evobitsPerfil', privileges: [{ resource: { db: '<banco>',
  collection: 'system.profile' }, actions: ['find'] }], roles: [] })` e `db.createUser({ user: 'evobits', pwd:
  '<senha>', roles: ['evobitsPerfil'] })`. O profiler fica como está (não ligue nem desligue sem eu pedir).

## Passos
1. Descubra como o banco é gerenciado neste ambiente (pacote do sistema, contêiner, Ansible, Terraform, Helm) e onde
   ficam os arquivos de configuração.
2. Escreva os comandos ou a mudança de configuração do motor <motor> como no contexto, no formato que o ambiente usa
   (por exemplo uma tarefa Ansible ou um script SQL de migração de infraestrutura).
3. A senha nunca vai escrita: leia de um segredo ou variável (por exemplo EVOBITS_BANCO_SENHA) que eu defino.
4. Mostre o que exige reinício (só o `shared_preload_libraries` do Postgres) e o que é só recarga.
5. Não execute nada em produção: entregue os comandos e espere o meu OK.

## Regras
- Nenhuma permissão além das listadas. Nada de SUPERUSER, CREATEDB, CREATEROLE, readWrite, +@all, admin_users.
- Não grave senha em arquivo versionado nem na resposta.
- Não mude nada além do pedido (nem índices, nem parâmetros de desempenho, nem outros usuários).

## Como saber que deu certo
No painel do evobits, em "Conectar servidor de banco", o Teste mostra: Conexão e login ok com a versão, Leitura ok e
Sem escrita "nenhuma" (no PgBouncer, "não conferido"). Depois de 1 minuto os sensores mostram números.