16 modemov, 4 mobilní operátori= Odchádzajúca rýchlosť 933,45 Mbit/s
Úvod
Ahoj! Toto je článok o tom, ako sme vyvinuli novú monitoringovú sústavu. Od existujúcich sa líši možnosťou vysokofrekvenčného synchronizovaného získavania metrík a veľmi nízkou spotrebou zdrojov. Frekvencia dotazovania môže dosiahnuť 0,1 milisekundy s presnosťou synchronizácie medzi metrikami na 10 nanosekúnd. Všetky binárne súbory zaberajú 6 megabajtov.
O projekte
Máme celkom špecifický produkt. Vyrábame komplexné riešenie na sumarizáciu priepustnosti a odolnosti prenosových kanálov. To je, keď existuje niekoľko kanálov, povedzme Operátor1 (40 Mbit/s) + Operátor2 (30 Mbit/s) + Niečo iné (5 Mbit/s), výsledkom je jeden stabilný a rýchly kanál, ktorého rýchlosť bude približne takáto: (40+30+5)x0,92=75×0,92=69 Mbit/s.
Takéto riešenia sú žiadané tam, kde kapacita akéhokoľvek jedného kanála nestačí. Napríklad doprava, systémy video-dozoru a streamovania videa v reálnom čase, vysielanie priamych televíznych a rozhlasových prenosov, akékoľvek víkendové objekty, kde sú k dispozícii iba zástupcovia veľkej štvorky a rýchlosť na jednom modeme/kanále nie je dostatočná.
Pre každý z týchto smerov vyrábame samostatnú líniu zariadení, avšak softvérová časť je takmer rovnaká a kvalitný systém monitorovania je jedným z hlavných modulov, bez správnej implementácie ktorého by produkt nebol možný.
Za niekoľko rokov sa nám podarilo vytvoriť viacúrovňový, rýchly, multiplatformový a ľahký systém monitorovania. O čo chceme zdieľať s cteným spoločenstvom.
Stanovenie úlohy
Systém monitorovania zabezpečuje získavanie metrík dvoch zásadne odlišných tried: metriky v reálnom čase a všetky ostatné. K systému monitorovania boli stanovené len nasledujúce požiadavky:
- Vysokofrekvenčné synchronizované získavanie metrík v reálnom čase a ich prenos do systému riadenia bez oneskorenia.
Vysoká frekvencia a synchronizácia rôznych metrík nie sú len dôležité, ale sú životne nevyhnutné na analýzu entropie dátových prenosových kanálov. Ak má jeden prenosový kanál priemernú latenciu 30 milisekúnd, chyba v synchronizácii medzi ostatnými metrikami len na jednu milisekundu môže viesť k degradácii rýchlosti výsledného kanála takmer o 5 %. Ak sa pomýlime v synchronizácii o 1 milisekundu v 4 kanáloch, degradácia rýchlosti môže ľahko klesnúť až na 30 %. Okrem toho sa entropia v kanáloch mení veľmi rýchlo, takže ak ju budeme merať menej ako raz za 0.5 milisekundy, na rýchlych kanáloch s nízkou latenciou dostaneme vysokú degradáciu rýchlosti. Samozrejme, takáto presnosť nie je potrebná pre všetky metriky a nie za všetkých podmienok. Keď bude latencia v kanále 500 milisekúnd a budeme pracovať aj s takými, potom chyba 1 milisekundy nebude téměř viditeľná. Taktiež, pre metriky systémov zabezpečenia života nám stačí frekvencia opýtania a synchronizácia každé 2 sekundy, avšak samotný monitorovací systém by mal vedieť pracovať s extrémne vysokými frekvenciami opýtania a extrémne presnou synchronizáciou metriky. - Minimálne využitie zdrojov a jednotný stack.
Konečné zariadenie môže byť mocný palubný komplex, ktorý dokáže analyzovať situáciu na ceste alebo viesť biometrickú evidenciu osôb, rovnako ako jednoplatňový počítač veľkosti dlane, ktorý nosí pod nepriestrelnou vestou vojak špeciálnych síl na prenos videa v reálnom čase za zlých podmienok pripojenia. Napriek takémuto rozmanitému architektúram a výpočtovým výkonom, chceli by sme mať rovnaký softvérový stack. - Zastrešujúca architektúra
Metriky musia byť zhromažďované a agregované na konečnom zariadení, mať lokálny systém ukladania a vizualizácie v reálnom čase a retrospektívne. V prípade dostupnosti pripojenia — prenášať údaje do centrálneho monitorovacieho systému. Keď je pripojenie nedostupné — fronta na odoslanie by sa mala hromadiť a nemala by spotrebovať operačnú pamäť. - API na integráciu do monitorovacieho systému zákazníka, pretože nikto nepotrebuje mnoho monitorovacích systémov. Zákazník by mal zhromažďovať údaje z akýchkoľvek zariadení a sietí do jedného monitorovania.
Čo sa podarilo
Aby som nezahŕňal už tak rozsiahly text, nebudem uvádzať príklady a merania všetkých systémov monitorovania. To by si vyžiadalo ďalší článok. Jednoducho poviem, že nám sa nepodarilo nájsť monitorovací systém, ktorý by dokázal získať dve metriky súčasne s odchýlkou menšou ako 1 milisekunda a ktorý by rovnako efektívne fungoval na architektúre ARM s 64 MB RAM aj na architektúre x86_64 s 32 GB RAM. Preto sme sa rozhodli napísať vlastný, ktorý toto všetko zvládne. Tu je, čo sme získali:
Súčin priepustnosti troch kanálov pre rôzne topológie siete
Vizualizácia niektorých kľúčových metrik
Architektúra
Ako hlavný programovací jazyk, či už na zariadení alebo v dátovom centre, používame Golang. Výrazne nám uľahčil život so svojou implementáciou viacnásobného spracovania a možnosťou získať jeden staticky prelinkovaný spustiteľný binárny súbor pre každú službu. V dôsledku toho výrazne šetríme na zdrojoch, metódach a prenosových nákladoch pri zavádzaní služby na koncových zariadeniach, ako aj na čase potrebnom na vývoj a ladenie kódu.
Systém je implementovaný podľa klasického modulárneho princípu a obsahuje niekoľko podsystemov:
- Registrácia metrík.
Každá metrika je spravovaná vlastným vláknom a synchronizovaná prostredníctvom kanálov. Podarilo sa nám dosiahnuť presnosť synchronizácie až 10 nanosekúnd. - Uloženie metrík
Vyberali sme medzi tým, či napísať našu vlastnú úložisko pre časové rady alebo využiť niečo existujúce. Databáza je potrebná pre retrospektívne dáta, ktoré sú určené na neskoršiu vizualizáciu. T.j. neobsahuje údaje o oneskoreniach v kanáli každých 0.5 milisekundy alebo chybových hláseniach v transportnej sieti, ale obsahuje rýchlosť na každom rozhraní každých 500 milisekúnd. Okrem vysokých požiadaviek na multiplatformnosť a nízku spotrebu zdrojov, je pre nás mimoriadne dôležité mať schopnosť spracovať dáta tam, kde sú uložené. To obrovsky šetrí výpočtové zdroje. Od roku 2016 používame DBMS Tarantool v tomto projekte a zatiaľ nevidíme na obzore jeho náhradu. Flexibilný, s optimálnou spotrebou zdrojov a viac než adekvátnou technickou podporou. Takisto v Tarantool je implementovaný GIS modul. Nie je síce taký mocný ako PostGIS, ale nám stačí na naše úlohy uloženia niektorých metrík viazaných na lokalitu (aktuálne pre dopravu). - Vizualizácia metrík
Tu je všetko relatívne jednoduché. Berieme dáta z úložiska a ukazujeme ich buď v reálnom čase, alebo retrospectívne. - Synchronizácia dát s centrálna monitorovacou systémom.
Centrálna monitorovacia systém prijíma dáta zo všetkých zariadení, uchováva ich s danou retrospektívou a cez API ich odovzdáva do systému monitorovania Zákazníka. Na rozdiel od klasických monitorovacích systémov, kde „hlava“ obieha a zbiera dáta, máme opačnú schému. Zariadenia samotné posielajú dáta, keď je spojenie. Toto je veľmi dôležitý moment, pretože to umožňuje získať dáta zo zariadenia počas tých časových úsekov, keď nebolo dostupné, a nezameriavať kanály a zdroje, keď je zariadenie nedostupné. Ako centrálnu monitorovaciu systém používame Influx monitoring server. Na rozdiel od podobných, dokáže importovať retrospektívne dáta (t.j. s časovou pečiatkou odlišnou od momentu získania metriky). Zhromaždené metriky vizualizuje doladená Grafana. Tento štandardný stack bol vybraný aj preto, že má pripravené API integrácie prakticky s každým systémom monitorovania zákazníka. - Synchronizácia dát s centrálnou systémou správy zariadení.
Systém správy zariadení implementuje Zero Touch Provisioning (aktualizácia firmvéru, konfigurácie atď.) a na rozdiel od systému monitorovania dostáva len problémy so zariadeniami. Ide o spúšťače činnosti palubných hardvérových strážnych služieb a všetky metriky systémov životného zabezpečenia: teplota CPU a SSD, záťaž CPU, voľné miesto a S.M.A.R.T. zdravie na diskoch. Úložisko subsystému je postavené aj na Tarantool. To nám poskytuje značnú rýchlosť v agregácii časových radov tisícov zariadení a úplne rieši otázku synchronizácie dát s týmito zariadeniami. V Tarantool je zabudovaný výborný systém frontov a garantovanej doručenia. Túto dôležitú funkciu sme dostali z krabice, skvelé!
Systém správy siete
Čo ďalej
Momentálne najoslabenejším článkom je centrálna systém monitorovania. Je implementovaný na 99,9 % na štandardnom stacku a má niekoľko nedostatkov:
- InfluxDB stráca dáta pri výpadku elektriny. Zvyčajne zákazník rýchlo odoberá všetko, čo prichádza od zariadení, a v samotnej databáze nie sú dáta staršie ako 5 minút, avšak v budúcnosti to môže byť problém.
- Grafana má niekoľko problémov s agregáciou dát a ich synchronizáciou zobrazenia. Najčastejší problém je, keď v databáze existuje časový rad s intervalom 2 sekundy začínajúci povedzme od 00:00:00, a Grafana začína zobrazovať dáta v agregácii s +1 sekundu. V dôsledku toho používateľ vidí skáčucí graf.
- Nadmerné množstvo kódu pre API integráciu so systémami monitorovania tretích strán. Dalo by sa to urobiť oveľa kompaktnejšie a určite prepisovať na Go.)
Myslím, že všetci ste už videli, ako vyzerá Grafana, a bezomňa viete o jej problémoch, preto nebudem preťažovať príspevok obrázkami.
Záver
Zámerne som sa rozhodol nenapísať technické podrobnosti, ale opísal som iba základný dizajn tohto systému. Po prvé, aby bolo technicky kompletné popísať systém, potrebný by bol ešte jeden článok. Po druhé, nie všetkým to bude zaujímavé. Napíšte do komentárov, aké technické podrobnosti by ste chceli vedieť.
Ak by mal niekto otázky mimo tento článok, môžete mi písať na adresu a.rodin @ qedr.com
Zdroj: habr.com
