fireflo_, donc un seul match trouve tout :
Les métriques
Toutes des jauges, lues au moment du scrape, donc aucune ne coûte quoi que ce soit par message.
Les quatre qui valent une alerte
fireflo_routing_failed_queue
Non nul signifie que des messages sont partis. Pas de CDR et pas d’accusé. Sauf si
outSms.enqueueFailedRouting est réglé.fireflo_cdr_failed
Du revenu que vous ne pouvez pas facturer. Silencieux partout ailleurs.
fireflo_rating_unrated
Trafic livré et facturé rien. Croît silencieusement et ne s’auto-corrige jamais.
amqp.bridge.degraded
Dans le log plutôt qu’une métrique. La durabilité REST est partie et rien d’autre ne vous le dira.
routing_rules_broken est comment distinguer corrigé de déjà rapporté
Le log dit chaque règle cassée une fois par règle, pas une fois par message. Délibérément, puisque non gardé ce serait une ligne par message par tentative sur exactement le trafic déjà en erreur.
Le compteur ne se remet à zéro que quand une nouvelle table de routage est publiée. Donc un log silencieux n’est pas la preuve que le problème est parti, et cette jauge est la forme fiable de la même question.
whitelist_would_reject avant d’appliquer
Le mode report-only compte ce qui aurait été refusé sans le refuser.
La profondeur de file par worker n’est pas ici
Il faudrait un mètre par worker, enregistré et retiré à mesure que les workers démarrent et s’arrêtent./ops/health la rapporte par worker en attendant, donc une alerte de backlog par vendeur doit venir de là plutôt que de Prometheus.
Configuration de scrape
Connexes
Santé en direct
L’état qui n’est pas dans Prometheus.
Tokens et accès
Quels endpoints ont besoin de quel token.