Monitoramento de infraestrutura de TI: o que medir em cada camada e com que limiar

Autor: Pedro Tebaldi PM do KeepGreen| Revisão técnica: Ednilson Correa SRE

Publicado abr/2014Atualizado ago/2026

Em 57% dos casos, a falha mais recente de grande porte custou mais de US$ 100 mil. Em uma a cada cinco, o prejuízo passou de US$ 1 milhão. Os números vêm do levantamento anual de interrupções em data centers.

Ainda assim, nenhuma dessas operações estava sem ferramenta de coleta. Elas estavam sem saber o que a coleta deveria vigiar. Hoje, ligar um agente em trezentos servidores é trivial. Contudo, o trabalho difícil vem depois.

Ele consiste em decidir a partir de que valor aquela CPU vira chamado. Além disso, é preciso definir por quanto tempo o desvio precisa durar antes de acordar alguém. Portanto, o problema raramente é cobertura. Em geral, o problema é critério.

Este texto percorre a infraestrutura camada por camada. Para cada uma, ele traz o sinal que importa, o limiar de partida e o motivo por trás desse limiar. Em seguida, apresenta a ordem de instrumentação para quem não consegue cobrir o parque inteiro de uma vez.

O que entra em infraestrutura de TI quando o assunto é monitoração

Monitoramento de infraestrutura de TI é a coleta contínua de sinais das camadas que sustentam um serviço. Entram aí rede, servidor e sistema operacional, virtualização, contêiner, storage e banco de dados.

Ele responde por disponibilidade e por saturação de recurso, nunca pela lógica da aplicação. Portanto, quando o escopo fica implícito, sobra ponto cego entre duas camadas. Esse vão costuma aparecer no pior momento possível.

O mercado nomeia o recorte como ITIM, sigla de IT Infrastructure Monitoring. Ao lado dele convivem o APM, voltado ao comportamento da aplicação, além do NPMD, que analisa fluxo e integridade de tráfego. Os três se sobrepõem em várias métricas. Ainda assim, cada um responde a uma pergunta diferente.

Vale dizer também o que fica de fora desse escopo. Regra de negócio, jornada do usuário e comportamento de código não pertencem à monitoração de infraestrutura. Do mesmo modo, evento de segurança pede correlação própria e retenção diferente. Misturar esses domínios no mesmo console produz um painel que ninguém consegue interpretar em plantão.

Essa distinção tem consequência prática na hora de contratar. Uma equipe que compra ITIM esperando diagnóstico de código descobre o vão tarde. Em geral, a descoberta acontece durante um incidente, com todo mundo na mesma sala. Por isso, vale começar pelo mapa do que cada recorte enxerga.

Monitoramento de infraestrutura e monitoramento de aplicações: o que cada um enxerga

A separação mais barata de explicar é por origem do dado. A monitoração de infraestrutura pergunta ao recurso como ele está: interface, processo, volume, instância.

Já o monitoramento de aplicações pergunta à transação como ela correu, do primeiro clique até a resposta do banco. Ou seja, um mede o que sustenta. O outro mede o que foi entregue.

A penúltima linha da tabela é onde nascem quase todas as discussões de plantão. O recurso aparece verde. A transação está lenta. Como resultado, cada equipe mostra o próprio painel e a reunião vira arbitragem de gráficos.

Vale destacar também onde a monitoração termina e a observabilidade começa. Monitoração responde a perguntas que você já sabia fazer. Em contrapartida, observabilidade permite formular perguntas novas durante o incidente, sem subir código.

Camada de rede: o que medir e a partir de que limiar

Antes de tudo, a rede entrega quatro sinais que raramente mentem: utilização, descarte, erro e latência. Cada um pede um limiar de partida diferente. Além disso, nenhum deles funciona como número absoluto isolado do enlace.

Utilização, descarte e erro

Comece pela utilização de link acima de 70% sustentada em cinco minutos. Entretanto, a média de cinco minutos esconde microrrajadas que já encheram o buffer. Por isso, prefira o limiar calculado a partir da linha de base.

Por outro lado, o descarte de pacote pede rigor maior. Em enlace de WAN, qualquer descarte sustentado acima de 0,1% já degrada TCP por retransmissão. Nesse sentido, a leitura de fluxo por NetFlow e sFlow devolve conversação, porta e aplicação.

Erro de CRC, por outro lado, não tem limiar percentual defensável. Contador de CRC crescendo aponta problema físico em cabo, conector ou transceptor. Logo, o número certo é zero. Ainda assim, muitos ambientes só descobrem o cabo ruim quando a aplicação começa a cair.

Latência e a armadilha do número redondo

Latência não aceita limiar de catálogo. Um enlace de fibra metropolitana opera em poucos milissegundos. Já um rádio ponto a ponto de área florestal opera em dezenas.

Portanto, o alarme correto compara o valor atual com a linha de base daquele enlace. A comparação vale para o mesmo dia da semana e para a mesma faixa de horário. Dessa forma, o pico de segunda-feira de manhã deixa de acordar o plantão.

Esse padrão se repete em quase toda métrica de infraestrutura. Em síntese, o número redondo copiado de um guia genérico não sobrevive nem ao primeiro fechamento contábil.

Jitter e perda em tráfego sensível

Voz e vídeo quebram antes dos dados. Um enlace que transporta telefonia começa a degradar com jitter acima de 30 ms, mesmo com banda sobrando. Por isso, tratar voz com o limiar de tráfego comum atrasa o diagnóstico.

A perda de pacote tem o mesmo comportamento assimétrico. Ela passa despercebida numa transferência de arquivo, porém corta sílabas numa ligação. Assim, o alarme de voz precisa de limiar próprio e de janela de sustentação mais curta que a do restante da rede.

Camada de servidor e sistema operacional: os quatro sinais que não mentem

No servidor, a tentação é medir o que o painel oferece pronto. CPU, memória, disco e rede aparecem em qualquer agente. Justamente por isso, a maioria dos ambientes coleta os quatro sem tirar decisão de nenhum deles.

CPU e memória: o sinal atrás do sinal

CPU sustentada acima de 85% por quinze minutos serve como ponto de partida. Contudo, o sinal mais útil costuma ser outro, como mostram as métricas de servidor em detalhe.

A fila de execução, ou a pressão de CPU no Linux moderno, revela processo esperando por processador antes de a utilização saturar. Ou seja, um servidor com folga aparente já pode estar entregando resposta pior.

Do mesmo modo, a memória exige cuidado semelhante. No Linux, o número que importa é a memória available, nunca a free, porque o cache de página aparece como ocupado sem ser. Além disso, o alarme de swap deve olhar a taxa de entrada e saída. Swap parado é herança. Swap em movimento é dor.

Disco: espaço é o sintoma, tempo de resposta é a causa

Alarme de disco em 90% de ocupação chega tarde. Em contrapartida, a projeção de esgotamento de recurso devolve prazo: o volume alerta quando a tendência aponta saturação em sete dias.

Esse prazo cabe dentro de uma janela de manutenção. O percentual fixo, por sua vez, só cabe dentro de uma madrugada. Assim, a mesma métrica muda de natureza conforme o critério aplicado sobre ela.

O segundo sinal de disco é o tempo de resposta. Latência de operação acima de 20 ms em armazenamento flash indica contenção ou controladora degradada. Ela também aparece quando existe vizinho barulhento no storage compartilhado. Em resumo, esse número explica lentidão que a ocupação nunca explicaria.

Agente ou acesso remoto

O método de coleta muda o custo do projeto antes de mudar a qualidade do dado. Agente entrega profundidade, porém exige pacote instalado, atualizado e liberado no firewall.

Acesso remoto por SNMP, WMI ou SSH entrega cobertura rápida. Em compensação, ele perde granularidade de processo. Na prática, parque legado costuma pedir a segunda opção no começo.

Nosso time detalha como instrumentar sem entrar no código da aplicação. Esse caminho resolve o bloqueio de janela de mudança apertada, que é o que trava a maioria dos projetos no primeiro mês.

Virtualização, contêiner e storage: onde o mesmo número muda de sentido

Aqui mora o erro mais caro do monitoramento de infraestrutura de TI. Ele consiste em reaproveitar o limiar do servidor físico dentro do hypervisor. O número é o mesmo. O significado, no entanto, deixou de ser.

Virtualização: o número que muda de dono

Memória em host virtualizado engana por construção. O hypervisor entrega memória sob demanda. Por isso, a métrica que denuncia contenção é o ballooning e o swap do próprio hypervisor.

Do mesmo modo, o tempo de espera por vCPU acima de 5% aponta disputa de agendamento. A contenção em ambiente virtualizado costuma surgir primeiro na latência do datastore.

Contêiner e storage: o teto contratado

Em contêiner, a métrica decisiva é o estrangulamento de CPU no cgroup. Some a ela a contagem de reinício e os eventos de término por falta de memória. Um pod pode servir tráfego com latência ruim sem nunca ficar indisponível. Logo, só o estrangulamento revela o problema a tempo.

No storage, o par que importa é IOPS entregue contra IOPS contratado, com a profundidade de fila ao lado. Volume em nuvem com limite de operações se comporta como disco saudável até bater o teto. A partir daí, a fila cresce sem que nenhuma métrica de ocupação se mexa.

Além disso, vários discos gerenciados trabalham com crédito de rajada. Ou seja, eles entregam desempenho alto por um período e caem para a linha básica quando o crédito acaba. Por isso, monitorar o saldo desse crédito evita o diagnóstico errado de aplicação lenta. Do mesmo modo, o alarme deve nascer no consumo do crédito, nunca na queda de desempenho que vem depois.

Banco de dados e serviços de negócio: o topo da pilha

Por fim, o banco de dados é a camada em que a infraestrutura encosta na aplicação. Quatro sinais resolvem a maior parte dos plantões: sessões ativas contra o limite configurado, bloqueio e espera por trava, atraso de replicação, além da consulta mais lenta da janela.

Atraso de replicação merece destaque por um motivo específico. Ele é o único sinal desta lista que mede risco de perda de dado, não desempenho. Um atraso de trinta segundos em réplica de leitura degrada relatório. O mesmo atraso em réplica de contingência define quanto você perde num failover.

Na operação das Lojas Marisa monitoramos 433 lojas a partir do datacenter. O banco Oracle entrou instrumentado por indicadores de desempenho, disponibilidade, armazenamento, segurança e replicação.

O ganho não veio da quantidade de itens coletados. Ele veio de ligar esses indicadores à transação, incluindo o sistema de transferência eletrônica de fundos. O detalhe está no case de monitoramento das 433 lojas da Marisa.

Acima do banco fica o serviço de negócio. Esse é o único ponto em que a diretoria reconhece o próprio processo. Os indicadores de banco de dados sustentam a leitura por baixo. Por fim, a transação sintética fecha por cima, medindo o caminho como um usuário faria.

A transação sintética resolve um problema que a soma de recursos não resolve. Cada componente pode responder dentro do limiar, enquanto o encadeamento deles estoura o tempo aceitável. Ou seja, a conta fecha por peça e não fecha por processo. Nesse sentido, o robô que executa a compra ou a emissão da nota mede a única coisa que o negócio reconhece.

Vale rodar essa transação também fora do horário de pico. Uma falha que só aparece de madrugada costuma ser rotina de fechamento, backup ou reindexação disputando o mesmo recurso. Dessa forma, o teste sintético vira detector de conflito de janela, não apenas de indisponibilidade.

Em que ordem instrumentar quando não dá para monitorar tudo

A ordem correta não começa pela camada mais barata de coletar. Ela começa pelo processo de negócio que dói mais quando para. Dali, o trabalho desce até o recurso.

Do processo para o recurso

Antes de tudo, escolha de dois a quatro processos críticos. Desenhe a cadeia de dependência de cada um deles, do usuário até o disco. Em seguida, instrumente os pontos dessa cadeia de fora para dentro.

Primeiro entra a transação sintética que prova o resultado. Depois disso, entram o serviço e o recurso que o sustenta. Dessa forma, cada item monitorado nasce com dono, com impacto conhecido e com alguém disposto a atender o alarme de madrugada.

Essa inversão contraria o hábito de começar pelo inventário do parque. Em compensação, ela entrega valor no primeiro mês. Além disso, o console nasce sem os milhares de itens que ninguém consegue interpretar.

Duas semanas sem alarme nenhum

O terceiro passo é a linha de base. Colete por duas a quatro semanas sem criar alarme. Limiar definido antes da linha de base é chute com aparência de engenharia.

A partir daí, a projeção de tendência substitui boa parte dos limiares fixos. Só então vale ampliar a cobertura horizontal para o resto do ambiente. Nesse momento, o time já sabe o que cada número significa naquele parque. Consequentemente, o quarto mês vira expansão, não reconstrução.

Do alerta à ação: o limiar que gera trabalho e o que gera ruído

Cobertura sem calibragem produz um efeito conhecido. Ele tem nome, tem medida e aparece em toda operação que cresceu rápido demais no número de itens coletados.

Na quarta edição da pesquisa com 1.363 profissionais, 30% apontaram a fadiga de alerta como o maior obstáculo à resposta a incidentes.

Nesse sentido, três ajustes reduzem ruído sem reduzir cobertura. O primeiro é a janela de sustentação: o alarme só dispara quando o desvio persiste pelo tempo que caracteriza problema real. Dessa forma, a rajada de trinta segundos deixa de acordar o plantão.

O segundo ajuste é a dependência entre itens. Quando o switch de acesso cai, os quarenta hosts atrás dele não geram quarenta chamados. Em vez disso, eles geram um, com quarenta impactos listados dentro.

O terceiro ajuste é o mais desconfortável de aplicar. Todo alarme precisa de uma ação escrita. Alarme sem ação definida deve sair do console. Consequentemente, a lista encolhe e a que sobra passa a ser atendida. Esse é o mecanismo que separa monitoração de fadiga de alerta.

Existe uma razão adicional para escrever a ação. Na edição de 2025 do mesmo levantamento, quase 40% das organizações relataram falha grave por erro humano. Desses casos, 85% vieram de procedimento não seguido.

O procedimento anexado ao alarme ataca exatamente esse ponto. Ele transforma o alerta em instrução, não em aviso. Por isso, a revisão trimestral da lista de alarmes rende mais que a troca de ferramenta.

Falta um quarto ajuste, que quase ninguém aplica: a severidade precisa mudar o caminho do alarme. Um mesmo item pode notificar por painel durante o dia e acionar o plantão à noite. Em seguida, a regra de escalação define quanto tempo o primeiro nível segura antes de subir. Sem esses dois parâmetros, severidade vira apenas uma cor no console.

Como escolher a ferramenta de monitoramento de infraestrutura

Em última análise, a comparação de funcionalidades resolve pouco. Toda ferramenta madura coleta as mesmas métricas hoje. Quatro critérios costumam decidir de verdade. Nenhum deles, porém, aparece na primeira página do material de vendas.

Os quatro critérios que decidem

O primeiro é o modelo de coleta que o seu parque suporta: agente, acesso remoto ou os dois convivendo. O segundo é o modelo de custo, que pode ser por item monitorado, por host, por volume ingerido ou por usuário. Cada um deles envelhece de um jeito quando o ambiente cresce.

Já o terceiro critério é a capacidade de modelar dependência entre itens. Sem ela, você compra a tempestade de alarmes junto com a licença. Nesse sentido, o teste em ambiente real vale mais que a demonstração comercial.

O quarto critério é a saída, não a entrada. Pergunte como a ferramenta abre chamado. Pergunte também como ela devolve relatório de nível de serviço e como alimenta o painel que a diretoria olha.

Uma leitura estruturada dos critérios para comparar ferramentas ajuda a evitar a compra que precisa ser trocada em dezoito meses. Em última análise, o custo da troca costuma superar a diferença de preço que motivou a escolha original.

Por onde começar na segunda-feira

Escolha um processo de negócio que já gerou reunião de crise neste semestre. Desenhe a cadeia dele em uma folha, do usuário até o disco. Em seguida, marque em vermelho cada elo que hoje ninguém mede.

Esse mapa costuma caber em quinze minutos. Ainda assim, ele revela mais lacuna do que qualquer inventário de ativos. Depois disso, colete duas semanas de linha de base nos elos vermelhos, sem criar alarme.

Defina o limiar por desvio dessa linha de base. Anexe uma ação escrita a cada alarme que sobrar. Por fim, revise a lista trinta dias depois e remova o que ninguém atendeu.

Esse ciclo rende mais do que uma migração de ferramenta. Ele ataca o problema real: não é a falta de dado que atrasa o diagnóstico. É a falta de critério sobre o dado que já existe. Se preferir acelerar o caminho, fale com nossos especialistas e monte a primeira cadeia de dependência com quem já fez isso em produção.