--- title: "Dashboardy v reálném čase s Laravelem, Redisem a WebSockets" description: "Jak v Laravelu postavit dashboardy a upozornění v reálném čase nad velkými datovými toky: příjem přes buffer, fronty, broadcasting, agregace a dynamické prahy." canonical: https://sdk.enterprises/cs/insights/real-time-dashboards-laravel language: cs --- # Dashboardy v reálném čase s Laravelem, Redisem a WebSockets Aktualizováno: 2026-09-25 > Laravel zvládne dashboardy v reálném čase nad velkými datovými toky, pokud se surové události nikdy nedostanou do prohlížeče: příjem ukládejte do bufferu v Redisu, zpracovávejte ho ve workerech z front, předem agregujte do časových oken a přes WebSockets vysílejte jen souhrny. Upozornění stavte na dynamických prazích naučených z nedávné historie místo pevných limitů a specializovanou streamovací platformu přidejte, až potřeby přehrávání, pořadí nebo objemu přerostou fronty v Redisu. ## Surové události držte mimo prohlížeč Nejčastější chybou u dashboardů v reálném čase je posílat každou příchozí událost na každou připojenou obrazovku. Při velkém objemu prohlížeče nestíhají, WebSocket server se zahltí a graf je stejně nečitelný. Rozdělte systém do čtyř fází: příjem, zpracování, agregace a vysílání. Každá fáze má vlastní kapacitu a může zpomalit, aniž by s sebou strhla ostatní. Dashboard dostává agregované aktualizace v pevném rytmu, například jednou za sekundu pro každý panel, ne surové události. Naši inženýři toto uspořádání použili u Slump, platformy pro sledování trendů 5G sítí, ukazatelů kapacity a predikce saturace v reálném čase pro operátory v celém jižním Španělsku, postavené na backendu v Laravelu 11 a 12, který přijímá velké objemy streamovaných dat. ## Příjem veďte přes buffer, aby se špičky provozu nestaly výpadky Endpoint pro příjem by měl dělat co nejméně: zvalidovat obsah, přidat ho do bufferu a vrátit odpověď. Parsování, obohacování a zápisy do databáze patří do workerů. Při středních objemech funguje Redis jako takový buffer dobře. Události vkládejte do seznamu nebo streamu v Redisu a nechte workery, ať si je berou po dávkách, protože jeden dávkový insert je pro databázi mnohem levnější než stovky insertů po jednom řádku. - Validujte schéma a chybně formátované události odmítejte hned na vstupu - Odpovídejte rychle a uvnitř požadavku nikdy nezapisujte do primární databáze - Z bufferu čtěte po dávkách, ne jednu událost na úlohu - Omezte délku bufferu a nastavte upozornění na jeho růst, aby byl zpětný tlak (backpressure) vidět dřív, než se změní ve ztrátu dat ## Zpracování škálujte pomocí oddělených front a Horizonu Fronty v Laravelu postavené na Redisu vám dají workery, které můžete přidávat horizontálně. Laravel Horizon přidává počty workerů, propustnost a čekací doby pro každou frontu, a podle nich ověříte, že zpracování stíhá příjem. Fronty oddělte podle priority. Vyhodnocování upozornění by nikdy nemělo čekat za frontou přepočtů historických dat, proto dejte zpracování, agregaci, upozorněním a exportům vlastní fronty a vlastní skupiny workerů. Každá úloha musí být idempotentní. Streamy doručují znovu, workery padají uprostřed dávky a opakované pokusy se dějí, takže dvojí zpracování stejné události nesmí zdvojnásobit počítadlo. Často stačí identifikátor události kontrolovaný proti krátkodobé množině v Redisu. ## Před vysíláním agregujte do časových oken Dashboardy ukazují četnosti, průměry, percentily a trendy, ne jednotlivé události. Ty počítejte ve workerech do pevných časových oken, například po sekundách a po minutách, pro každou zobrazovanou entitu: buňku sítě, region, zákazníka. Živé agregace držte v Redisu v hashích nebo seřazených množinách s klíčem podle okna a každé uzavřené okno zapište do databáze kvůli historii. Návrh dotazů nad těmito historickými tabulkami je stejně důležitý jako živá cesta, protože uživatelé si pohled oddálí na den nebo týden. U Slump přepracování cachování v Redisu a optimalizace dotazů zkrátily latenci příjmu, a právě to udrželo živý pohled aktuální i pod zátěží. ## Souhrny vysílejte přes WebSockets pomocí Reverbu nebo hostované služby Broadcasting v Laravelu posílá události do kanálů, které frontend odebírá přes Laravel Echo. Laravel Reverb je oficiální WebSocket server od Laravelu a hostované služby jako Pusher nebo Ably fungují přes stejné API pro broadcasting. - Vysílejte podle časovače z agregovaného stavu, ne jednou za každou příchozí událost - Používejte privátní kanály a každé odebírání autorizujte na serveru, aby uživatelé viděli jen entity, které vidět smějí - Posílejte kompaktní snímky nebo rozdíly, ne celé datové sady - Po opětovném připojení ať klient načte aktuální stav přes HTTP a pak naváže na stream - S rostoucím počtem spojení provozujte několik instancí Reverbu za load balancerem, propojených přes Redis pub/sub ## Upozorňujte podle dynamických prahů místo pevných limitů Pevné prahy u streamovaných metrik selhávají oběma směry. Provoz ve 3 ráno nevypadá vůbec jako provoz ve 20 hodin, takže jediný limit buď spouští poplach celou noc, nebo přes den přehlédne problémy. Dynamický práh porovnává každou novou hodnotu s výchozí úrovní naučenou z nedávné historie pro stejnou entitu a stejnou dobu v týdnu. Jednoduchá a vysvětlitelná verze drží klouzavý průměr a směrodatnou odchylku pro každou entitu a hodinu v týdnu a spustí upozornění, když hodnota zůstane mimo toto pásmo několik po sobě jdoucích oken. U Slump dynamická upozornění na anomálie omezila ruční monitorování, protože operátoři dostávali upozornění na skutečné odchylky, místo aby sledovali obrazovky. - Vyžadujte trvání, například tři po sobě jdoucí okna mimo pásmo, abyste omezili šum - Držte jedno otevřené upozornění pro každou entitu a podmínku, které se aktualizuje, a neopakuje - Do každého upozornění zahrňte aktuální hodnotu, výchozí úroveň, pásmo a odkaz na panel - Pravidelně procházejte ztlumená a ignorovaná upozornění a pásmo dolaďujte ## Vězte, kdy přidat specializovanou streamovací technologii Laravel s Redisem pokryje hodně, ale má své limity. Zvažte Kafku, Redpandu nebo spravovanou streamovací službu, často se stream procesorem jako Apache Flink, když potřebujete dlouhé uchovávání a přehrávání surových událostí, přísné pořadí podle klíče napříč mnoha konzumenty nebo propustnost, při které se úzkým hrdlem stane paměť Redisu. Přechod nemusí proběhnout najednou. Laravel ponechte pro API, dashboardy, správu upozornění a vysílání a stream předřaďte fázi agregace. Systémy v reálném čase tohoto typu stavíme i rozšiřujeme, od příjmu dat až po pravidla upozornění, na která operátoři spoléhají. ## Hlavní body - Surové události do prohlížečů nikdy nestreamujte; agregované souhrny vysílejte v pevném rytmu. - Endpoint pro příjem držte tenký a události ukládejte do bufferu v Redisu k dávkovému zpracování workery. - Fronty oddělte podle priority a každou úlohu udělejte idempotentní, aby opakované pokusy nepoškodily počítadla. - Dynamické prahy založené na nedávné historii dávají méně a užitečnějších upozornění než pevné limity. - Kafku nebo podobnou platformu přidejte, když potřebujete přehrávání, přísné pořadí nebo objem nad možnosti Redisu, a Laravel ponechte pro aplikační vrstvu. ## Časté dotazy ### Zvládne Laravel dashboardy v reálném čase nad velkými objemy dat? Ano, pokud architektura drží těžkou práci mimo cestu požadavku: tenký endpoint pro příjem, buffer v Redisu, workery z front, které agregují do časových oken, a vysílání pouze souhrnů přes WebSockets. Laravel pak obsluhuje API, dashboardy a upozornění, zatímco workery se škálují nezávisle. ### Použít pro WebSockets Laravel Reverb, nebo Pusher? Reverb je oficiální WebSocket server od Laravelu a běží na vaší vlastní infrastruktuře, což vyhovuje týmům, které chtějí mít pod kontrolou náklady a umístění dat. Pusher nebo Ably vám ušetří provozní práci s WebSocket servery. Obě možnosti používají stejné API pro broadcasting v Laravelu, takže můžete později přejít. ### Co je dynamický práh v monitoringu? Dynamický práh je limit pro upozornění vypočítaný z nedávné historie pro stejnou metriku, entitu a dobu v týdnu, místo pevného čísla. Přizpůsobuje se denním a týdenním vzorcům, takže upozornění se spouštějí při skutečných odchylkách, a ne při běžných špičkách. ## Související služby - [Software na míru](https://sdk.enterprises/cs/services/product-engineering)