Egy másik megfigyelő rendszer

16 modem, 4 mobilszolgáltató = Kimenő sebesség 933.45 Mbit/s

Bevezetés

Helló! Ez a cikk arról szól, hogyan írtunk magunknak egy új felügyeleti rendszert. A meglévőktől abban különbözik, hogy képes nagyfrekvenciás szinkron mérőszámokat elérni, és nagyon alacsony erőforrás-felhasználást tesz lehetővé. A lekérdezési sebesség elérheti a 0.1 milliszekundumot, 10 nanoszekundumos metrikák közötti szinkronizálási pontosság mellett. Minden bináris fájl 6 megabájtot foglal el.

a projektről

Van egy meglehetősen specifikus termékünk. Átfogó megoldást készítünk az adatátviteli csatornák áteresztőképességének és hibatűrésének összegzésére. Ilyenkor több csatorna van, mondjuk Operátor1 (40Mbit/s) + Operátor2 (30Mbit/s)+ Valami más (5 Mbit/s), az eredmény egy stabil és gyors csatorna, aminek a sebessége kb. ez: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.

Az ilyen megoldásokra ott van a kereslet, ahol valamelyik csatorna kapacitása nem elegendő. Például közlekedés, videó megfigyelő rendszerek és valós idejű video streaming, élő televíziós és rádiós adások közvetítése, minden olyan külvárosi létesítmény, ahol a távközlési szolgáltatók között csak a Nagy Négy képviselői vannak, és egy modem/csatorna sebessége nem elegendő .
Ezen területek mindegyikére külön-külön készüléksort gyártunk, de ezek szoftveres része szinte megegyezik, és egy magas színvonalú felügyeleti rendszer az egyik fő modulja, melynek megfelelő megvalósítása nélkül a termék nem jöhet létre.

Több év leforgása alatt sikerült egy többszintű, gyors, többplatformos és könnyű felügyeleti rendszert létrehoznunk. Ezt szeretnénk megosztani tisztelt közösségünkkel.

Probléma nyilatkozat

A felügyeleti rendszer két alapvetően különböző osztály metrikáját nyújtja: a valós idejű mérőszámokat és az összes többit. A felügyeleti rendszernek csak a következő követelményei voltak:

1. Valós idejű metrikák nagyfrekvenciás szinkron gyűjtése és késedelem nélküli átvitele a kommunikációs menedzsment rendszerbe.
   A különböző mérőszámok nagy frekvenciája és szinkronizálása nemcsak fontos, hanem az adatátviteli csatornák entrópiájának elemzéséhez is. Ha egy adatátviteli csatornában az átlagos késleltetés 30 ezredmásodperc, akkor a fennmaradó, mindössze egy milliszekundumos mérőszámok közötti szinkronizálási hiba az eredményül kapott csatorna sebességének körülbelül 5%-os csökkenéséhez vezet. Ha 1 csatornán 4 ezredmásodperccel félreütjük az időzítést, a sebességcsökkenés könnyen 30%-ra csökkenhet. Ráadásul a csatornákban az entrópia nagyon gyorsan változik, így ha 0.5 ezredmásodpercnél ritkábban mérjük, a gyors csatornákon kis késleltetéssel nagy sebességű degradációt kapunk. Természetesen ilyen pontosságra nincs szükség minden mérőszámhoz és nem minden körülmények között. Ha a csatorna késleltetése 500 ezredmásodperc, és ezzel dolgozunk, akkor az 1 ezredmásodperces hiba szinte észrevehetetlen lesz. Ezenkívül az életfenntartó rendszer mérőszámaihoz elegendő 2 másodperces lekérdezési és szinkronizálási sebességünk van, de magának a megfigyelő rendszernek képesnek kell lennie arra, hogy ultramagas lekérdezési arányokkal és a mérőszámok ultra-precíz szinkronizálásával működjön.
2. Minimális erőforrás-felhasználás és egyetlen köteg.
   A végberendezés lehet egy nagy teljesítményű fedélzeti komplexum, amely képes elemezni az úton kialakult helyzetet, vagy biometrikus felvételt készíthet az emberekről, vagy egy tenyérnyi egyfedélzeti számítógép, amelyet a különleges erők katonája a páncélja alatt visel, hogy videót továbbítson. valós időben rossz kommunikációs körülmények között. Az architektúrák és a számítási teljesítmény ilyen sokfélesége ellenére ugyanazt a szoftvercsomagot szeretnénk.
3. Esernyő építészet
   A mérőszámokat össze kell gyűjteni és összesíteni kell a végeszközön, helyben kell tárolni, és valós időben és visszamenőleg megjeleníteni. Ha van kapcsolat, vigye át az adatokat a központi felügyeleti rendszerbe. Ha nincs kapcsolat, a küldési sornak halmozódnia kell, és nem kell RAM-ot fogyasztania.
4. API az ügyfél felügyeleti rendszerébe való integráláshoz, mert senkinek nincs szüksége sok felügyeleti rendszerre. Az ügyfélnek egyetlen monitorozásba kell gyűjtenie az adatokat bármely eszközről és hálózatról.

Mi történt

Annak érdekében, hogy ne terheljem meg az amúgy is lenyűgöző hosszú olvasást, nem mondok példákat és méréseket az összes monitoring rendszerre. Ez egy másik cikkhez vezet. Csak annyit mondok, hogy nem találtunk olyan megfigyelő rendszert, amely képes egyidejűleg két metrika felvételére 1 milliszekundumnál kisebb hibával, és amely egyformán hatékonyan működik mind ARM architektúrán 64 MB RAM-mal, mind x86_64 architektúrán 32-vel. GB RAM. Ezért úgy döntöttünk, hogy megírjuk a sajátunkat, amely mindezt megteheti. Íme, amit kaptunk:

Három csatorna átviteli sebességének összegzése különböző hálózati topológiákhoz

Néhány kulcsfontosságú mérőszám megjelenítése

építészet

Fő programozási nyelvként a Golangot használjuk, mind az eszközön, mind az adatközpontban. Nagymértékben leegyszerűsítette az életet a multitasking megvalósításával és azzal, hogy minden szolgáltatáshoz egy statikusan csatolt végrehajtható bináris fájlt kaphat. Ennek eredményeként jelentősen megtakarítjuk az erőforrásokat, a módszereket és a forgalmat a szolgáltatás végberendezésekre történő telepítéséhez, a fejlesztési időt és a kódhibakeresést.

A rendszer a klasszikus moduláris elv szerint valósul meg, és több alrendszert tartalmaz:

1. Metrics regisztráció.
   Mindegyik metrikát saját szál szolgálja ki, és szinkronizálja a csatornák között. Akár 10 nanoszekundumos szinkronizálási pontosságot tudtunk elérni.
2. Mutatók tárolása
   Választottunk, hogy saját tárhelyet írunk idősorokhoz, vagy használunk valamit, ami már elérhető. Az adatbázis a visszamenőleges adatokhoz szükséges, amelyek utólagos megjelenítésre kerülnek, vagyis nem tartalmaz adatokat a csatorna 0.5 ezredmásodpercenkénti késéséről vagy a szállítási hálózat hibaleolvasásáról, hanem minden interfészen 500 ezredmásodpercenként van sebesség. A platformok közötti magas követelmények és az alacsony erőforrás-felhasználás mellett rendkívül fontos számunkra, hogy feldolgozni tudjuk. az adatok ott vannak, ahol tárolják. Ezzel óriási számítási erőforrásokat takaríthatunk meg. Ebben a projektben 2016 óta használjuk a Tarantool DBMS-t, és egyelőre nem látjuk, hogy helyettesítené azt a horizonton. Rugalmas, optimális erőforrás-felhasználással, több mint megfelelő műszaki támogatással. A Tarantool térinformatikai modult is megvalósít. Természetesen nem olyan erős, mint a PostGIS, de bizonyos (közlekedés szempontjából releváns) helymeghatározási mérőszámok tárolására elegendő.
3. A mérőszámok vizualizálása
   Itt minden viszonylag egyszerű. Adatokat veszünk a raktárból, és valós időben vagy utólag megjelenítjük.
4. Az adatok szinkronizálása a központi felügyeleti rendszerrel.
   A központi felügyeleti rendszer minden eszközről fogad adatokat, meghatározott előzményekkel tárolja és API-n keresztül elküldi a Megrendelő felügyeleti rendszerébe. Ellentétben a klasszikus megfigyelőrendszerekkel, amelyekben a „fej” járkál és adatokat gyűjt, nálunk az ellenkező séma van. Maguk az eszközök küldenek adatokat, amikor kapcsolat van. Ez egy nagyon fontos pont, mivel lehetővé teszi, hogy adatokat fogadjon az eszközről arra az időszakra, amikor az nem volt elérhető, és ne töltsön be csatornákat és erőforrásokat, amíg az eszköz nem elérhető. Az Influx monitoring szervert központi felügyeleti rendszerként használjuk. Ellentétben analógjaival, képes visszamenőleges adatokat importálni (vagyis a metrikák beérkezésének pillanatától eltérő időbélyeggel) Az összegyűjtött metrikákat a Grafana vizualizálja, fájllal módosítva. Azért is esett erre a szabványos veremre a választás, mert szinte minden ügyfélfigyelő rendszerrel rendelkezik kész API-integrációkkal.
5. Adatszinkronizálás központi eszközkezelő rendszerrel.
   Az eszközkezelő rendszer Zero Touch Provisioning-t valósít meg (firmware, konfiguráció stb. frissítése), és a felügyeleti rendszerrel ellentétben csak készülékenként kapja meg a problémákat. Ezek triggerek a fedélzeti hardverfigyelő szolgáltatások működéséhez és az életfenntartó rendszerek összes mérőszámához: CPU és SSD hőmérséklet, CPU terhelés, szabad hely és SMART állapot a lemezeken. Az alrendszer tárolója is Tarantoolra épül. Ez jelentős sebességet biztosít az idősorok összesítésében több ezer eszközön, és teljesen megoldja az adatok szinkronizálását ezekkel az eszközökkel. A Tarantool kiváló sorban állási és garantált szállítási rendszerrel rendelkezik. Ezt a fontos funkciót kivettük a dobozból, nagyszerű!

Hálózatkezelő rendszer

Mi a következő

Eddig a leggyengébb láncszemünk a központi felügyeleti rendszer. 99.9%-ban szabványos veremben van megvalósítva, és számos hátránya van:

1. Az InfluxDB adatvesztést okoz, ha áramszünet. Általános szabály, hogy a Megrendelő azonnal begyűjti mindazt, ami az eszközökről érkezik, és maga az adatbázis sem tartalmaz 5 percnél régebbi adatokat, de a jövőben ez fájdalmassá válhat.
2. A Grafanának számos problémája van az adatok összesítésével és a megjelenítésének szinkronizálásával. A leggyakoribb probléma az, ha az adatbázis 2 másodperces idősort tartalmaz, mondjuk 00:00:00-tól kezdődően, és a Grafana +1 másodperctől kezdi összesítve megjeleníteni az adatokat. Ennek eredményeként a felhasználó táncoló grafikont lát.
3. Túl sok kód az API-integrációhoz harmadik féltől származó megfigyelőrendszerekkel. Sokkal kompaktabbá tehető és persze Go-ban átírható)

Szerintem mindannyian tökéletesen láttátok, hogy néz ki a Grafana, és nélkülem is ismeritek a problémáit, úgyhogy nem fogom túlzsúfolni a posztot képekkel.

Következtetés

Szándékosan nem írtam le a műszaki részleteket, hanem csak az alapvető kialakítást írtam le ennek a rendszernek. Először is, a rendszer teljes körű műszaki leírásához egy másik cikkre lesz szükség. Másodszor, ez nem mindenkit fog érdekelni. Írd meg kommentben, hogy milyen műszaki részleteket szeretnél tudni.

Ha valakinek a jelen cikken kívüli kérdése van, írjon nekem az a.rodin @ qedr.com címre.

Forrás: will.com