Monitoramento IoT e monitoramento de TI: o que muda na prática?

Monitorar um servidor em um data center e acompanhar um sensor instalado em um equipamento industrial são atividades que compartilham princípios importantes, mas enfrentam condições operacionais diferentes.

No primeiro cenário, a equipe geralmente dispõe de uma rede conhecida, sistemas operacionais identificáveis, interfaces de gestão e acesso relativamente controlado ao ambiente. No segundo, o ativo pode estar a quilômetros de distância, depender de bateria, operar com conectividade intermitente e permanecer exposto a calor, umidade, poeira ou vibração.

Essa diferença muda a forma de coletar informações, interpretar indisponibilidades, configurar alertas e investigar falhas.

Isso não significa que as práticas tradicionais de monitoramento de Tecnologia da Informação (TI) deixem de funcionar. Inventário de ativos, indicadores de disponibilidade, correlação de eventos, gestão de incidentes e análise histórica continuam essenciais. O que muda é a maneira de aplicar esses princípios a dispositivos que nem sempre permanecem conectados, respondem a consultas ou disponibilizam métricas detalhadas.

O monitoramento IoT amplia a visão tradicional de infraestrutura para incluir o comportamento do dispositivo físico, a comunicação e a confiabilidade dos dados produzidos em campo.

O ponto de partida é diferente

No monitoramento de TI, os ativos mais comuns incluem servidores físicos e virtuais, sistemas operacionais, bancos de dados, aplicações, equipamentos de rede e serviços de infraestrutura. A equipe acompanha métricas como utilização de processador, memória, espaço em disco, latência, disponibilidade e erros de aplicação.

Muitos desses componentes são administrados centralmente, possuem recursos suficientes para executar agentes ou disponibilizar interfaces de gestão e operam em redes projetadas para oferecer comunicação contínua.

Em IoT, o objeto monitorado também pode ser um pequeno sensor, um medidor inteligente, um rastreador, um controlador industrial ou um equipamento de comunicação instalado em campo. Esses dispositivos podem ter pouca capacidade de processamento e memória, interfaces de diagnóstico restritas e diferentes condições de alimentação e conectividade.

O National Institute of Standards and Technology (NIST) define um dispositivo IoT pela combinação de pelo menos um sensor ou atuador, que interage com o mundo físico, e uma interface de rede, que o conecta ao mundo digital. O instituto também reconhece que o dispositivo pode depender de hubs, serviços em nuvem ou outros sistemas para executar determinadas funções [1].

Essa combinação entre componentes físicos e digitais muda o diagnóstico.

Quando um servidor apresenta utilização elevada de memória, a equipe pode consultar métricas do sistema operacional, examinar processos e relacionar o comportamento com logs da aplicação. Quando um sensor remoto deixa de transmitir, talvez estejam disponíveis apenas os horários das últimas mensagens, o histórico das medições e alguns indicadores fornecidos pelo gateway.

Nos dois casos existe uma situação a investigar. A diferença está na quantidade de evidências, nos meios para coletá-las e nas possibilidades de intervenção.

A coleta nem sempre começa no sistema de monitoramento

Uma diferença importante está no modelo utilizado para obter informações dos ativos.

Em muitas arquiteturas de TI, a plataforma consulta periodicamente um alvo para coletar métricas. Esse modelo é conhecido como pull: o sistema central inicia a solicitação e o ativo responde. O Prometheus, por exemplo, utiliza normalmente esse modelo e aponta entre suas vantagens a possibilidade de identificar com maior clareza quando um alvo deixa de responder [2].

Em diversas arquiteturas IoT, o fluxo começa no dispositivo. Ele publica uma medição ou um evento em um gateway, broker ou serviço de ingestão, que encaminha a mensagem aos sistemas interessados.

O MQTT é um protocolo de transporte de mensagens baseado no modelo de publicação e assinatura. Um cliente publica mensagens em tópicos, enquanto outros clientes se inscrevem nos tópicos relevantes para recebê-las. A especificação também estabelece que o formato do conteúdo transportado é definido pela aplicação [3].

Isso permite que um sensor envie informações quando ocorre uma medição programada, quando surge um evento ou quando a conexão está disponível, sem exigir uma consulta individual para cada leitura.

Mas a distinção não é absoluta. IoT não significa necessariamente comunicação por envio, assim como o monitoramento de TI não funciona exclusivamente por consulta. Algumas soluções IoT utilizam solicitação e resposta. O Constrained Application Protocol (CoAP), padronizado pela Internet Engineering Task Force (IETF), foi projetado para nós e redes restritos e oferece uma camada de interação baseada em requisições e respostas [4].

A diferença mais importante não está em escolher entre pull e push, mas em interpretar corretamente o comportamento esperado de cada ativo.

Disponibilidade pode ter significados diferentes

Um servidor que deveria responder continuamente pode ser considerado indisponível quando deixa de atender às consultas do monitoramento. Para um dispositivo IoT, um período sem comunicação pode fazer parte do funcionamento normal.

Sensores alimentados por bateria podem permanecer em modo de baixo consumo durante parte do tempo. Medidores podem transmitir em intervalos predeterminados. Rastreadores podem armazenar informações localmente quando perdem conectividade e enviá-las depois que o sinal retorna.

Considere um medidor que envia uma leitura a cada 15 minutos. A ausência de mensagens dentro dessa janela não representa necessariamente uma falha. Se a plataforma gerar alertas em intervalos menores que o ciclo normal de transmissão, produzirá notificações indevidas. Se esperar tempo demais, uma interrupção real poderá permanecer invisível por um período incompatível com a aplicação.

Por isso, o monitoramento precisa conhecer a frequência prevista das mensagens, a latência admissível, as possibilidades de atraso, o comportamento durante falhas de comunicação e o processo de recuperação quando a conectividade retorna.

Também é necessário diferenciar três momentos:

O horário em que a medição foi realizada.

O horário em que o dispositivo ou gateway transmitiu a mensagem.

O horário em que a plataforma recebeu e processou a informação.

Um gateway pode encaminhar dados armazenados durante uma interrupção. A entrega é recente, mas a medição pode ser antiga. Sem essa distinção, um painel pode apresentar informações atrasadas como se descrevessem a condição atual do ativo.

Em IoT, receber uma mensagem agora não significa necessariamente observar o que está acontecendo agora.

O ambiente físico participa do diagnóstico

O monitoramento de TI já acompanha temperatura, energia e condições físicas de data centers. Portanto, considerar o ambiente não é uma exclusividade da IoT.

O que muda é a variedade dos locais de instalação e a proximidade entre as condições ambientais e o funcionamento do dispositivo.

Um sensor pode estar instalado em uma máquina industrial, dentro de um gabinete externo, próximo a motores, em uma área rural ou em um ponto sujeito a umidade, poeira e vibração. A alimentação elétrica, a montagem, o invólucro de proteção e a exposição ambiental podem afetar tanto o dispositivo quanto sua comunicação.

Uma única falha de energia pode interromper um gateway e, como consequência, fazer vários sensores aparentemente desaparecerem. Um gabinete metálico pode interferir na propagação do sinal. Temperaturas fora das especificações do fabricante podem afetar componentes eletrônicos ou baterias.

Além disso, a variável medida pelo sensor nem sempre descreve a condição interna do próprio dispositivo. A temperatura de um equipamento industrial, por exemplo, não informa necessariamente a temperatura dos componentes eletrônicos do sensor instalado sobre ele.

O diagnóstico precisa considerar essas relações para evitar conclusões apressadas e intervenções no componente errado.

As evidências disponíveis são mais limitadas

Servidores e aplicações normalmente oferecem métricas, logs, rastreamentos, acesso remoto e ferramentas de diagnóstico. Mesmo quando a investigação é complexa, a equipe costuma dispor de diferentes fontes de evidência.

Dispositivos IoT menores podem fornecer apenas um conjunto reduzido de informações. Em alguns casos, não há sistema operacional acessível, armazenamento suficiente para manter logs ou conectividade constante para uma sessão remota.

O diagnóstico passa a depender do que a arquitetura conseguiu preservar fora do dispositivo: últimas mensagens, qualidade do sinal, estado do gateway, indicadores de bateria, mudanças de configuração e histórico de comunicação.

Essa limitação torna o desenho da telemetria parte importante do projeto. Se uma informação necessária para investigar falhas não for coletada durante a operação, talvez seja impossível recuperá-la depois do incidente.

Também muda a forma de atuação. Reiniciar remotamente um servidor pode ser simples em uma infraestrutura administrada. Substituir um sensor em campo pode exigir deslocamento, acesso físico, peça de reposição e coordenação com a operação local.

Quanto menor a capacidade de diagnóstico remoto, maior a importância de coletar evidências úteis antes que o dispositivo deixe de responder.

Protocolos iguais não garantem dados equivalentes

O ecossistema IoT reúne diferentes protocolos, fabricantes, modelos e formatos. Um equipamento pode utilizar MQTT, outro pode se comunicar por CoAP, e um terceiro pode depender de um protocolo industrial ou de um gateway que converte suas informações para a plataforma central.

Mesmo quando dois dispositivos usam o mesmo protocolo, suas mensagens podem ter estruturas e significados diferentes. A especificação MQTT define como transportar mensagens, mas não estabelece um modelo universal para o conteúdo. Unidades, nomes de campos, códigos de estado e convenções continuam sendo definidos pelas aplicações [3].

Uma arquitetura de monitoramento escalável precisa identificar cada dispositivo e associá-lo a um inventário confiável. Também deve normalizar atributos comuns, como fabricante, modelo, localização e estado operacional, sem eliminar as características necessárias para compreender cada equipamento.

Essa normalização permite construir uma visão comum, mas não transforma todos os ativos em objetos idênticos. Um nível de bateria, uma intensidade de sinal e um código de falha continuam exigindo interpretação conforme o fabricante, o modelo e a função exercida.

O que continua válido da experiência de TI

As particularidades da IoT exigem adaptações, mas não justificam descartar práticas consolidadas de gestão de infraestrutura.

O inventário continua essencial. Em IoT, ele precisa incluir informações como modelo, firmware, localização, conectividade, alimentação, gateway associado e aplicação que utiliza os dados.

Indicadores e linhas de base também permanecem necessários. A diferença é que os limites devem refletir o ciclo operacional de cada dispositivo. Um servidor que responde continuamente segue critérios diferentes de um sensor que transmite em períodos específicos.

A correlação de eventos ajuda a evitar que sintomas relacionados sejam tratados isoladamente. Se diversos sensores ligados ao mesmo gateway deixam de transmitir ao mesmo tempo, a infraestrutura compartilhada deve ser investigada antes de presumir falhas independentes em todos os equipamentos.

Os processos de gestão de incidentes continuam válidos. Priorização, atribuição, escalonamento e encerramento permanecem necessários, mas os chamados precisam incluir informações adequadas ao ambiente físico, como a última medição, o horário de recebimento, o gateway associado e a localização do ativo.

A automação e a análise histórica também mantêm seu valor. Elas podem agrupar ocorrências, classificar eventos, encaminhar chamados e revelar padrões recorrentes, desde que respeitem as limitações dos dispositivos e das redes.

O princípio central é simples: as práticas tradicionais devem ser adaptadas, não aplicadas indiscriminadamente.

Uma arquitetura integrada precisa observar quatro camadas

Na maioria das organizações, IoT e TI não formam ambientes independentes. Uma solução conectada depende de gateways, redes, brokers, servidores, bancos de dados, serviços de processamento e aplicações corporativas.

Por isso, uma visão integrada precisa acompanhar quatro camadas relacionadas.

Infraestrutura e serviços centrais

Servidores, máquinas virtuais, redes, bancos de dados, brokers, APIs e serviços de ingestão precisam continuar sob o monitoramento tradicional de TI. Uma falha nessa camada pode afetar vários dispositivos, mesmo quando todos continuam funcionando em campo.

Dispositivos e comunicação

O acompanhamento deve considerar a última mensagem, a frequência de transmissão, a qualidade da conexão, o estado energético e as métricas específicas oferecidas pelo equipamento.

Qualidade e atualidade dos dados

Não basta confirmar que uma mensagem chegou. É necessário verificar se a medição pertence ao intervalo esperado, se permanece coerente e se segue as regras definidas para a aplicação.

Correlação e resposta operacional

Eventos das diferentes camadas precisam ser relacionados. O objetivo é reconhecer dependências, reduzir diagnósticos fragmentados e encaminhar cada ocorrência para a equipe responsável com o máximo de contexto disponível.

Essa integração evita que dispositivos, comunicação e infraestrutura sejam tratados como universos isolados. Também permite diferenciar uma falha local de um problema compartilhado que afeta toda a cadeia.

Ampliar a visibilidade sobre o ambiente conectado

O monitoramento IoT e o monitoramento de TI compartilham fundamentos, mas lidam com condições operacionais diferentes.

Dispositivos instalados em campo podem transmitir periodicamente, depender de conectividade intermitente, entrar em modo de baixo consumo e oferecer poucos recursos de diagnóstico. Também estão sujeitos a condições físicas que influenciam seu funcionamento e produzem dados que precisam ser interpretados conforme o contexto da aplicação.

Essas características não invalidam a experiência acumulada em infraestrutura. Inventário, indicadores, correlação de eventos, gestão de incidentes, automação e análise histórica permanecem fundamentais.

Para organizações que mantêm ativos conectados distribuídos, a abordagem mais consistente é integrar a visibilidade da infraestrutura central à condição operacional dos dispositivos em campo. Isso permite investigar falhas considerando as dependências entre sensores, comunicação, gateways, plataformas e aplicações.

Monitorar IoT significa ampliar a capacidade de enxergar o ambiente físico conectado e relacioná-lo aos serviços digitais dos quais ele depende.

Sobre a Target Solutions

A Target Solutions atua há mais de 15 anos apoiando organizações na evolução de suas operações de infraestrutura, monitoramento, observabilidade, automação e inteligência operacional. Ao longo dessa trajetória, participou de projetos em ambientes complexos de Telecom, Tecnologia, Governo, Energia e grandes empresas, contribuindo para aumentar a eficiência operacional e a confiabilidade dos serviços.

Essa experiência também inclui projetos relacionados à Internet das Coisas (IoT), nos quais conectividade, integração tecnológica e acompanhamento operacional são importantes para transformar dispositivos conectados em soluções úteis às organizações.

Sobre o autor

Paulo Florêncio de Menezes é cofundador da Target Solutions e atua há mais de 15 anos em projetos relacionados a infraestrutura, monitoramento, observabilidade, automação e operações de TI e Telecom.

É graduado em Processamento de Dados pela Universidade Federal do Amazonas (UFAM), possui MBA em Gestão Empresarial pela Fundação Dom Cabral (FDC) e Mestrado Profissional em Economia pela Fundação Getulio Vargas (FGV).

Em sua pesquisa de Mestrado, desenvolveu o IBEOP-IA (Índice Brasileiro de Exposição Ocupacional Potencial à Inteligência Artificial), investigando a exposição potencial das ocupações brasileiras às capacidades da IA por meio da combinação de dados ocupacionais, patentes de inteligência artificial e técnicas de processamento de linguagem natural.

Referências

[1] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Frequently Asked Questions: NIST Cybersecurity for IoT Program.

[2] PROMETHEUS AUTHORS. Frequently asked questions: Why do you pull rather than push? Documentação oficial do Prometheus.

[3] OASIS. MQTT Version 5.0. OASIS Standard, 7 mar. 2019.

[4] SHELBY, Zach; HARTKE, Klaus; BORMANN, Carsten. The Constrained Application Protocol (CoAP). RFC 7252. Internet Engineering Task Force, jun. 2014.