Monitoramento HVAC em data centers: arquitetura de referência para a Colômbia

Em um data center colombiano, uma falha de HVAC não detectada em 10 minutos pode tirar servidores inteiros de operação e disparar SLAs. A forma usual de cobrir isso —um BMS proprietário caro ou um operador olhando luzes verdes na sala— escala mal e não produz evidência para auditoria.

Esta é a arquitetura de monitoramento HVAC que implantamos em infraestrutura crítica colombiana: não invasiva, vendor-neutral e operacional 24/7 desde o primeiro dia.

TL;DR — a arquitetura em uma imagem mental

[HVAC #1..N]   →   [Gateway edge]   →   [Broker MQTT]   →   [Time-series DB]   →   [Dashboard + alertas]
 Modbus/BACnet     normaliza             AWS IoT / EMQX     InfluxDB             Grafana → email/WhatsApp/PagerDuty
                   buffer local

Cinco camadas, cada uma substituível sem tocar nas outras. Sem lock-in com o vendor do HVAC nem com a nuvem.

1. Conectar ao HVAC sem tocar nele

Regra #1 em infraestrutura crítica: não se toca no equipamento que funciona. A integração precisa ser passiva.

Os HVAC industriais típicos em data centers colombianos (Liebert/Vertiv, Stulz, APC, Daikin, Schneider) expõem variáveis via:

• Modbus RTU (RS-485) ou Modbus TCP — mais comum em equipamentos de 5+ anos.
• BACnet IP — equipamentos modernos ou integrados a BMS predial.
• SNMP — alguns equipamentos de nicho.
• Protocolo proprietário — Liebert com SiteScan, Stulz com C7000. Exigem API/SDK do fabricante.

Validar antes de comprometer arquitetura: abrir o manual do HVAC e confirmar o que ele expõe. Variáveis mínimas que precisamos: temperatura de retorno, temperatura de insuflamento, estado on/off, consumo elétrico, alarmes ativos, modo (cooling/heating/fan).

Se o equipamento não expõe nada útil por protocolo padrão, orce um módulo adicional de comunicação do fabricante (USD 400–1.500 conforme marca) ou sensores externos não invasivos como backup.

Esse padrão de integração é exatamente o que cobrimos no serviço de desenvolvimento IoT e aplicamos na solução de monitoramento HVAC.

2. Gateway edge: o coração da resiliência

Um gateway industrial (Moxa UC, Advantech UNO, Raspberry Pi industrial) faz quatro coisas:

1. Pollar os HVAC via Modbus/BACnet a cada N segundos.
2. Normalizar unidades e nomes (cada vendor nomeia variáveis diferente).
3. Bufferizar localmente quando o upstream falha — dados não se perdem.
4. Publicar ao broker MQTT com tópicos hierárquicos (dc1/sala-a/hvac-3/temp-insuflamento).

Ponto crítico: um gateway por sala (ou por agrupamento lógico), não um só para o data center inteiro. Se um gateway falha, só sua zona perde visibilidade. E os gateways monitoram uns aos outros — se um para de publicar, os demais emitem alerta.

3. Broker MQTT e time-series

O broker é o coração do sistema. Opções reais:

• AWS IoT Core — gerenciado, escala sozinho, integra com todo ecossistema AWS. Custo previsível.
• EMQX ou Mosquitto self-hosted — controle total, custo baixo, exige gerenciar HA.
• Azure IoT Hub / GCP IoT — equivalentes conforme sua nuvem preferida.

Para data centers na Colômbia onde política dita on-premise, EMQX em HA é a aposta. Para clientes cloud-first, AWS IoT Core ganha por simplicidade operacional.

Time-series: InfluxDB (open source ou cloud) ou TimescaleDB (extensão PostgreSQL). Para data centers preferimos InfluxDB pela retenção por bucket e compressão eficiente. Com 50 HVAC enviando 10 variáveis a cada 30s, são ~1,4 GB/ano por equipamento — gerenciável em qualquer deployment.

4. Dashboards e alertas: o que o operador realmente usa

Grafana é o padrão de facto. O que importa não é a ferramenta, é o design:

• Visão da sala: temperatura média, hot-spots, equipamentos em alarme, redundância ativa.
• Visão por HVAC: histórico 24h, consumo, ciclos, comparação contra setpoint.
• Visão executiva: SLA do mês, MTTR de incidentes, tendência mensal de consumo.

Alertas são onde projetos falham. Regras mínimas para data center:

1. Temperatura de retorno > limiar por N minutos → alerta imediato.
2. HVAC em alarme proprietário → alerta imediato com código do fabricante.
3. Queda de redundância (se tem N+1, perdeu o +1) → alerta crítico.
4. Tendência anômala (consumo subindo sem razão) → alerta não urgente, ticket diurno.
5. Gateway sem publicar 5 minutos → alerta para TI, não para operador do DC.

Cada alerta precisa ter dono, canal e ação esperada. Alerta sem dono atribuído é ruído — em um mês as pessoas silenciam.

Esta camada é exatamente o que cobre o serviço de monitoramento em tempo real.

5. Escalonamento de alertas: nem todo alerta acorda o líder de TI

Modelo padrão de 3 níveis:

Nível	Canal	Quem	Tempo de reação
1 — Informação	Slack/Teams	Equipe DC	Próxima ronda
2 — Ação	E-mail + Slack	Operador plantão	< 15 min
3 — Crítico	SMS + WhatsApp + PagerDuty	Plantão + supervisor	< 5 min, 24/7

PagerDuty cuida do escalonamento: se o operador de turno não dá ack em 10 min, escala para o supervisor; se este também não, para o chefe de operações. Sem isso, um alerta crítico enviado às 3 da manhã pode não receber resposta.

Decisões em projetos reais

Decisão	Default recomendado	Quando mudar
Nuvem ou on-premise?	Nuvem (AWS/Azure)	Política de segurança proíbe
1 gateway por sala ou por equipamento?	Por sala	Equipamentos com protocolo proprietário isolado
Polling a cada quanto?	30 segundos	Variáveis críticas: 5–10 s
Retenção de dados?	1 ano quente, 3 anos frio	Requisitos regulatórios
BMS existente?	Coexistir, não substituir	O BMS está sendo aposentado

Este é o tipo de arquitetura que aplicamos no setor de data centers e infraestrutura crítica, e onde a solução HVAC se cruza com monitoramento unificado.

Erros típicos em projetos HVAC

1. Projetar para o dia 1 sem pensar no 100. O que funciona com 3 HVAC desmorona com 30 se os tópicos MQTT não foram bem desenhados.
2. Alertas sem dono. Acabam silenciados em um canal de Slack que ninguém lê.
3. Esquecer a dimensão humana. O operador do DC precisa de uma visão diferente do chefe de TI. Um único dashboard para todos não serve.
4. Não testar o escalonamento. Alertas críticos são testados às 3 da manhã de um sábado, não no demo de segunda.
5. Pular o inventário de equipamentos. Um único HVAC não documentado encontrado em produção pode quebrar o cronograma.

Checklist mínimo antes de cotar

• Inventário completo de HVAC com marca, modelo, ano, protocolo suportado.
• Política de hosting definida (nuvem / on-premise / híbrido).
• Variáveis críticas a monitorar identificadas por equipamento.
• Matriz de alertas definida: nível, canal, dono, tempo de resposta.
• Horizonte de retenção de dados acordado.
• BMS existente: coexistimos ou substituímos?

---

Operando um data center ou sala técnica sem visibilidade contínua do HVAC? Na COL0 implantamos esta arquitetura em infraestrutura crítica colombiana. Conte seu caso ou converse pelo WhatsApp — em uma ligação dizemos se seu ambiente permite a implementação descrita acima ou exige ajustes.