1. Pergunte para o banco, não para o log
Três das quatro causas prováveis não são roteamento, e o banco diz qual em uma query.2. Algum fornecedor está bound?
Um catch-all perfeito apontando para um fornecedor que não está conectado não entrega nada, e parece um bug de roteamento de qualquer ângulo.3. O cliente chegou a ser informado?
Não. Vale internalizar isso, porque molda toda conversa com um cliente. A resposta do submit é enviada antes de o roteamento rodar. Então uma falha de roteamento nunca pode aparecer como erro nosubmit_sm do cliente ou na chamada HTTP dele. Só pode aparecer depois,
como um delivery receipt e uma linha em cdr_rejected.
4. O log está quieto porque foi corrigido, ou porque já falou?
routing.rule.broken é logado uma vez por regra, não uma vez por mensagem. De propósito, já que
sem essa proteção seria uma linha por mensagem por tentativa exatamente no tráfego que já está indo
mal.
A consequência é uma armadilha: um log quieto não é prova de que o problema acabou. O contador só
reseta quando uma nova tabela de roteamento é publicada.
Então depois de corrigir uma regra, observe se a linha reaparece, não se ela fica ausente. A
forma confiável da mesma pergunta é o número:
O que capturar antes de mudar qualquer coisa
Se você vai pedir ajuda, ou espera precisar explicar isso depois, capture estes quatro agora. São todos baratos e três deles são destruídos por um restart:1
A quebra por rejeição
A query de
cdr_rejected acima, com as contagens.2
/ops/health inteiro
last_error, last_submit_error, routing_failed_queue e routing_retry_queue em um único
snapshot.3
As linhas de WARN e ERROR
Não o log inteiro.
routing.rule.broken, message.dropped, listener.bind.failed,
message.submit.response.4
Um serial de mensagem que falhou
Tudo lá na frente fica mais fácil quando você consegue rastrear uma mensagem real e não uma
classe delas.
Relacionados
Nada é entregue
Quando realmente é roteamento.
Recusas
Toda razão em
cdr_rejected, e o que resolve.