16 modemov, 4 mobilní operátori = Odchádzajúca rýchlosť 933.45 Mbit/s
Úvod
Ahoj! Tento článok je o tom, ako sme pre seba napísali nový monitorovací systém. Od existujúcich sa líši schopnosťou získať vysokofrekvenčné synchrónne metriky a veľmi nízkou spotrebou zdrojov. Rýchlosť dotazovania môže dosiahnuť 0.1 milisekúnd s presnosťou synchronizácie medzi metrikami 10 nanosekúnd. Všetky binárne súbory zaberajú 6 megabajtov.
o
Máme pomerne špecifický produkt. Vyrábame komplexné riešenie na zhrnutie priepustnosti a odolnosti kanálov prenosu dát. Vtedy existuje niekoľko kanálov, povedzme Operátor1 (40Mbit/s) + Operátor2 (30Mbit/s)+ Niečo iné (5 Mbit/s), výsledkom je jeden stabilný a rýchly kanál, ktorého rýchlosť bude približne toto: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.
Takéto riešenia sú žiadané tam, kde je kapacita ktoréhokoľvek kanála nedostatočná. Napríklad doprava, video monitorovacie systémy a video streaming v reálnom čase, vysielanie živého televízneho a rozhlasového vysielania, akékoľvek prímestské zariadenia, kde sú medzi telekomunikačnými operátormi iba zástupcovia veľkej štvorky a rýchlosť na jednom modeme/kanáli nestačí .
Pre každú z týchto oblastí vyrábame samostatný rad zariadení, ale ich softvérová časť je takmer rovnaká a kvalitný monitorovací systém je jedným z jeho hlavných modulov, bez ktorého správnej implementácie by produkt nebol možný.
V priebehu niekoľkých rokov sa nám podarilo vytvoriť viacúrovňový, rýchly, multiplatformový a odľahčený monitorovací systém. To je to, čo chceme zdieľať s našou rešpektovanou komunitou.
Vyhlásenie o probléme
Monitorovací systém poskytuje metriky dvoch zásadne odlišných tried: metriky v reálnom čase a všetky ostatné. Monitorovací systém mal iba tieto požiadavky:
- Vysokofrekvenčné synchrónne získavanie metrík v reálnom čase a ich bezodkladný prenos do systému riadenia komunikácie.
Vysoká frekvencia a synchronizácia rôznych metrík nie je dôležitá len pre analýzu entropie kanálov prenosu údajov. Ak je v jednom kanáli prenosu údajov priemerné oneskorenie 30 milisekúnd, potom chyba v synchronizácii medzi zostávajúcimi metrikami iba jedna milisekunda povedie k zníženiu rýchlosti výsledného kanála približne o 5 %. Ak nesprávne načasujeme načasovanie o 1 milisekundu cez 4 kanály, zníženie rýchlosti môže ľahko klesnúť na 30 %. Okrem toho sa entropia v kanáloch mení veľmi rýchlo, takže ak ju meriame menej ako raz za 0.5 milisekúnd, na rýchlych kanáloch s malým oneskorením dostaneme vysokú rýchlosť degradácie. Samozrejme, takáto presnosť nie je potrebná pre všetky metriky a nie za všetkých podmienok. Keď je oneskorenie v kanáli 500 milisekúnd a pracujeme s takýmito, potom chyba 1 milisekúnd nebude takmer viditeľná. Aj pre metriky systému podpory života máme dostatočnú rýchlosť dotazovania a synchronizácie 2 sekundy, ale samotný monitorovací systém musí byť schopný pracovať s ultra vysokými rýchlosťami dotazovania a ultra presnou synchronizáciou metrík. - Minimálna spotreba zdrojov a jeden zásobník.
Koncovým zariadením môže byť buď výkonný palubný komplex, ktorý dokáže analyzovať situáciu na ceste alebo vykonávať biometrické zaznamenávanie ľudí, alebo jednopalubný počítač veľkosti dlane, ktorý vojak špeciálnych síl nosí pod pancierom na prenos videa. v reálnom čase v zlých komunikačných podmienkach. Napriek takejto rôznorodosti architektúr a výpočtového výkonu by sme chceli mať rovnaký softvérový balík. - Dáždniková architektúra
Metriky musia byť zhromažďované a agregované na koncovom zariadení, lokálne uložené a vizualizované v reálnom čase a retrospektívne. Ak existuje spojenie, preneste údaje do centrálneho monitorovacieho systému. Keď nie je pripojenie, odosielací front by sa mal hromadiť a nespotrebovať RAM. - API pre integráciu do monitorovacieho systému zákazníka, pretože nikto nepotrebuje veľa monitorovacích systémov. Zákazník musí zhromažďovať údaje zo všetkých zariadení a sietí do jedného monitorovania.
Čo sa stalo
Aby som nezaťažil už tak pôsobivé čítanie, nebudem uvádzať príklady a merania všetkých monitorovacích systémov. To povedie k ďalšiemu článku. Poviem len, že sa nám nepodarilo nájsť monitorovací systém, ktorý je schopný brať dve metriky súčasne s chybou menšou ako 1 milisekunda a ktorý funguje rovnako efektívne ako na architektúre ARM so 64 MB RAM, tak aj na architektúre x86_64 s 32. GB pamäte RAM. Preto sme sa rozhodli napísať vlastný, ktorý toto všetko dokáže. Tu je to, čo máme:
Zhrnutie priepustnosti troch kanálov pre rôzne topológie siete
Vizualizácia niektorých kľúčových metrík
architektúra
Golang používame ako hlavný programovací jazyk na zariadení aj v dátovom centre. Výrazne zjednodušil život vďaka implementácii multitaskingu a schopnosti získať jeden staticky prepojený spustiteľný binárny súbor pre každú službu. Vďaka tomu výrazne šetríme zdroje, metódy a prevádzku na nasadenie služby na koncové zariadenia, čas vývoja a ladenie kódu.
Systém je implementovaný na klasickom modulárnom princípe a obsahuje niekoľko podsystémov:
- Registrácia metrík.
Každá metrika je poskytovaná vlastným vláknom a synchronizovaná medzi kanálmi. Podarilo sa nám dosiahnuť presnosť synchronizácie až 10 nanosekúnd. - Ukladanie metrík
Rozhodovali sme sa medzi napísaním vlastného úložiska pre časové rady alebo použitím niečoho, čo už bolo k dispozícii. Databáza je potrebná pre retrospektívne dáta, ktoré sú predmetom následnej vizualizácie, teda neobsahuje dáta o oneskoreniach v kanáli každých 0.5 milisekúnd alebo chybových údajoch v transportnej sieti, ale na každom rozhraní je rýchlosť 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é vedieť spracovávať. údaje sú tam, kde sú uložené. To šetrí obrovské výpočtové zdroje. Tarantool DBMS používame v tomto projekte od roku 2016 a zatiaľ nevidíme na obzore jeho náhradu. Flexibilné, s optimálnou spotrebou zdrojov, viac ako primeraná technická podpora. Tarantool tiež implementuje modul GIS. Samozrejme, nie je taký výkonný ako PostGIS, ale na naše úlohy ukladania niektorých metrík súvisiacich s polohou (relevantných pre dopravu) stačí. - Vizualizácia metrík
Všetko je tu pomerne jednoduché. Dáta berieme zo skladu a zobrazujeme ich buď v reálnom čase, alebo spätne. - Synchronizácia údajov s centrálnym monitorovacím systémom.
Centrálny monitorovací systém prijíma dáta zo všetkých zariadení, ukladá ich so zadanou históriou a cez API ich odosiela do monitorovacieho systému Zákazníka. Na rozdiel od klasických monitorovacích systémov, v ktorých „hlava“ chodí a zbiera dáta, máme opačnú schému. Samotné zariadenia odosielajú údaje, keď existuje spojenie. Toto je veľmi dôležitý bod, pretože vám umožňuje prijímať údaje zo zariadenia počas tých časových období, počas ktorých neboli dostupné, a nenačítavať kanály a zdroje, kým je zariadenie nedostupné. Ako centrálny monitorovací systém používame Influx monitorovací server. Na rozdiel od svojich analógov dokáže importovať retrospektívne dáta (t. j. s časovou pečiatkou odlišnou od momentu prijatia metrík) Zozbierané metriky vizualizuje Grafana, modifikované súborom. Tento štandardný zásobník bol vybraný aj preto, že má hotové API integrácie s takmer akýmkoľvek systémom monitorovania zákazníkov. - Synchronizácia údajov s centrálnym systémom správy zariadení.
Systém správy zariadení implementuje Zero Touch Provisioning (aktualizácia firmvéru, konfigurácie atď.) a na rozdiel od monitorovacieho systému dostáva iba problémy na zariadenie. Sú to spúšťače pre fungovanie palubných služieb stráženia hardvéru a všetkých metrík systémov podpory života: teplota procesora a SSD, zaťaženie procesora, voľné miesto a stav SMART na diskoch. Úložisko subsystému je tiež postavené na Tarantool. To nám dáva značnú rýchlosť pri agregácii časových radov naprieč tisíckami zariadení a tiež úplne rieši problém synchronizácie údajov s týmito zariadeniami. Tarantool má vynikajúce radenie a garantovaný systém doručenia. Túto dôležitú funkciu sme dostali z krabice, skvelé!
Systém riadenia siete
čo ďalej
Naším najslabším článkom je zatiaľ centrálny monitorovací systém. Je implementovaný na 99.9% na štandardnom zásobníku a má niekoľko nevýhod:
- InfluxDB stratí dáta pri výpadku napájania. Zákazník spravidla promptne zhromažďuje všetko, čo pochádza zo zariadení a samotná databáza neobsahuje údaje staršie ako 5 minút, čo však môže byť v budúcnosti utrpením.
- Grafana má množstvo problémov s agregáciou dát a synchronizáciou ich zobrazenia. Najčastejším problémom je, keď databáza obsahuje časový rad s intervalom 2 sekúnd počnúc povedzme 00:00:00 a Grafana začne zobrazovať údaje v agregácii od +1 sekundy. Výsledkom je, že používateľ vidí tanečný graf.
- Nadmerné množstvo kódu na integráciu API s monitorovacími systémami tretích strán. Môže byť oveľa kompaktnejší a samozrejme prepísaný v Go)
Myslím, že ste všetci dokonale videli, ako Grafana vyzerá a poznáte jej problémy aj bezo mňa, takže nebudem zahlcovať príspevok obrázkami.
Záver
Zámerne som nepopisoval technické detaily, ale opísal som len základný dizajn tohto systému. Po prvé, na úplný technický opis systému bude potrebný ďalší článok. Po druhé, nie každého to bude zaujímať. Napíšte do komentárov, aké technické detaily by ste chceli vedieť.
Ak má niekto otázky nad rámec tohto článku, môžete mi napísať na a.rodin @ qedr.com
Zdroj: hab.com