Ferramentas de monitoramento e observabilidade são essenciais para garantir saúde e performance dos sistemas — mas e quando elas se tornam o agente causador de lentidão, lock ou até indisponibilidade?
Sim, isso acontece. Com mais frequência do que se imagina.
Este artigo traz exemplos reais de quando o monitoramento se tornou o ofensor do sistema monitorado, especialmente em ambientes de bancos de dados — e como você pode evitar isso.
O problema: monitoramento intrusivo
Muitas ferramentas coletam dados com:
- Polling agressivo
- Queries em views pesadas
- Agentes que consomem recursos excessivos (CPU, I/O, locks)
- Scraping em intervalos curtos sem controle adaptativo
Em ambientes de missão crítica, qualquer consumo adicional pode custar caro — e causar exatamente os sintomas que você está tentando evitar: lentidão, deadlocks, I/O wait, escalonamento de recursos, alarmes falsos.
Muitas ferramentas não sabe distinguir nem identificar os melhores horários para executar coletas mais agressivas, nem, tem inteligência para fazer isso em batches, interromper em caso de escalação de recursos, ou, de prejuízo para o ativo monitorado.
Casos Reais Documentados
1. Datadog + PostgreSQL / MySQL
- O postgres.d e mysql.d (integrations do Datadog Agent) executavam queries frequentes em pg_stat_activity, pg_stat_statements, information_schema.tables, etc.
- Impacto real: aumento da latência em queries OLTP, locks indesejados, elevação da CPU em servidores subdimensionados.
Fonte: GitHub Issues e Datadog Docs
2. Zabbix monitorando MySQL em produção
- Templates padrão do Zabbix executam SHOW FULL PROCESSLIST, SHOW ENGINE INNODB STATUS e consultas do tipo SELECT COUNT(*) em tabelas grandes.
- Em horários de pico, causavam lentidão crítica em bancos que processavam milhares de transações por minuto.
- Relatos de DBAs no MySQL Brasil e eventos como Percona Live confirmam esse padrão.
3. Filebeat + Metricbeat em ambientes com alta rotação de logs
- Em aplicações com log intenso (e.g., bancos com binlog ativado), os Beats geram leitura contínua de disco e compressão de dados local, consumindo CPU e aumentando iowait.
- Causaram escalonamento automático de instâncias e aumento de custos sem retorno visível.
4. Oracle OEM (Enterprise Manager)
- Mesmo em soluções corporativas como o Oracle OEM, coletas em views como DBA_HIST e ASH geraram impacto em rotinas de backup e jobs noturnos.
- Em alguns ambientes, DBAs migraram a coleta para réplicas ou reduziram a frequência para evitar interferência.
5. Prometheus + mysqld_exporter / postgres_exporter
- Coleta a cada 15s de métricas detalhadas (e.g., histograma de locks, latência por query) sem throttling adaptativo.
- Causou overload no Prometheus e nas próprias instâncias monitoradas em empresas com dezenas de bancos simultâneos.
Fonte: GitHub Issues dos Exporters
Mas, por que isso acontece?
A maioria dessas ferramentas não diferencia ambientes produtivos de ambientes de teste. Elas partem de uma abordagem genérica, com:
- Foco em coletar o máximo de dados,
- Intervalos de scraping curtos,
- Sem awareness de workload em tempo real,
- E muitas vezes, rodando queries diretamente na instância principal, sem usar réplicas ou métricas derivadas.
Consequências e reflexos:
- I/O adicional que compete com queries do usuário.
- Locks em views e tabelas internas (information_schema, performance_schema, pg_stat_*).
- Consumo de memória pelo agente de coleta, interferindo no buffer pool do banco.
- Alarmes falsos disparando por conta do próprio impacto da ferramenta.
- DBA ou SRE gastando horas caçando um “culpado” que, no fim, é a própria ferramenta de monitoramento.
Boas práticas:
- Use coleta assíncrona sempre que possível.
- Baseie-se em métricas nativas e não invasivas (performance_schema, pg_stat_statements, system views com caches).
- Evite agentes com footprint alto. Prefira coleta leve e com throttling adaptativo.
- Aproveite réplicas secundárias para coletar dados analíticos.
- Implemente monitoramento sobre o monitoramento. Sim, é isso mesmo: veja quanto CPU/RAM/disco sua stack de observabilidade está consumindo.
Pensamento do dia: observabilidade que atrapalha não é observabilidade
Se a ferramenta de monitoramento é mais pesada que o próprio workload, você tem um novo problema — e não uma solução.
Se quiser entender se sua stack atual está gerando esse tipo de efeito colateral, fale com a equipe do Flightdeck. Nascido para ambientes de alta criticidade, ele oferece visibilidade real sem gerar carga significativa no banco monitorado — e sem prometer dashboards bonitos à custa de performance.
Saiba mais sobre o Flightdeck!
Visite nosso canal no youtube e aprenda sobre a plataforma e veja tutoriais
Aprenda sobre monitoramento de banco de dados com ferramentas avançadas aqui.