Még egy megfigyelő rendszer

16 modem, 4 mobilszolgáltató = Kimeneti sebesség 933,45 Mbit/s

Bevezetés

Helló! Ez egy cikk arról, hogyan írtunk magunknak egy új monitorozó rendszert. Az eddigiektől eltérően lehetőséget ad a nagy frekvenciájú szinkronizált mérési adatok megszerzésére, és nagyon alacsony erőforrás-felhasználást igényel. A kérdezési frekvencia elérheti a 0,1 milliszekundumot, a metrikák közötti szinkronizálás pontossága 10 nanomásodperc. Minden bináris fájl 6 megabájtot foglal el.

A projektről

Elég specifikus termékünk van. Komplett megoldást kínálunk az átviteli csatornák sávszélességének és megbízhatóságának összegzésére. Ez akkor történik, amikor több csatorna van, mondjuk Szolgáltató1 (40 Mbit/s) + Szolgáltató2 (30 Mbit/s) + Valami más (5 Mbit/s), az eredményként pedig egy stabil és gyors csatorna jön létre, amelynek sebessége körülbelül így alakul: (40+30+5)x0,92=75×0,92=69 Mbit/s.

Ilyen megoldásokra ott van szükség, ahol bármelyik csatorna kapacitása nem elegendő. Például közlekedésben, videómegfigyelő rendszerekben és valós idejű videó streamelésben, élő televíziós és rádióadások közvetítésében, valamint bármilyen külső helyszínen, ahol az internet szolgáltatók közül csak a nagy négyes képviselői állnak rendelkezésre, és egy modem/csatorna sebessége nem elegendő.
Minden egyes irányhoz külön eszközsorozatot készítünk, azonban a szoftverük szinte azonos és a minőségi monitorozó rendszer az egyik legfontosabb modulja, amelynek helyes megvalósítása nélkül a termék lehetetlen lenne.

Több éven keresztül sikerült létrehoznunk egy több szintű, gyors, platformfüggetlen és könnyű monitorozó rendszert, amelyet szeretnénk megosztani a tisztelt közösséggel.

Lépjünk át a kitűzött feladatra: írjunk egy XDP mechanizmust SYN cookie-kkal.

A monitorozó rendszer biztosítja két alapvetően különböző osztályú metrikák beszerzését: valós idejű metrikák és minden egyéb. A monitorozó rendszerrel szemben az alábbi követelmények álltak:

1. Nagy frekvenciájú, szinkronizált valós idejű metrikák beszerzése és azok késlekedés nélküli továbbítása a kommunikációs vezérlőrendszerbe.
   A magas frekvencia és a különböző metrikák szinkronizációja nemcsak fontos, hanem alapvetően szükséges az adatátviteli csatornák entropiájának elemzéséhez. Ha egy adatátviteli csatornán az átlagos késleltetés 30 millisekundum, akkor egy millimásodperces szinkronizációs hiba a többi metrika között körülbelül 5%-kal rontja a végeredmény csatornájának sebességét. Ha négy csatornán 1 millisekundumos szinkronizációs hibát követünk el, a sebességcsökkenés könnyen 30%-ra emelkedhet. Emellett az entropia a csatornákban nagyon gyorsan változik, ezért ha 0,5 millisekundumnál ritkábban mérjük, a gyors csatornákban, alacsony késleltetéssel nagy sebességcsökkenést tapasztalhatunk. Természetesen, nem minden metrika és nem minden körülmények között van szükség ilyen pontosságra. Amikor a késleltetés 500 millisekundum, és dolgozunk is ilyenekkel, az 1 millisekundumos eltérés szinte észrevétlen marad. Emellett az életfenntartó rendszerek metrikáihoz elegendő a 2 másodperces kérdezési és szinkronizációs frekvencia, azonban a monitorozó rendszernek képesnek kell lennie ultravékony kérdezési frekvenciák és rendkívül pontos metrikák szinkronizálására.
2. Minimalizált erőforrás-felhasználás és egységes technológiai stack.
   A végberendezés lehet egy erőteljes fedélzeti komplexum, amely képes elemezni a közlekedési helyzetet vagy biometrikus adatokat rögzíteni, de lehet egy tenyérnyi méretű egykártyás számítógép, amelyet egy kommandós visel golyóálló mellény alatt, hogy valós időben videoanyagot továbbítson gyenge kapcsolat mellett. A különböző architektúrák és számítási teljesítmények ellenére egy egységes szoftver stack-re vágyunk.
3. Zsindelyarchitektúra
   A metrikákat a végberendezésen kell összegyűjteni és aggregálni, helyi tároló- és megjelenítési rendszert kell biztosítani valós időben és visszamenőlegesen. Ha van kapcsolat, az adatokat küldeni kell a központi monitorozó rendszerbe. Amikor nincs kapcsolat, a küldési várakozólistát fel kell halmozni, és nem szabad memóriát fogyasztania.
4. API az ügyfél monitorozó rendszerébe való integrációhoz, mert senkinek sincs szüksége sok monitorozó rendszerre. Az ügyfélnek az összes eszköztől és hálózattól adatokat kell gyűjtenie egyetlen monitorozásban.

Mi lett az eredmény

Annak érdekében, hogy ne terheljem az amúgy is terjedelmes longread-et, nem hozok példákat és méréseket minden monitoring rendszerből. Ez további cikket igényelne. Csak annyit mondok, hogy nem találtunk olyan monitoring rendszert, amely képes lenne egyszerre két metrika mérésére kevesebb mint 1 milliszekundumos hibahatárral, és amely egyaránt hatékonyan működik ARM architektúrán 64 MB RAM-mal és x86_64 architektúrán 32 GB RAM-mal. Ezért úgy döntöttünk, hogy készítünk egy sajátot, ami mindezt tudja. Íme, amit készítettünk:

Három csatorna átviteli kapacitásának összegzése különböző hálózati topológiák számára

Néhány kulcsfontosságú metrika vizualizációja

Architektúra

Fő programozási nyelvként, mind az eszközön, mind az adatközpontban, a Golang-ot használjuk. Jelentősen megkönnyítette az életünket a párhuzamosság megvalósításával és azzal, hogy minden szolgáltatáshoz statikusan linkelt bináris fájlt kaphatunk. Ennek eredményeként jelentősen megtakarítunk az erőforrásokban, a módszerekben és a szolgáltatás telepítésénél a végső eszközökre, a fejlesztési és hibakeresési időben.

A rendszer klasszikus moduláris elv szerint lett megvalósítva, és több alrendszert tartalmaz:

1. Metrikák regisztrálása.
   Minden metrikát saját szál kezel, amely kanálokon keresztül szinkronizálódik. Sikerült elérnünk 10 nanoszekundumos szinkronizálási pontosságot.
2. Metrikák tárolása
   Döntöttünk arról, hogy saját tárolót készítünk az időbeli adatok számára, vagy használunk valamit a meglévők közül. Az adatbázisra a retrospektív adatokhoz van szükség, amelyeket később vizualizálunk. Azaz nincsenek adataink például a csatornában 0,5 milliszekundumonkénti késésekről vagy a szállítóhálózati hibajelzésekről, de van sebesség minden interfészenként 500 milliszekundumonként. A platformok közötti nagyfokú kompatibilitásra és az alacsony erőforrás-felhasználásra vonatkozó magas követelmények mellett számunkra rendkívül fontos, hogy képesek legyünk az adatokat ott feldolgozni, ahol tároljuk őket. Ez hatalmas mértékben takarít meg számítási erőforrásokat. 2016 óta használjuk a Tarantool adatbázis-kezelőt ebben a projektben, és egyelőre nem látunk helyettesítőt a láthatáron. Rugalmas, optimális erőforrás-felhasználással és megfelelő technikai támogatással. A Tarantool-ban GIS modul is található. Bár nem olyan erőteljes, mint a PostGIS, de elegendő a helyhez kötött metrikák tárolására (ami fontos a szállításhoz).
3. Metrikai vizualizáció
   Itt minden viszonylag egyszerű. Az adatokat a tárolóból vesszük, és megjelenítjük őket vagy valós időben, vagy retrospektíven.
4. Adatok szinkronizálása a központi monitoring rendszerrel.
   A központi monitoring rendszer adatokat fogad el minden eszköztől, és azokat előre meghatározott retrospektív időszak szerint tárolja. Ezután API-n keresztül visszaadja őket a Megrendelő monitoring rendszerének. A klasszikus monitoring rendszerekkel ellentétben, ahol a "központi egység" összegyűjti az adatokat, nálunk fordított a séma. Az eszközök maguk küldik el az adatokat, amikor van kapcsolat. Ez nagyon fontos, mivel lehetővé teszi, hogy az eszköztől származó adatokat olyan időszakokban kapjunk meg, amikor az nem volt elérhető, és nem terheli a csatornákat és az erőforrásokat akkor, amikor az eszköz nem hozzáférhető. A központi monitoring rendszerként az Influx monitoring szervert használjuk. Az analógokkal ellentétben képes retrospektív adatokat importálni (azaz olyan időbélyeggel, amely eltér a metrika rögzítésének pillanatától). A begyűjtött metrikákat a finomhangolt Grafana vizualizálja. Ez a szabványos stack azért is lett kiválasztva, mert rendelkezik kész API integrációval gyakorlatilag bármely megrendelő monitoring rendszerrel.
5. Adatok szinkronizálása a központi eszközkezelő rendszerrel.
   Az eszközkezelő rendszer megvalósítja a Zero Touch Provisioning-ot (firmware frissítés, konfiguráció stb.), és eltérően a megfigyelő rendszertől, csak az eszközökkel kapcsolatos problémákat kapja. Ezek az alaphardver figyelő szolgáltatások működésének indítói, valamint az életfenntartó rendszerek összes mutatója: CPU és SSD hőmérséklet, CPU terhelés, szabad hely és S.M.A.R.T egészség a lemezeken. A jaltaszter alrendszer tárolása szintén Tarantool-ra épül. Ez jelentős sebességet ad az időbeli adatsorok aggregálásában ezrek eszközén, és teljes mértékben megoldja az adatok szinkronizálásának kérdését ezekkel az eszközökkel. A Tarantool tartalmaz egy nagyszerű sor- és garantált kézbesítési rendszert. Ezt a fontos funkciót dobozból kaptuk, fantasztikus!

Hálózatkezelő rendszer

Mi következik

Jelenleg a leggyengébb láncszem a központi monitoring rendszerünk. Ez 99.9%-ban a standard stack-en valósult meg, és több hátránya van:

1. Az InfluxDB adatokat veszít áramkimaradás esetén. Jellemzően az ügyfél gyorsan elviszi az összes érkező adatot az eszközöktől, így az adatbázisban nincsenek 5 percnél régebbi adatok, azonban a jövőben ez fájdalmakká válhat.
2. A Grafana több problémával küzd az adatok aggregálásával és azok szinkronizálásával. A leggyakoribb probléma az, amikor az adatbázisban egy 2 másodperces intervallumú időbeli sor van, mondjuk 00:00:00-tól kezdve, és a Grafana 1 másodperces eltolással kezdi el megjeleníteni az adatokat. Ennek következtében a felhasználó ugráló grafikont lát.
3. Túlzott mennyiségű kód az API integrációhoz külső megfigyelőrendszerekkel. Ezt sokkal kompaktabban is meg lehetne csinálni, és természetesen átírhatnánk Go-ra )

Úgy gondolom, mindannyian jól tudjátok, hogy néz ki a Grafana, és tudjátok a problémáit, ezért nem akarom feleslegesen terhelni a bejegyzést képekkel.

Zárás

Tudatosan nem írtam le a technikai részleteket, csak a rendszer alapvető tervezését írtam le. Először is, a rendszer technikai részletes leírásához egy újabb cikk szükséges. Másodszor, nem mindenkit érdekelne ez. Kérlek, írjátok meg a hozzászólásokban, hogy milyen technikai részleteket szeretnétek tudni.

Ha valakiben kérdés merül fel a cikken kívül, írjatok nekem az a.rodin @ qedr.com címre.

Forrás: habr.com