Skip to main content
La plupart des incidents FireFlo se présentent de la même façon : les messages ont été acceptés et rien n’est arrivé. Ce symptôme a au moins six causes distinctes, et une seule d’entre elles est le routage. Descendez cette page dans l’ordre. Chaque étape écarte plus qu’elle ne coûte.

​
1. Demandez à la base de données, pas au log

Trois des quatre causes probables ne sont pas du tout du routage, et la base de données dit laquelle en une requête.
Aucune édition de la table de routage ne changera une ligne qui n’est pas maxAttempts. Ces messages ont été refusés avant que le routage ne soit atteint. C’est l’après-midi gaspillé le plus courant en exploitation FireFlo.

​
2. Un fournisseur est-il seulement bindé ?

Un attrape-tout parfait pointant sur un fournisseur qui n’est pas connecté ne livre rien, et ressemble à un bug de routage sous tous les angles.
Il répond en mots — « N vendor(s) configured, none bound — nothing can be sent yet. »

​
3. Le client en a-t-il jamais été informé ?

Non. Cela vaut la peine d’être intériorisé, car cela façonne chaque conversation avec un client. La réponse de soumission est envoyée avant que le routage ne s’exécute. Un échec de routage ne peut donc jamais faire surface comme une erreur sur le submit_sm du client ou son appel HTTP — il ne peut apparaître que plus tard, en tant qu’accusé de livraison et ligne cdr_rejected.
« Mon envoi a renvoyé succès » et « mon message a été livré » sont deux affirmations sans aucun lien sur toute passerelle SMPP, FireFlo compris. Un 200 signifie accepté pour routage.

​
4. Le log est-il silencieux parce que c’est corrigé, ou parce qu’il l’a déjà dit ?

routing.rule.broken est journalisé une fois par règle, pas une fois par message — délibérément, car sans garde, ce serait une ligne par message par tentative sur exactement le trafic qui va déjà mal. La conséquence est un piège : un log silencieux n’est pas la preuve que le problème est parti. Le compteur ne se remet à zéro que lorsqu’une nouvelle table de routage est publiée. Donc après avoir corrigé une règle, guettez que la ligne réapparaisse, pas qu’elle reste absente. La forme fiable de la même question est le nombre :

​
Que capturer avant de changer quoi que ce soit

Si vous allez demander de l’aide, ou si vous vous attendez à expliquer ceci plus tard, prenez ces quatre éléments maintenant — ils sont tous peu coûteux et trois d’entre eux sont détruits par un redémarrage :
1

La ventilation des refus

La requête cdr_rejected ci-dessus, avec ses compteurs.
2

/ops/health, complet

last_error, last_submit_error, routing_failed_queue et routing_retry_queue en un seul instantané.
3

Les lignes WARN et ERROR

Pas tout le log — routing.rule.broken, message.dropped, listener.bind.failed, message.submit.response.
4

Un numéro de série d'un message qui a échoué

Tout ce qui est en aval est plus facile quand on peut tracer un vrai message plutôt qu’une classe de messages.
Rédactez avant de partager. Identifiants, system IDs, adresses IP, numéros de téléphone et contenu de message apparaissent tous dans ces sorties. fireflo rédacte ce qu’il peut, mais une ligne de log copiée à la main est sous votre responsabilité.

​
Voir aussi

Rien n'est livré

Quand c’est vraiment le routage.

Refus

Chaque raison cdr_rejected, et ce qui la corrige.