Como este tema funciona na sua empresa
Infraestrutura é básica — um ou dois servidores, backup manual. Monitoramento é reativo: uptime checado manualmente ou com ping simples, espaço em disco notado quando "disco quase cheio". Ferramentas: Zabbix gratuito, scripts simples. Foco: não deixar cair, saber quando vai cair.
Infraestrutura estruturada — múltiplos servidores, RAID, redundância. Monitoramento ativo de CPU, memória, disco, rede por servidor. Alertas quando métrica passa de limite. Ferramentas: Datadog, New Relic, Prometheus. Revisão semanal/mensal. Foco: saúde preventiva, não reativa.
Infraestrutura em escala — 100+ servidores, múltiplos datacenters, híbrida/multi-cloud. Monitoramento preditivo com ML — prediz falha antes que ocorra. Observabilidade completa (infra + aplicação + negócio). Ferramentas: Splunk, Dynatrace, Elastic. Análise contínua, melhoria automática. Foco: antecipar problema, não reagir.
KPIs de infraestrutura medem saúde dos componentes que sustentam TI: servidores, armazenamento, rede, energia. Diferem de KPIs de aplicação porque focam na "coluna vertebral" — se infra cair, tudo para, independente de aplicação estar ok.
Por que infraestrutura é invisível até quebrar
Problema comum: infraestrutura só recebe atenção quando falha. Quando está rodando bem, ninguém nota. Resultado: degradação silenciosa até colapso repentino.
Exemplo: servidor com 85% de disco cheio. Está funcionando. Administrador não está preocupado. Semanas depois, aplicação para porque não consegue escrever. "Por que não alertou?" Porque ninguém estava monitorando.
Monitoramento proativo de infraestrutura previne isso: você vê degradação, age antes de quebra.
Os 5 grupos de KPIs de infraestrutura
Grupo 1: Utilização de Recursos
Medem quanto de cada recurso está sendo usado.
CPU (processador)
O que mede: % de capacidade de CPU sendo usada.
Métrica importante: não apenas instantâneo, mas série temporal — como está ao longo do dia?
Meta realista: 50–70% é saudável. 80%+ por muito tempo sinaliza saturation. 20% ou menos pode indicar over-provisioning (máquina grande demais).
Cuidado comum: CPU 95% toda hora é sustentável se picos são curtos. CPU 95% contínuo é insustentável — vai quebrar quando puja mais 1%.
Memória (RAM)
O que mede: % de RAM disponível sendo usada.
Meta realista: 60–75% utilização saudável. Acima de 85% prolongado sinaliza falta de capacidade. Menos de 30% indica over-provisioning.
Por que não deixar em 99%: Sistema precisa de buffer para picos. Sem buffer, qualquer pico causa swap (usar disco como RAM, muito mais lento).
Disco (armazenamento)
O que mede: % de capacidade de disco sendo usado.
Meta realista: 70% de ocupação é limite. Acima de 80%, performance degrade. Acima de 90%, risco de falha (aplicação não consegue escrever).
Métrica importante: Não apenas ocupação, mas crescimento — quanto disco se preenche por dia? Quantos dias até encher?
Rede (banda)
O que mede: % de banda de rede (Mbps) sendo usada.
Meta realista: 60–70% de utilização sustentável. Acima de 80% contínuo, picos causa perda de pacote.
Cuidado: "Rede 10Gbps disponível" não significa 10Gbps sempre. Compartilhada entre servidores. Se 5 servidores dividem 10Gbps, cada um tem 2Gbps esperado.
Grupo 2: Saúde de Componentes
Medem "como está cada peça".
Status de RAID array
O que mede: Se disco está degraded, missing, ou ok em array RAID.
Por que importa: RAID tolera perda de disco (por exemplo, RAID 6 tolera 2 discos). Se já está degraded e outro falha, perda total de dados. Monitorar aviso de degradation.
Ação: Disco degraded ? substitua ASAP antes que outro falhe.
Temperatura
O que mede: Temperatura de CPU, disco, sala do servidor.
Meta realista: CPU < 80°C, disco < 50°C, sala < 24°C. Acima disso, componente degrada.
Por que importa: Calor reduz vida útil. Componente muito quente vai falhar mais cedo.
Fan speed (ventilador)
O que mede: RPM de ventilador.
Meta realista: Ventilador deve estar rodando. Se RPM cai a zero (ventilador morreu) ou máximo contínuo (temperatura muito alta), sinal de problema.
Power supply (fonte de energia)
O que mede: Status de fonte de alimentação — ok, warning, falha.
Por que importa: Fonte falhando causa downtime. Monitore antes que falhe.
Grupo 3: Redundância e Disaster Recovery
Medem capacidade de sobreviver a falhas.
Cluster status
O que mede: Se todos nós do cluster estão conectados e sincronizados.
Meta: Todos nós 100% saudáveis. Se um nó sai, aplicação continua no outro.
Alerta: Se cluster ficou de 3 nós para 2, sinal de problema. Investigue antes que terceiro também caia.
Replicação de dados
O que mede: % de dados replicados com sucesso para site secundário.
Meta: 100% de dados críticos replicados, lag < 5 minutos. Se replicação está atrasada, há risco de perda de dados.
Backup status
O que mede: Quantos backups foram bem-sucedidos, quantos falharam, quando foi o último backup bem-sucedido.
Meta realista: 100% de sucesso. Backup que falha é inútil. Se falhou, descobrir por quê ASAP.
Métrica importante: Não apenas "backup completou" — "backup foi testado?" (você sabe que recupera?)
Grupo 4: I/O (Input/Output) — velocidade de leitura e escrita
Medem velocidade de acesso a dados.
Latência de disco (read/write latency)
O que mede: Tempo para ler/escrever dado no disco.
Meta realista: SSD < 5ms, HDD < 15ms. Acima disso, performance de aplicação sofre.
Por que importa: Aplicação esperando disco é lenta para usuário.
IOPS (input/output operations per second)
O que mede: Quantas operações de leitura/escrita o disco consegue fazer por segundo.
Meta realista: SSD moderno: 10.000+ IOPS. HDD: 100–300 IOPS. Se você precisa de 5.000 IOPS e disco oferece 1.000, vai dar bottleneck.
Throughput de rede
O que mede: Megabits por segundo de dados transferindo na rede.
Por que importa: Se replicação de dados entre servidores é lenta, reduz disponibilidade.
Grupo 5: Capacidade (previsão)
Medem quando recursos acabar.
Crescimento de disco (dias até cheio)
O que mede: Dado crescimento atual, quantos dias até disco ficar 100% cheio?
Exemplo: Disco com 70GB de 100GB, crescimento 1GB/dia = 30 dias até cheio. Alerta: ordem já novo disco.
Meta: Sempre ter 30+ dias de buffer antes do limite crítico.
CPU capacity planning
O que mede: Se CPU é suficiente para próximos 6–12 meses de crescimento esperado.
Ação: Se análise de tendência mostra que daqui 6 meses CPU vai estar 90%, já encomenda hardware novo (leva tempo).
Headroom (espaço livre)
O que mede: Quanto de capacidade total ainda está disponível para crescimento.
Meta realista: 30% headroom é conservador. 20% é ok. Menos de 10% é preocupante.
Alertas: defina os certos, evite ruído
Armadilha comum em monitoramento: muitos alertas inúteis. "CPU 80%" todo dia, alertas ignorados, real problema passa despercebido.
Estratégia de alertas
- Crítico (vermelho): Ação imediata necessária. CPU 95%+ por 10 minutos, disco 95%+, componente com falha. On-call é acordado.
- Aviso (amarelo): Investigar amanhã. CPU 80%+ prolongado, disco crescendo rápido, temperatura elevada. Não é emergência.
- Info (azul): Apenas log, sem alerta. Disco 60%, CPU 50%, tudo normal — registra para histórico.
Ajuste de limites
Comece conservador (alertas cedo), depois ajuste baseado em realidade. Se alerta de "CPU 80%" vai 10 vezes/dia e nuncaé emergência, levante para 90% ou ignore.
Manutenção preventiva baseada em dados
Ao invés de "trocar disco a cada X anos", troque quando dados sinalizam degradação.
Exemplos
- Disco SMART failing: SMART (Self-Monitoring, Analysis and Reporting Technology) é sensor que sinaliza falha iminente. Baseado nisso (não em calendário), troque disco.
- Fan speed baixando: Fan está envelhecendo. Troque antes que morra.
- Temperatura subindo: Provavelmente poeira no radiador. Limpe antes que componente queime.
Resultado: manutenção preventiva que realmente previne, não "manutenção by calendar" que não faz sentido.
Sinais de que sua empresa precisa monitorar infraestrutura
Se você se reconhece em dois ou mais cenários abaixo, é hora:
- Infraestrutura quebra sem aviso — "disco cheio de repente", "CPU sempre em 100%"
- Você não sabe quanto tempo até disco encher ou quanto headroom tem
- Backup não é testado ou você não sabe se está funcionando
- Você não monitora saúde de componentes (RAID, temperatura, fonte)
- Manutenção é por calendário ("trocar disco a cada 3 anos") vs. baseado em dados
- Você perdeu dados ou teve downtime que poderia ser prevenido com monitoramento
- Crescimento de infraestrutura não é planejado — "ah, precisa de mais espaço"
Caminhos para estruturar monitoramento de infraestrutura
Seu admin/DevOps estrutura monitoramento usando Zabbix (open source), Prometheus (observabilidade), ou ferramentas nativas (vSphere, Hyper-V). Configura alertas, apresenta dados.
- Perfil necessário: Admin de sistema ou DevOps experiente, familiar com infraestrutura
- Tempo estimado: 1–2 semanas para setup (ferramentas), 2–4 semanas para calibrar alertas
- Faz sentido quando: Você tem profissional competente, quer custo baixo, máximo controle
- Risco principal: Alertas não calibrados (muito ruído) ou métricas irrelevantes (muito técnico, pouco prático)
Consultoria ou fornecedor de ferramentas (Datadog, New Relic, Splunk) desenha monitoramento, implementa, treina equipe. Ajusta alertas baseado em SLOs da empresa.
- Tipo de fornecedor: Consultoria de infraestrutura, vendedor de ferramentas com profissional de implementação, especialista em observabilidade
- Vantagem: Desenho alinhado a SLA da empresa, implementação rápida, suporte no vendor
- Faz sentido quando: Você quer implementação rápida, alinhamento com SLA, acesso a suporte vendor
- Resultado típico: Monitoramento desenhado em 1–2 semanas, implementado em 2–4 semanas, alertas calibrados em 1 mês
Precisa estruturar monitoramento e observabilidade de infraestrutura?
Se saúde de infraestrutura é prioridade, oHub conecta você gratuitamente com especialistas em monitoramento, observabilidade, e DevOps. Você descreve o desafio, recebe propostas, e decide sem compromisso em menos de 3 minutos.
Encontrar fornecedores de TI no oHub
Sem custo, sem compromisso. Você recebe propostas e decide se e com quem avançar.
Perguntas frequentes
Como medir saúde de infraestrutura de TI?
Meça utilização (CPU, memória, disco, rede), saúde de componentes (RAID, temperatura, fonte), redundância (cluster status, replicação, backup). Use ferramentas: Zabbix (open source), Prometheus, Datadog, New Relic. Revise semanalmente ou quando alerta dispara.
Quais são os alertas essenciais de infra?
Crítico: CPU 95%+, disco 95%+, componente com falha. Aviso: CPU 80%+, disco 80%+, temperatura elevada, fan speed baixa. Info: crescimento de disco, degradação de RAID. Ajuste limites à realidade para evitar alertas inúteis.
Como predizer falha de infraestrutura?
Use tendência de dados: SMART de disco, temperatura subindo, latência de I/O degradando. Ferramentas com ML (Dynatrace, Splunk) identificam padrões de falha iminente. Backup testado é "seguro de vida" — se falha ocorre, recupera.
Como reportar saúde de infra para gestão?
Dashboard simples: uptime de sistemas críticos (99%?), capacidade (quantos dias até disco cheio?), incident de infra (quantos por mês?), backup status (100% sucesso?). Uma página, mês comparado a anterior. 5 minutos de apresentação.
Como avaliar capacidade de infraestrutura?
Meça utilização atual, crescimento por mês, projete próximos 6–12 meses. Se em 6 meses disco estará 90% cheio, CPU 80%, já encomenda hardware novo. Planeje com antecedência (hardware leva tempo).
Fontes e referências
- Amazon Web Services. AWS Well-Architected Framework — Reliability Pillar. Best practices para confiabilidade de infraestrutura.
- Google Cloud. Monitoring and Alerting Best Practices. Guia de monitoramento e alertas de infraestrutura.
- Prometheus. Monitoring and Alerting Toolkit. Ferramenta open source de monitoramento de infraestrutura.