Monitoramento de infraestrutura de TI: arquitetura, métricas, protocolos e boas práticas

Infraestrutura monitorada não é apenas aquela em que servidores e equipamentos respondem a ping. Uma operação precisa acompanhar disponibilidade, desempenho, capacidade, integridade e o funcionamento dos serviços que dependem desses componentes.

Um servidor pode permanecer online enquanto o armazenamento se aproxima do limite. Uma interface de switch pode continuar ativa enquanto acumula erros e descartes. Um backup pode ser concluído todos os dias, mas levar progressivamente mais tempo. Uma aplicação pode responder em HTTP e ainda apresentar uma degradação significativa de desempenho.

O objetivo do monitoramento de infraestrutura de TI é transformar esses sinais técnicos em informações que permitam identificar falhas, investigar comportamento anormal e agir antes que uma degradação se transforme em indisponibilidade.

O que realmente significa monitorar uma infraestrutura

Monitoramento precisa responder a diferentes perguntas.

O equipamento está acessível? O serviço está funcionando? O desempenho está dentro do comportamento esperado? Existe tendência de esgotamento de algum recurso? A situação exige intervenção ou apenas acompanhamento?

Essas perguntas representam dimensões diferentes.

Disponibilidade indica se um ativo ou serviço pode ser alcançado. Desempenho mostra como ele está se comportando enquanto funciona. Capacidade ajuda a identificar recursos se aproximando de seus limites. Integridade permite acompanhar condições como falhas de disco, serviços parados, interfaces com erro ou problemas de hardware.

Existe ainda uma camada mais importante: aquilo que o usuário realmente utiliza está funcionando?

Um servidor DNS pode estar ligado sem resolver nomes corretamente. Uma VM de banco de dados pode estar em execução enquanto a aplicação apresenta lentidão. Um servidor web pode responder à rede e, ao mesmo tempo, não conseguir entregar a aplicação.

Por isso, ambientes maduros procuram monitorar não apenas equipamentos, mas também os serviços que dependem deles.

Como funciona uma arquitetura de monitoramento

Uma arquitetura de monitoramento normalmente possui algumas etapas fundamentais.

Os ativos geram informações. Uma camada de coleta obtém esses dados utilizando agentes, protocolos, APIs ou verificações de serviço. As métricas são armazenadas ao longo do tempo e utilizadas para construir histórico, regras, dashboards e alertas.

A partir daí, a plataforma precisa transformar dados técnicos em contexto operacional.

Um valor isolado de CPU pode significar pouco. O mesmo valor acompanhado por aumento de latência, degradação da aplicação e repetição diária representa uma situação completamente diferente.

É também por isso que diferentes ferramentas podem fazer parte da mesma arquitetura. A solução responsável por coletar uma métrica não precisa necessariamente ser a mesma utilizada para visualizá-la.

ICMP e disponibilidade básica

ICMP é frequentemente utilizado como uma primeira camada de verificação.

Ele permite identificar conectividade, latência e perda de pacotes entre pontos da rede.

Entretanto, uma resposta de ping demonstra apenas que existe comunicação IP naquele momento. Ela não comprova que DNS, banco de dados, autenticação, ERP ou uma aplicação estejam funcionando corretamente.

A disponibilidade da rede e a disponibilidade do serviço devem, portanto, ser tratadas como conceitos diferentes.

SNMP no monitoramento de redes

O Simple Network Management Protocol (SNMP) continua sendo uma das principais tecnologias para acompanhamento de equipamentos de infraestrutura.

Switches, roteadores, firewalls, access points, UPS, impressoras e storages podem disponibilizar informações como utilização das interfaces, tráfego, CPU, memória, temperatura, erros, descartes e estado de componentes.

Em equipamentos de rede, essa visão é muito mais útil do que simplesmente saber se o dispositivo está ligado.

Uma porta pode permanecer ativa e apresentar erros. Um link pode continuar operacional enquanto sofre perda de pacotes. Um equipamento pode responder normalmente e estar operando próximo de seus limites.

Sempre que possível, ambientes atuais devem avaliar SNMPv3, que acrescenta mecanismos de autenticação e proteção da comunicação em relação às versões anteriores.

Agentes em servidores Windows e Linux

Em sistemas operacionais, agentes permitem uma coleta mais detalhada.

O Zabbix Agent, por exemplo, permite obter informações locais de sistemas e aplicações, trabalhando com verificações ativas e passivas.

Esse tipo de coleta pode acompanhar CPU, memória, filesystem, interfaces, processos, serviços e outras informações internas do servidor.

Monitoramento com agente e sem agente não devem ser vistos necessariamente como abordagens concorrentes.

Um servidor pode utilizar agente para métricas do sistema operacional, uma interface de gerenciamento para informações de hardware e HTTP para validar a aplicação que ele hospeda.

A escolha depende da informação que precisa ser obtida.

HTTP, APIs e verificação do serviço

Quanto mais próximo o monitoramento estiver do serviço utilizado pelo usuário, mais significativa será a informação coletada.

Verificações HTTP e HTTPS podem acompanhar disponibilidade de páginas e APIs, códigos retornados e tempo de resposta.

APIs também se tornaram fontes importantes de telemetria. Hypervisors, soluções de backup, aplicações empresariais e serviços cloud podem disponibilizar métricas e estados diretamente por interfaces programáticas.

Isso permite sair da pergunta “o servidor está online?” e chegar a algo mais relevante: o serviço que depende dele está funcionando corretamente?

Polling, eventos e intervalos de coleta

Grande parte do monitoramento tradicional utiliza polling, no qual a plataforma consulta periodicamente determinado valor.

O intervalo de coleta é uma decisão importante.

Uma frequência excessivamente alta aumenta tráfego, processamento e armazenamento. Uma frequência muito baixa pode esconder eventos rápidos ou reduzir a qualidade da análise.

Também existem mecanismos orientados a eventos, como Syslog e SNMP traps, nos quais o dispositivo envia informações quando determinada condição ocorre.

Ambientes corporativos normalmente combinam coleta periódica e eventos, dependendo da natureza da informação.

O que deve ser monitorado em servidores e redes

CPU e memória são importantes, mas representam apenas parte da infraestrutura.

Em servidores também podem ser relevantes espaço em disco, taxa de crescimento, latência de armazenamento, IOPS, utilização das interfaces, processos, serviços, eventos, jobs e integridade física.

Em redes, indicadores como latência, perda de pacotes, utilização de interfaces, erros, descartes, estado de VPNs e disponibilidade dos equipamentos ajudam a construir uma visão operacional mais completa.

O contexto histórico também é importante.

Um filesystem com 20% de espaço disponível pode não representar problema imediato. Porém, se algumas semanas antes possuía 45%, existe uma tendência de crescimento que precisa ser analisada.

Nesse momento o monitoramento começa a contribuir também para planejamento de capacidade.

Virtualização precisa ser observada por camadas

Uma máquina virtual não funciona de maneira isolada.

Ela depende da CPU, memória, armazenamento e rede disponibilizados pela infraestrutura de virtualização.

Uma VM pode apresentar métricas aparentemente normais enquanto o host físico está sobrecarregado ou o datastore apresenta alta latência.

Por isso, ambientes VMware, Hyper-V, Proxmox e outras plataformas precisam considerar tanto as máquinas virtuais quanto hosts, storage e rede.

Esse é um exemplo claro de como uma mesma falha pode atravessar diferentes camadas da infraestrutura antes de chegar ao usuário.

Backup e storage também precisam gerar telemetria

Um job de backup concluído com sucesso é uma informação importante, mas pode não ser suficiente para avaliar a saúde da proteção.

Duração dos jobs, quantidade de dados processados, capacidade disponível, crescimento do repositório e idade do último backup válido ajudam a identificar problemas antes que a recuperação seja comprometida.

O mesmo vale para storage.

Um volume pode continuar acessível mesmo com um RAID degradado ou com aumento gradual de latência.

Esse tema se conecta diretamente às práticas discutidas no artigo sobre resiliência em infraestrutura, backup e virtualização.

Métricas, histórico e séries temporais

Uma métrica isolada possui valor limitado.

Quando os dados são armazenados ao longo do tempo, torna-se possível comparar períodos, reconhecer tendências e investigar quando determinada alteração começou.

O Prometheus trabalha justamente com dados organizados como séries temporais, identificadas por nomes de métricas e labels. A alteração de uma combinação de labels gera uma série diferente.

Essa arquitetura se tornou especialmente comum em aplicações modernas, containers e ambientes cloud-native.

Também exige planejamento. Uma utilização inadequada de labels pode multiplicar a quantidade de séries armazenadas e aumentar significativamente a cardinalidade do ambiente.

Monitorar melhor não significa simplesmente coletar o maior volume possível de dados.

Thresholds e baselines

Uma regra como “CPU acima de 80%” parece objetiva, mas não possui contexto suficiente.

O pico durou cinco segundos ou trinta minutos? É um servidor crítico? Existe aumento do tempo de resposta? É horário de backup? Esse comportamento acontece diariamente?

Thresholds continuam sendo úteis, mas devem considerar duração, criticidade e comportamento histórico.

O histórico permite estabelecer uma baseline, ou seja, uma referência de como aquele componente normalmente se comporta.

Uma alteração significativa em relação ao comportamento esperado pode ser mais importante do que simplesmente ultrapassar um número fixo.

Alertas precisam gerar ação

Nem toda métrica precisa produzir uma notificação.

Dashboards servem para acompanhamento e investigação. Alertas deveriam chamar atenção para situações que exigem avaliação ou ação.

Quando tudo gera alerta, o resultado tende a ser ruído.

Esse problema é conhecido como fadiga de alertas. A equipe recebe tantas notificações pouco importantes que eventos realmente críticos podem perder prioridade.

Dependências também precisam ser consideradas.

Se um host de virtualização ficar indisponível e dez máquinas virtuais deixarem de responder, provavelmente existe uma causa principal, e não onze problemas independentes.

Um bom desenho de alertas considera severidade, dependências, janelas de manutenção e responsáveis pela resposta.

Monitoramento distribuído

Ambientes com filiais, datacenters ou redes separadas podem exigir uma arquitetura distribuída.

O Zabbix Proxy, por exemplo, pode realizar coleta em nome do servidor central e manter dados temporariamente quando existe interrupção de comunicação.

Isso permite colocar a coleta próxima dos ativos, enquanto configuração, histórico e gestão permanecem centralizados.

Esse modelo também reduz a necessidade de realizar todas as verificações diretamente através de links WAN ou VPN.

As ferramentas não pertencem todas à mesma categoria

É comum encontrar Zabbix, Prometheus, Grafana, PRTG, SolarWinds, Azure Monitor e Datadog na mesma lista de “ferramentas de monitoramento”, mas essas tecnologias não possuem exatamente a mesma função.

Zabbix, PRTG, Checkmk, Nagios/Icinga e SolarWinds aparecem com frequência em cenários de servidores, redes, disponibilidade e infraestrutura.

Prometheus possui forte foco em métricas e séries temporais e tornou-se particularmente comum em ambientes cloud-native.

Grafana atua principalmente sobre fontes de dados. Uma data source do Grafana pode ser Prometheus, Loki, banco SQL ou serviço de monitoramento cloud. O Grafana consulta essas fontes para visualizar e explorar os dados, além de permitir regras de alerta.

Isso explica por que “Grafana versus Zabbix” nem sempre é uma comparação tecnicamente adequada. Dependendo da arquitetura, eles podem participar do mesmo ambiente.

Monitoramento em cloud

Cloud muda parte das fontes de telemetria, mas não elimina a necessidade de monitoramento.

O Azure Monitor reúne métricas, logs, traces e eventos de recursos Azure e ambientes híbridos em uma plataforma de observabilidade da Microsoft.

Na AWS, o Amazon CloudWatch acompanha recursos e aplicações executadas na plataforma e trabalha com métricas, alarmes, dashboards e logs.

Em ambientes híbridos, essas plataformas podem coexistir com sistemas locais de monitoramento.

Esse cenário se conecta ao modelo apresentado no artigo sobre infraestrutura híbrida com Azure.

Monitoramento e observabilidade

Monitoramento e observabilidade estão relacionados, mas não são exatamente a mesma coisa.

O monitoramento normalmente começa com perguntas já conhecidas: o servidor está disponível? O disco está próximo do limite? A interface apresenta erros? O serviço deixou de responder?

Observabilidade procura ampliar a capacidade de investigar o comportamento do sistema, inclusive quando a causa ainda não é conhecida.

O OpenTelemetry trabalha com sinais de telemetria como métricas, logs e traces. Traces representam o caminho percorrido por uma requisição, métricas representam medições e logs registram eventos do sistema.

Essa diferença se torna especialmente importante em aplicações distribuídas, nas quais uma única requisição pode atravessar vários componentes até encontrar um gargalo.

Observabilidade merece uma análise própria e será aprofundada em outro conteúdo.

Monitorar a própria plataforma também é necessário

Existe uma pergunta frequentemente esquecida: quem monitora o sistema responsável pelo monitoramento?

Se essa plataforma deixar de coletar dados, a equipe precisa perceber.

Dependendo da criticidade do ambiente, isso pode exigir verificações externas, backup da configuração, redundância de componentes ou outras estratégias de disponibilidade.

Nem todo ambiente precisa de uma arquitetura complexa, mas essa dependência precisa ser conhecida.

Monitoramento maduro produz contexto

A evolução do monitoramento pode ser percebida pelas perguntas que a operação consegue responder.

Inicialmente, a pergunta pode ser apenas se um equipamento está online.

Depois, é possível analisar se ele está funcionando dentro do comportamento esperado.

Com histórico suficiente, também é possível identificar tendências que indicam aproximação de limites.

Em uma arquitetura mais madura, a pergunta passa a ser: o serviço entregue ao usuário está saudável e, caso não esteja, quais componentes podem estar contribuindo para a degradação?

Ferramentas open source, soluções comerciais e serviços cloud oferecem caminhos diferentes para alcançar esse objetivo.

A escolha deve considerar arquitetura, escala, fontes de dados, integrações, retenção, criticidade, capacidade da equipe e custo operacional.

O valor do monitoramento não está na quantidade de gráficos disponíveis, mas na capacidade de transformar dados técnicos em contexto para diagnóstico, prevenção de falhas e planejamento da infraestrutura.

A Install Technology atua na implantação e administração de ambientes de monitoramento para servidores, redes, virtualização e infraestrutura corporativa.

Fale com nossa equipe para avaliar o monitoramento do seu ambiente.