Monitoring et observabilité d'une plateforme messaging

Une plateforme messaging en production traite des millions de messages, absorbe les pics d'usage, dialogue avec des APIs externes (Meta, opérateurs SMS marocains) et doit garantir la livraison d'événements critiques comme les OTP bancaires. Sans monitoring et observabilité solides, chaque incident devient une chasse au trésor. Voici comment structurer une observabilité complète pour une plateforme messaging au Maroc.

Les trois piliers de l'observabilité

Les métriques

Séries temporelles agrégées : nombre de messages envoyés par seconde, latence moyenne d'un appel API, taux d'erreur par endpoint. Elles répondent à la question que se passe-t-il globalement ?. Outils standards : Prometheus pour la collecte, Grafana pour la visualisation.

Les logs

Enregistrements horodatés des événements. Ils répondent à que s'est-il passé pour cet utilisateur précis ?. Structuration recommandée : JSON, avec des champs standardisés (level, timestamp, service, trace_id, user_id). Outils : Elasticsearch + Kibana, Loki + Grafana, ou services managés (Datadog, New Relic).

Les traces

Chaînage complet d'une requête à travers plusieurs services. Elles répondent à pourquoi cette requête a-t-elle mis 3 secondes ?. Standard : OpenTelemetry. Outils : Jaeger, Tempo, Datadog APM.

Les métriques essentielles pour une plateforme messaging

Métriques de trafic

• Messages envoyés par seconde, découpés par canal (WhatsApp, SMS) et par catégorie (Authentication, Utility, Marketing).
• Webhooks reçus par seconde, découpés par type d'événement (sent, delivered, read, failed).
• Taille de la file d'attente (RabbitMQ, Redis) : indicateur avancé de saturation.

Métriques de latence

• Latence p50, p95, p99 des appels API BSP.
• Latence webhook : délai entre envoi et réception du statut delivered.
• Latence bout en bout : entre requête HTTP entrante et confirmation utilisateur.

Métriques d'erreurs

• Taux d'erreur global par endpoint.
• Répartition des codes d'erreur Meta (131026 numéro invalide, 131047 fenêtre expirée, 131051 template rejeté, etc.).
• Taux de rate limiting (HTTP 429).

Métriques métier

• Taux de livraison par opérateur marocain (IAM, Orange, Inwi).
• Coût moyen par message par catégorie.
• Taux de bascule SMS Failback.
• Taux de vérification OTP réussie dans les 5 minutes.

Structurer les logs

Format JSON structuré

Chaque log est un objet JSON contenant au minimum : timestamp ISO 8601, niveau (info, warn, error), service émetteur, message texte, trace_id pour corrélation. Pour un événement messaging spécifique, ajouter : message_id, phone_number (hashé pour la conformité réglementaire), channel, template_name, status.

Trace ID de bout en bout

Chaque requête entrante génère un trace_id propagé dans tous les logs et appels sortants. Résultat : filtrer sur un trace_id reconstitue instantanément toute la vie de la requête à travers les services.

Attention à la vie privée

Ne jamais logger en clair : numéro de téléphone, contenu de message, code OTP, tokens d'authentification. Utiliser le hachage (SHA-256) ou la troncation quand nécessaire.

Alerting intelligent

Éviter la fatigue d'alerte

Une alerte qui se déclenche 50 fois par jour finit par être ignorée. Règles d'or :

• Seuils basés sur des taux, pas sur des valeurs absolues (taux d'erreur > 5 % pendant 5 minutes plutôt que plus de 100 erreurs par minute).
• Fenêtres glissantes pour lisser le bruit.
• Dégroupement des alertes redondantes.
• Escalade progressive : email → Slack → PagerDuty selon la gravité.

Les alertes critiques indispensables

• Taux d'erreur API BSP supérieur à 5 % sur 5 minutes.
• Latence p95 supérieure à 3 secondes sur 10 minutes.
• Taille de file d'attente en croissance continue sur 15 minutes.
• Aucun webhook Meta reçu depuis 5 minutes (probable panne de la chaîne).
• Taux de bascule SMS Failback anormalement élevé (indicateur potentiel de problème WhatsApp).
• Solde crédit BSP inférieur au seuil de sécurité.

Tableaux de bord recommandés

Dashboard opérationnel temps réel

Vue en direct pour l'astreinte : messages/seconde, taux d'erreur global, latence p95, statut de chaque service. Refresh 30 secondes maximum.

Dashboard business

Vue pour le management : volumétrie journalière, coût cumulé du mois, taux de livraison par canal, top templates utilisés. Refresh horaire suffit.

Dashboard par tenant

Pour une plateforme multi-tenant : mêmes métriques par client, avec possibilité d'export pour la facturation et le reporting client.

Cas d'usage : diagnostic d'un pic d'erreurs OTP

1. L'alerte se déclenche : taux d'erreur OTP > 5 % sur 5 minutes.
2. Le dashboard opérationnel montre une concentration d'erreurs sur les numéros IAM.
3. Les logs filtrés par code d'erreur révèlent des 131056 (rate limit dépassé sur le compte WhatsApp).
4. Les traces montrent que le volume a triplé suite à une campagne marketing lancée sans anticipation.
5. Décision : augmenter la limite via le BSP et régler la campagne.

Sans observabilité structurée, ce diagnostic aurait pris des heures. Avec, quelques minutes.

Stack technique recommandée

• Metrics : Prometheus + Grafana (open source) ou Datadog (managé).
• Logs : Loki + Grafana ou ELK (Elasticsearch + Logstash + Kibana).
• Traces : OpenTelemetry SDK, backend Jaeger ou Tempo.
• Alerting : Alertmanager, PagerDuty, Opsgenie.
• Uptime monitoring externe : Pingdom, StatusCake, ou UptimeRobot pour vérifier depuis l'extérieur que la plateforme répond.

Coûts à anticiper

Pour une plateforme messaging traitant environ 1 million de messages par mois au Maroc :

• Stack open source auto-hébergée : ~500 à 2 000 MAD/mois d'infrastructure.
• Solution managée (Datadog, New Relic) : ~3 000 à 10 000 MAD/mois selon la rétention.
• Astreinte humaine 24/7 : coût organisationnel, à intégrer dès la conception.

Conclusion

Monitorer une plateforme messaging n'est pas une couche de confort — c'est une brique fondamentale de sa fiabilité. Métriques bien choisies, logs structurés, traces propagées, alerting intelligent et dashboards adaptés forment un système nerveux qui détecte les problèmes avant les clients. Investir sérieusement en observabilité dès le premier jour évite des mois de firefighting et protège la promesse de service — particulièrement critique quand il s'agit d'OTP bancaires ou de notifications transactionnelles marocaines.