Tableaux de bord temps réel : Laravel, Redis, WebSockets

Tenez les événements bruts à l'écart du navigateur

L'erreur la plus courante dans les tableaux de bord temps réel consiste à pousser chaque événement entrant vers chaque écran connecté. À fort volume, les navigateurs prennent du retard, le serveur WebSocket sature et le graphique devient de toute façon illisible.

Découpez le système en quatre étapes : ingestion, traitement, agrégation et diffusion. Chaque étape a sa propre capacité et peut ralentir sans entraîner les autres. Le tableau de bord reçoit des mises à jour agrégées à un rythme fixe, par exemple une fois par seconde et par panneau, et non des événements bruts.

Nos ingénieurs ont utilisé cette architecture pour Slump, une plateforme de supervision temps réel des tendances du réseau 5G, des indicateurs de capacité et de la prédiction de saturation pour des opérateurs de tout le sud de l'Espagne, construite sur un back-end Laravel 11 et 12 qui ingère des données en streaming à fort volume.

Tamponnez l'ingestion pour que les pics de trafic ne deviennent pas des pannes

L'endpoint d'ingestion doit en faire le moins possible : valider la charge utile, l'ajouter à un tampon et répondre. L'analyse, l'enrichissement et les écritures en base de données relèvent des workers.

À volume modéré, Redis fait très bien office de tampon. Poussez les événements dans une liste ou un stream Redis et laissez les workers les récupérer par lots, car une insertion groupée coûte bien moins cher à la base de données que des centaines d'insertions ligne par ligne.

• Validez le schéma et rejetez les événements mal formés dès l'entrée
• Répondez vite et n'écrivez jamais dans la base principale au sein de la requête
• Lisez le tampon par lots plutôt qu'un événement par job
• Plafonnez la longueur du tampon et déclenchez une alerte quand il grossit, pour que la contre-pression soit visible avant de se transformer en perte de données

Faites monter le traitement en charge avec des files séparées et Horizon

Les files d'attente Laravel adossées à Redis vous donnent des workers que vous pouvez multiplier horizontalement. Laravel Horizon ajoute le nombre de workers par file, le débit et les temps d'attente, ce qui vous permet de vérifier que le traitement suit l'ingestion.

Séparez les files par priorité. L'évaluation des alertes ne doit jamais attendre derrière un arriéré de retraitement historique : donnez au traitement, à l'agrégation, aux alertes et aux exports leurs propres files et leurs propres groupes de workers.

Rendez chaque job idempotent. Les flux redélivrent, des workers plantent au milieu d'un lot et les nouvelles tentatives arrivent : traiter deux fois le même événement ne doit pas doubler un compteur. Un identifiant d'événement vérifié dans un ensemble Redis de courte durée suffit souvent.

Agrégez par tranches de temps avant de diffuser

Les tableaux de bord affichent des débits, des moyennes, des percentiles et des tendances, pas des événements individuels. Calculez-les dans les workers par tranches de temps fixes, par exemple par seconde et par minute, pour chaque entité affichée : une cellule, une région, un client.

Gardez les agrégats en direct dans Redis, avec des hashes ou des sorted sets indexés par tranche, et écrivez chaque tranche clôturée en base de données pour l'historique. La conception des requêtes sur ces tables d'historique compte autant que le chemin en direct, car les utilisateurs voudront dézoomer sur une journée ou une semaine.

Sur Slump, une refonte du cache Redis et l'optimisation des requêtes ont réduit la latence d'ingestion, ce qui a permis de garder la vue en direct à jour sous charge.

Diffusez des synthèses via WebSockets avec Reverb ou un service hébergé

Le broadcasting de Laravel envoie des événements sur des canaux auxquels le front-end s'abonne via Laravel Echo. Laravel Reverb est le serveur WebSocket officiel, et des services hébergés comme Pusher ou Ably fonctionnent via la même API de broadcasting.

• Diffusez selon une minuterie à partir de l'état agrégé, pas à chaque événement entrant
• Utilisez des canaux privés et autorisez chaque abonnement côté serveur, pour que les utilisateurs ne voient que les entités auxquelles ils ont droit
• Envoyez des instantanés compacts ou des deltas, pas des jeux de données complets
• À la reconnexion, faites charger l'état courant au client via HTTP, puis reprenez le flux
• Faites tourner plusieurs instances Reverb derrière un répartiteur de charge, avec Redis pub/sub entre elles, à mesure que le nombre de connexions augmente

Déclenchez les alertes sur des seuils dynamiques plutôt que sur des limites fixes

Les seuils fixes échouent dans les deux sens sur des métriques de streaming. Le trafic à 3 heures du matin ne ressemble en rien à celui de 8 heures du soir : une limite unique se déclenche donc toute la nuit ou rate les problèmes de la journée.

Un seuil dynamique compare chaque nouvelle valeur à une référence apprise à partir de l'historique récent pour la même entité et le même moment de la semaine. Une version simple et explicable conserve une moyenne et un écart-type glissants par entité et par heure de la semaine, et déclenche une alerte quand la valeur reste hors de cette bande pendant plusieurs tranches consécutives.

Sur Slump, les alertes dynamiques sur anomalie ont réduit la surveillance manuelle, car les opérateurs étaient prévenus des vrais écarts au lieu de surveiller des écrans.

• Exigez une persistance, par exemple trois tranches consécutives hors bande, pour réduire le bruit
• Gardez une seule alerte ouverte par entité et par condition, mise à jour plutôt que répétée
• Incluez dans chaque alerte la valeur actuelle, la référence, la bande et un lien vers le panneau
• Passez régulièrement en revue les alertes mises en sourdine ou ignorées, et ajustez la bande

Sachez quand ajouter une technologie de streaming dédiée

Laravel avec Redis couvre beaucoup de terrain, mais a ses limites. Envisagez Kafka, Redpanda ou un service de streaming managé, souvent avec un moteur de traitement de flux comme Apache Flink, quand vous avez besoin d'une longue rétention et du rejeu des événements bruts, d'un ordonnancement strict par clé sur de nombreux consommateurs, ou d'un débit qui fait de la mémoire Redis le goulot d'étranglement.

La transition n'a pas à se faire d'un coup. Gardez Laravel pour l'API, les tableaux de bord, la gestion des alertes et le broadcasting, et placez le flux en amont de l'étape d'agrégation. Nous construisons et faisons évoluer des systèmes temps réel de ce type, de l'ingestion jusqu'aux règles d'alerte sur lesquelles s'appuient les opérateurs.

FAQ