Alarme falso de robôs ESP32: o Wi-Fi não caiu, o canal encheu

Problema

O Zabbix abriu um card de severidade alta: robô fora da rede. O card ficou aberto por 28 minutos. Nos dois dias anteriores os robôs já somavam 21 avisos de lentidão ou perda de ping, alguns em dois robôs no mesmo minuto. Para a operação, a leitura natural era “o Wi-Fi dos robôs está caindo”.

Hipóteses descartadas

• Queda do Wi-Fi do robô: a controladora mostrava o robô conectado sem interrupção havia dois dias, com sinal de −53 dBm.
• Falha da antena: sem reinício havia três dias e 100% dos pings do Zabbix respondidos no período.
• Mudança de configuração: o log de administração tinha só acessos, nenhuma alteração.
• Defeito de um robô: no mesmo minuto os outros três também perderam pacotes e ficaram lentos.

Causa raiz

O canal de 2,4 GHz da antena da área operacional, que costuma ficar entre 30 e 50% ocupado, chegou a 61–75% por cerca de seis minutos. Celulares conectados à rede Wi-Fi de uso geral se associavam a essa antena de longe, com sinal de −80 a −107 dBm. Longe, um aparelho transmite em taxa baixa e ocupa o canal por mais tempo a cada pacote. Os robôs, perto e com sinal ótimo, ficavam esperando a vez: a resposta subiu de cerca de 3 ms para 70–150 ms e os testes falharam.

Solução e validação

• RSSI mínimo de cerca de −80 dBm no rádio de 2,4 GHz da antena da área operacional, que estava desligado. Os robôs, entre −53 e −58 dBm, ficam bem acima do limite.
• Depois do ajuste, o canal voltou à faixa normal de ocupação e os alarmes desse tipo não se repetiram.
• Recomendação complementar no Zabbix: abrir o alarme com 4 testes seguidos sem resposta (2 min) em vez de 2 (1 min).

O que este caso demonstra

• Análise de causa raiz
• Wi-Fi: tempo de ar e RSSI
• Correlação de métricas
• Zabbix: itens, gatilhos e histerese
• UniFi: controladora e logs
• Investigação sem impacto

1. O alarme e a regra que o abre

O Zabbix testa a porta de aplicação de cada robô a cada 30 segundos (net.tcp.service). O gatilho abre com 2 testes seguidos sem resposta (1 minuto) e fecha com 4 respostas seguidas e menos de 4 mudanças de estado em 30 minutos.

No episódio, os testes falharam em t+1:05, t+2:05 e t+2:35, e o robô voltou a responder em t+3:02. O card abriu em t+2:35 e só fechou em t+31:02. A falha real durou cerca de 2 minutos; os outros 26 foram a histerese esperando a primeira mudança sair da janela de 30 minutos.

2. Hipóteses descartadas

• Robô desconectado: sessão contínua na controladora havia dois dias, mesma antena, sinal de −53 dBm. O mesmo para os outros robôs.
• Antena: uptime de mais de dois dias e nenhum ping perdido no Zabbix.
• Configuração: logs de administração dos dois dias sem nenhuma alteração.
• Hardware do robô: todos pioraram juntos no mesmo minuto, o que aponta para algo compartilhado.

3. Causa raiz: tempo de ar

O Wi-Fi é um meio compartilhado: na mesma antena e no mesmo canal, só um aparelho transmite por vez. O que importa não é só o sinal de cada um, mas quanto tempo de canal cada um gasta.

• Ocupação do canal da antena da área operacional: mediana de 42% desde o início do monitoramento; 60% só é passado em 10% do tempo.
• Em uma janela de cerca de 6 minutos: 61–75%.
• Entre t−15 min e t+20 min, 21 eventos de clientes com −80 dBm ou pior na antena, todos celulares da rede de uso geral, com MAC aleatório, vindos de antenas de outras áreas.
• Resposta ao ping dos robôs no mesmo intervalo: de cerca de 3 ms para 70–150 ms, com perda de pacotes.

4. Por que o celular distante pesa tanto

1. O celular longe da antena negocia uma taxa de transmissão baixa.
2. Em taxa baixa, cada pacote leva mais tempo no ar.
3. Alguns desses aparelhos ao mesmo tempo bastam para o canal passar de 60%.
4. O robô, mesmo com sinal ótimo, espera o canal liberar; a resposta atrasa e o teste do Zabbix expira.
5. O Wi-Fi do robô não cai. Quem falha é o teste.

Validação

• Depois do RSSI mínimo, a ocupação do canal da antena da área operacional voltou à faixa normal.
• Os alarmes de “fora da rede” desse tipo não se repetiram nos robôs.

Limitações

• A ligação entre o canal cheio e o alarme foi medida para este episódio. Para os 21 avisos anteriores ela é provável, pela mesma assinatura, mas não foi medida um a um.
• O RSSI mínimo desassocia o cliente distante; para onde ele vai depende do aparelho e da cobertura. Áreas com pouca cobertura podem ficar sem sinal para celulares.
• Nomes de antenas, redes, endereços, identificadores dos robôs e do ambiente não são publicados.

Fontes consultadas (só leitura)

• Controladora UniFi, com chave de API só leitura: estado e sessões dos robôs, log de conexões da antena e log de administração.
• Zabbix: ocupação do canal e clientes da antena (1 min), icmpping, icmppingloss e icmppingsec dos robôs (3 min), net.tcp.service da porta de aplicação (30 s) e eventos dos dois dias anteriores.
• Grafana: painéis sobre os mesmos itens, para ver canal e robôs na mesma linha do tempo.

Histórico antes do episódio

21 avisos nos robôs em dois dias, quase todos de lentidão ou perda, alguns em dois robôs no mesmo minuto: a mesma assinatura do episódio analisado.

Como eu ensinaria este conceito

O caso mostra que “sinal bom” não quer dizer “conexão boa”. Numa rede sem fio, todos dividem o mesmo ar, e quem fala devagar atrasa todo mundo.

A transposição completa para a sala de aula, alinhada à BNCC Computação, está no artigo Quando o Wi-Fi “cai” e o sinal está ótimo.