Realtidsdashboards med Laravel, Redis og WebSockets

Hold rå hændelser væk fra browseren

Den mest almindelige fejl i dashboards i realtid er at skubbe hver indkommende hændelse ud til hver tilsluttet skærm. Ved stor volumen sakker browserne bagud, WebSocket-serveren bliver mættet, og grafen bliver alligevel ulæselig.

Del systemet op i fire trin: indlæsning, behandling, aggregering og broadcasting. Hvert trin har sin egen kapacitet og kan blive langsommere uden at trække de andre med sig. Dashboardet modtager aggregerede opdateringer i en fast takt, for eksempel én gang i sekundet pr. panel, ikke rå hændelser.

Vores udviklere brugte denne opbygning på Slump, en platform til overvågning i realtid af tendenser i 5G-netværk, kapacitetsindikatorer og forudsigelse af mætning for operatører i hele det sydlige Spanien, bygget på en backend i Laravel 11 og 12, der indlæser store mængder streamingdata.

Buffer indlæsningen, så trafikspidser ikke bliver til nedbrud

Indlæsningsendpointet skal gøre så lidt som muligt: validere payloaden, lægge den i en buffer og returnere. Parsing, berigelse og skrivning til databasen hører hjemme i workers.

Ved moderat volumen fungerer Redis godt som buffer. Skub hændelserne ind på en Redis-liste eller -stream, og lad workers hente dem i batches, fordi én samlet indsættelse er langt billigere for databasen end hundredvis af indsættelser med én række ad gangen.

• Validér skemaet, og afvis fejlformede hændelser ved kanten
• Returnér hurtigt, og skriv aldrig til den primære database inde i forespørgslen
• Læs fra bufferen i batches frem for én hændelse pr. job
• Sæt et loft over bufferens længde, og få en alarm, når den vokser, så modtrykket er synligt, før det bliver til datatab

Skalér behandlingen med separate køer og Horizon

Laravel-køer baseret på Redis giver dig workers, som du kan tilføje horisontalt. Laravel Horizon viser antal workers, gennemstrømning og ventetider pr. kø, og det er sådan, du tjekker, at behandlingen følger med indlæsningen.

Adskil køerne efter prioritet. Evaluering af alarmer bør aldrig vente bag en stak af historisk genbehandling, så giv behandling, aggregering, alarmer og eksport deres egne køer og puljer af workers.

Gør hvert job idempotent. Streams leverer igen, workers går ned midt i en batch, og nye forsøg sker, så det at behandle den samme hændelse to gange må ikke fordoble en tæller. Et hændelses-id, der tjekkes mod et kortlivet Redis-sæt, er ofte nok.

Aggregér i tidsintervaller, før du broadcaster

Dashboards viser rater, gennemsnit, percentiler og tendenser, ikke enkelte hændelser. Beregn dem i workers i faste tidsintervaller, for eksempel pr. sekund og pr. minut, for hver enhed, du viser: en celle, en region, en kunde.

Hold de levende aggregater i Redis med hashes eller sorterede sæt med intervallet som nøgle, og skriv hvert afsluttet interval til databasen som historik. Designet af forespørgslerne på de historiktabeller betyder lige så meget som den levende del, fordi brugerne vil zoome ud til en dag eller en uge.

På Slump reducerede et redesign af Redis-cachingen og optimering af forespørgslerne latensen for indlæsning, og det var det, der holdt livevisningen opdateret under belastning.

Broadcast opsummeringer over WebSockets med Reverb eller en hostet tjeneste

Laravel broadcasting sender hændelser til kanaler, som frontenden abonnerer på via Laravel Echo. Laravel Reverb er Laravels egen WebSocket-server, og hostede tjenester som Pusher eller Ably fungerer gennem det samme broadcasting-API.

• Broadcast på en timer ud fra aggregeret tilstand, ikke én gang pr. indkommende hændelse
• Brug private kanaler, og godkend hvert abonnement på serveren, så brugerne kun ser de enheder, de har lov til at se
• Send kompakte snapshots eller deltaer, ikke hele datasæt
• Ved genforbindelse skal klienten hente den aktuelle tilstand over HTTP og derefter genoptage strømmen
• Kør flere Reverb-instanser bag en load balancer, med Redis pub/sub imellem dem, efterhånden som antallet af forbindelser vokser

Opsæt alarmer på dynamiske tærskler i stedet for faste grænser

Faste tærskler fejler i begge retninger på streamingmålinger. Trafikken kl. 3 om natten ligner slet ikke trafikken kl. 20, så én enkelt grænse enten slår alarm hele natten eller overser problemer i dagtimerne.

En dynamisk tærskel sammenligner hver ny værdi med et udgangspunkt, der er lært fra den seneste historik for den samme enhed og det samme tidspunkt på ugen. En enkel version, der er let at forklare, holder et glidende gennemsnit og en standardafvigelse pr. enhed og time på ugen og udløser en alarm, når værdien bliver uden for det bånd i flere intervaller i træk.

På Slump reducerede dynamiske alarmer ved anomalier den manuelle overvågning, fordi operatørerne blev tilkaldt ved reelle afvigelser i stedet for at holde øje med skærme.

• Kræv vedvarenhed, for eksempel tre intervaller i træk uden for båndet, for at skære støjen ned
• Hold én åben alarm pr. enhed og betingelse, som opdateres frem for at blive gentaget
• Medtag den aktuelle værdi, udgangspunktet, båndet og et link til panelet i hver alarm
• Gennemgå jævnligt alarmer, der er slået fra eller ignoreret, og justér båndet

Vid, hvornår du skal tilføje dedikeret streamingteknologi

Laravel med Redis dækker meget, men har sine grænser. Overvej Kafka, Redpanda eller en administreret streamingtjeneste, ofte med en streamprocessor som Apache Flink, når du har brug for lang opbevaring og genafspilning af rå hændelser, streng rækkefølge pr. nøgle på tværs af mange forbrugere eller en gennemstrømning, der gør Redis' hukommelse til flaskehalsen.

Skiftet behøver ikke ske på én gang. Behold Laravel til API'et, dashboards, administration af alarmer og broadcasting, og placér streamen foran aggregeringstrinnet. Vi bygger og udvider realtidssystemer af denne type, fra indlæsning til de alarmregler, operatørerne er afhængige af.

FAQ