Introdução ao monitoramento de bancos de dados

Imagina que você é o capitão de um navio navegando pelo oceano de dados. Você não quer só que o navio ande. Você quer ter certeza de que ele não vai bater num iceberg de queries demoradas, não vai ser pego de surpresa por uma tempestade de bloqueios, e nem afundar por excesso de conexões. O monitoramento do banco de dados é seu radar, barômetro e sonar, te ajudando a evitar icebergs, tempestades e pânico.

Por que e como monitorar o banco de dados

Monitorar ajuda a garantir que o banco de dados fique estável e que você perceba problemas antes deles virarem desastre. Imagina que, ao invés do serviço cair do nada, você recebe um aviso: "Ei, essa query já tá rodando faz 30 segundos, tem algo estranho aqui". Você já sabe onde tá o gargalo, quem tá segurando o lock, e em que momento o banco quase sufoca por falta de recurso.

Olha só no que vale a pena prestar atenção:

• Atividade de queries e transações. Fique de olho no fluxo das queries igual um operador de trânsito cuida do cruzamento. Quais comandos SQL estão travando os outros? Quem tá sobrecarregando o banco? Essas respostas te dão chance de otimizar tudo sem correria e desespero.

• Uso de recursos. CPU, RAM e espaço em disco são tipo o combustível e o casco do navio. Se algum recurso tá "vazando" ou sobrecarregado, o navio pode parar. O monitoramento mostra onde tá o excesso e te deixa redistribuir a carga.

• Performance das queries. Tem query que parece passageiro chato: pede demais, atrasa os outros e nunca tá feliz. O monitoramento mostra quem é o "fominha" — aí dá pra indexar, reescrever ou trocar.

• Locks e conflitos. Às vezes as queries brigam entre si: uma segura o recurso, outra fica esperando. É tipo alguém segurando a porta pra um lado e outro puxando pro outro. Monitorar esses locks te deixa agir antes que a treta fique séria.

Um monitoramento massa não só diz que o banco tá "vivo". Ele mostra onde a vida do banco pode dar ruim — e te dá tempo de arrumar antes do problema virar real.

Métricas chave pra monitorar no PostgreSQL

Pra entender como tá seu banco de dados, você precisa saber o que olhar. Essas métricas são tipo o "pulso" e a "pressão" do banco. Olha os principais parâmetros:

1. Quantidade de conexões ativas.

   Quantos usuários tão conectados agora? Será que tão tentando derrubar seu banco com queries sem noção? Por exemplo, o pg_stat_activity, que a gente vai ver nas próximas aulas, mostra a atividade atual.

2. Tempo de execução das queries.

   Quais queries rodam rapidinho? E quais acham que já tão aposentadas?

3. Uso de índices.

   Se você tem índices mas não usa, tem algo errado. Dá pra checar isso com o pg_stat_user_indexes.

4. Nível de locks e conflitos.

   É muito usado pra evitar "Deadlocks" (bloqueios mútuos).

5. Carga do processador e uso de memória.

   Por exemplo, quanto recurso do seu servidor o PostgreSQL tá "comendo"?

Como isso fica na prática?

Bora ver um exemplo real. Aqui vai uma query simples pra descobrir o tamanho de um banco específico:

SELECT pg_size_pretty(pg_database_size('nome_do_seu_banco')) AS database_size;

Essa query básica retorna o tamanho do banco num formato fácil de ler — tipo 243 MB ou 1.2 GB. Útil pra sacar rapidinho quanto o banco cresceu ultimamente.

Se quiser ver o tamanho de todos os bancos de uma vez — sem precisar digitar cada nome — pode usar assim:

SELECT datname, pg_size_pretty(pg_database_size(datname)) AS size
FROM pg_database;

Isso já te dá uma visão geral de todos os bancos no servidor — ótimo pra quem administra e quer pegar o "fominha" antes de receber aquele e-mail do host: "Seu espaço tá acabando".