fireflo_, así que una coincidencia encuentra todo:
Las métricas
Todos son gauges, leídos en el momento del scrape, así que ninguno cuesta nada por mensaje.
Los cuatro que merecen una alerta
fireflo_routing_failed_queue
Distinto de cero significa que mensajes están perdidos. Sin CDR y sin recibo. A menos que
outSms.enqueueFailedRouting esté establecido.fireflo_cdr_failed
Ingresos que no puedes facturar. Silencioso en todas partes.
fireflo_rating_unrated
Tráfico entregado y cobrado nada. Crece silenciosamente y nunca se auto-corrige.
amqp.bridge.degraded
En el log en lugar de una métrica. La durabilidad REST se fue y nada más te lo dirá.
routing_rules_broken es como distingues arreglado de ya-reportado
El log dice cada regla rota una vez por regla, no una vez por mensaje. Deliberadamente, ya que sin guardar
sería una línea por mensaje por intento sobre exactamente el tráfico que ya va mal.
El contador se resetea solo cuando se publica una nueva tabla de enrutamiento. Así que un log silencioso no es prueba de que el
problema se haya ido, y este gauge es la forma fiable de la misma pregunta.
whitelist_would_reject antes de aplicar
El modo solo-informativo cuenta lo que se habría rechazado sin rechazarlo.
La profundidad de cola por worker no está aquí
Requeriría un meter por worker, registrado y retirado a medida que los workers arrancan y paran./ops/health
lo reporta por worker mientras tanto, así que una alerta de backlog por proveedor tiene que venir de ahí en lugar
de Prometheus.
Configuración de scrape
Relacionado
Salud en vivo
El estado que no está en Prometheus.
Tokens y acceso
Qué endpoints necesitan qué token.