Checklist MQTT para Produção: 30 Verificações Antes de Entrar no Ar

Este checklist MQTT para produção reúne as verificações que separam uma demonstração que funciona na sua mesa de uma frota que roda por anos. Percorra-o antes do lançamento para cobrir TLS, credenciais, client IDs, comportamento de reconexão, design de topics, sessões, monitoramento e alertas. Cada item é curto e testável, e o código no final mostra um cliente pronto para produção que você pode adaptar para um broker ConnectMQ.

Como Usar Este Checklist

Trate cada item como uma pergunta de sim ou não e anexe evidências: um arquivo de configuração, um resultado de teste, uma captura de tela. Itens que você pular de propósito devem ser registrados com o motivo. Rode a lista uma vez durante o desenvolvimento, outra antes do lançamento e de novo após cada mudança importante de firmware ou de back-end.

Se você ainda está prototipando, o servidor MQTT público (gratuito) serve para aprender e testar protótipos, mas nenhum item desta lista deve ser verificado contra ele. Produção significa um broker privado com as suas próprias credenciais.

Seção 1: Broker e Segurança

1. Broker privado em uso. O tráfego de produção roda em um broker privado, não no servidor MQTT público.
2. Apenas TLS. Os dispositivos usam a porta 8883 (MQTT sobre TLS), os navegadores usam a 8084 (Secure WebSocket em /mqtt). As portas 1883 e 8083 sem criptografia não são usadas no firmware de produção.
3. Validação de certificado habilitada. Os clientes verificam o certificado do broker contra uma CA confiável. Nenhuma flag insecure esquecida dos testes.
4. Estratégia de bundle de CA definida. Os dispositivos têm uma forma de receber certificados raiz atualizados antes que os atuais expirem.
5. Credenciais únicas. Cada dispositivo ou gateway tem credenciais próprias, para que um possa ser revogado sem afetar os outros.
6. Nenhum segredo no controle de versão. As credenciais ficam em armazenamento seguro ou em sistemas de provisionamento, não no Git nem em pacotes de apps.
7. Revogação testada. Você de fato revogou uma credencial em staging e confirmou que o dispositivo foi recusado.

Veja as boas práticas de segurança MQTT para entender o raciocínio por trás desses itens.

Seção 2: Identidade dos Clientes e Sessões

8. Client IDs únicos e estáveis. Cada client ID é derivado de um número de série ou de um registro de provisionamento e nunca muda entre reinicializações.
9. Nenhum client ID duplicado. Dois processos nunca compartilham um ID; duplicatas derrubam uma à outra em um loop sem fim.
10. Clean start ou sessão persistente escolhido por cliente. Assinantes que não podem perder mensagens usam sessões persistentes; ferramentas de curta duração usam sessões limpas.
11. Session expiry definido de propósito. No MQTT 5, o intervalo de session expiry corresponde a quanto tempo um dispositivo pode ficar offline.
12. Last Will configurado. Os dispositivos definem um Last Will em um topic de status para que o back-end saiba de desconexões inesperadas.

Seção 3: Conectividade e Reconexões

13. Reconexão automática. Os clientes reconectam sozinhos após perda de rede ou reinícios do broker.
14. Backoff exponencial com jitter. Os intervalos entre tentativas crescem e são aleatorizados, para que a frota não reconecte em sincronia.
15. Reassinatura ao reconectar. Se não houver sessões persistentes, as assinaturas são restauradas no callback de conexão.
16. Keepalive ajustado. Valores típicos vão de 30 a 120 segundos; mais curtos em redes estáveis, mais longos em redes celulares para economizar dados.
17. Buffer offline. Os dispositivos armazenam leituras localmente enquanto estão desconectados, com um teto para proteger a memória.
18. Falhas testadas. Você desconectou o cabo de rede, reiniciou a conexão com o broker e desligou e religou os dispositivos, e a recuperação funcionou.

Seção 4: Topics, Payloads e QoS

19. Árvore de topics documentada. Uma convenção escrita cobre níveis, nomenclatura e exemplos. Comece pelos níveis pelos quais o seu back-end precisa rotear, como site, linha e dispositivo.
20. Nenhum wildcard no código de publicação. Somente assinantes usam + e #.
21. Formato de payload versionado. Payloads JSON ou binários incluem um campo de versão para que você possa mudar o schema depois.
22. Tamanho de payload dentro dos limites. As mensagens cabem no tamanho máximo de mensagem do seu plano, com folga.
23. QoS escolhido por tipo de mensagem. QoS 0 para telemetria de alta frequência em que uma perda é aceitável, QoS 1 para eventos e comandos. Veja níveis de QoS do MQTT explicados.
24. Retained messages usadas de forma intencional. Retenha status e configuração, não cada leitura de telemetria.

Seção 5: Capacidade e Limites

25. Número de conexões compatível com o plano. O pico de conexões simultâneas, incluindo back-ends, ferramentas e staging, fica dentro dos limites do plano, com folga.
26. Taxa de mensagens estimada. Você conhece a sua taxa esperada de mensagens por segundo e testou com um múltiplo dela.
27. Tratamento de cotas nos clientes. Reason codes do MQTT 5 como 0x97 (Quota exceeded) são registrados e provocam backoff, em vez de loops de retentativa agressivos.

Seção 6: Monitoramento, Alertas e Operação

28. Monitoramento ativo. Clientes conectados, fluxo de mensagens e uma sonda de ponta a ponta são monitorados. Veja monitoramento de broker MQTT.
29. Alertas roteados. Os alertas chegam a uma pessoa, com um responsável de plantão e um runbook para broker inacessível, desconexões em massa e erros de cota.
30. Ambiente de staging. Existe um broker separado para testar mudanças de firmware e de back-end antes que cheguem à frota.

Tabela-Resumo

Um Modelo de Cliente Pronto para Produção

Este cliente em Python, usando paho-mqtt 2.x, implementa muitos dos itens acima: TLS com validação de certificado, client ID estável, Last Will, session expiry do MQTT 5, reassinatura na conexão, backoff e registro de reason codes. Substitua os placeholders pelas credenciais do portal do ConnectMQ.

import json
import ssl
import time
import paho.mqtt.client as mqtt
from paho.mqtt.packettypes import PacketTypes
from paho.mqtt.properties import Properties

HOST = "YOUR_BROKER_HOST"
CLIENT_ID = "YOUR_CLIENT_ID"          # estável e único por dispositivo
BASE = f"plant1/line1/{CLIENT_ID}"
STATUS = f"{BASE}/status"

def on_connect(client, userdata, flags, reason_code, properties):
    if reason_code.is_failure:
        print("Connect failed:", reason_code)
        return
    print("Connected, session present:", flags.session_present)
    client.publish(STATUS, "online", qos=1, retain=True)
    client.subscribe(f"{BASE}/cmd", qos=1)

def on_disconnect(client, userdata, flags, reason_code, properties):
    print("Disconnected:", reason_code)   # ex.: Quota exceeded

def on_message(client, userdata, msg):
    print("Command:", msg.topic, msg.payload.decode())

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=CLIENT_ID,
                     protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.will_set(STATUS, "offline", qos=1, retain=True)
client.reconnect_delay_set(min_delay=1, max_delay=120)
client.on_connect = on_connect
client.on_disconnect = on_disconnect
client.on_message = on_message

connect_props = Properties(PacketTypes.CONNECT)
connect_props.SessionExpiryInterval = 3600   # mantém a sessão por 1 hora offline

client.connect(HOST, 8883, keepalive=60, clean_start=False, properties=connect_props)
client.loop_start()

while True:
    reading = {"v": 1, "temp": 21.7, "ts": int(time.time())}
    if client.is_connected():
        client.publish(f"{BASE}/telemetry", json.dumps(reading), qos=0)
    time.sleep(10)

Para adicionar jitter à primeira reconexão de toda a frota, aguarde um número aleatório de segundos antes da chamada inicial a connect na inicialização.

Aplicando o Checklist no ConnectMQ

No ConnectMQ, um broker MQTT gerenciado, vários itens já são resolvidos para você ou ficam fáceis de verificar. Cada broker recebe credenciais geradas com client IDs vinculados a elas, o que garante os itens 5 e 8. O TLS na 8883 e o Secure WebSocket na 8084 usam certificados Let's Encrypt, confiáveis para os bundles de CA padrão. A proteção contra flood e o bloqueio de IP após repetidas falhas de login acrescentam uma camada que você teria de construir por conta própria.

Para o item 25, confira os limites do plano: o plano Serverless gratuito suporta até 25 conexões, QoS até 1 e mensagens de 256 KB; o Serverless (Paid) suporta até 1.000 conexões, QoS 2, mensagens de 1 MB e shared subscriptions; Dedicated e BYOC oferecem capacidade isolada. Para os itens 28 e 29, use o dashboard do portal, o explorador de topics ao vivo e as regras de alerta por limite com o log de alertas, e assine $SYS/broker/connection/{clientId}/state para os gateways críticos. Um broker Serverless gratuito também é um bom ambiente de staging para o item 30.

Comece com o ConnectMQ

Crie o seu broker pronto para produção em app.connectmq.com, começando no plano Serverless gratuito, sem cartão de crédito. Quando estiver pronto para ir além do piloto, leia o nosso guia para passar do protótipo MQTT à produção, compare as opções no guia de broker MQTT na nuvem ou veja o que um broker MQTT gerenciado faz por você.

Perguntas frequentes

Qual é o item mais esquecido antes de o MQTT ir para produção?

O comportamento de reconexão sob falhas reais. Muitas equipes testam apenas o caminho feliz e descobrem tempestades de reconexão ou client IDs duplicados depois da primeira indisponibilidade.

Dispositivos em produção devem usar QoS 2?

Raramente. QoS 1 com tratamento idempotente no receptor cobre a maioria dos casos com menos overhead; reserve o QoS 2 para mensagens em que duplicatas sejam realmente prejudiciais.

Posso usar o servidor MQTT público em produção?

Não. Brokers públicos podem ser lidos por qualquer pessoa e têm limites restritos. Use um broker privado com as suas próprias credenciais e TLS.

Com que frequência devo rodar o checklist de novo?

Antes de cada lançamento e após mudanças significativas de firmware, de back-end ou de plano. Guarde as evidências para facilitar auditorias e passagens de bastão.