Başqa bir monitorinq sistemi

Başqa bir monitorinq sistemi
16 modem, 4 mobil operator = Çıxış sürəti 933.45 Mbit/s

Giriş

Salam! Bu yazı özümüz üçün yeni bir monitorinq sistemini necə yazdığımızdan bəhs edir. O, yüksək tezlikli sinxron metrikləri əldə etmək və çox az resurs istehlakı ilə mövcud olanlardan fərqlənir. Səsvermə sürəti 0.1 nanosaniyəlik ölçülər arasında sinxronizasiya dəqiqliyi ilə 10 millisaniyəyə çata bilər. Bütün ikili fayllar 6 meqabayt tutur.

Layihə haqqında

Bizim kifayət qədər spesifik məhsulumuz var. Biz məlumat ötürmə kanallarının ötürmə qabiliyyətini və nasazlığa dözümlülüyünü ümumiləşdirmək üçün hərtərəfli həll variantı istehsal edirik. Bu, bir neçə kanal olduqda, tutaq ki, Operator1 (40Mbit/s) + Operator2 (30Mbit/s)+ Başqa bir şey (5 Mbit/s), nəticə bir sabit və sürətli kanaldır, sürəti belə bir şey olacaq. bu: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.

Bu cür həllər hər hansı bir kanalın tutumu qeyri-kafi olduğu yerlərdə tələb olunur. Məsələn, nəqliyyat, videomüşahidə sistemləri və real vaxt rejimində video axını, canlı televiziya və radio yayımlarının yayımı, telekommunikasiya operatorları arasında yalnız Böyük Dördlüyün nümayəndələrinin olduğu və bir modem/kanalda sürətin kifayət etmədiyi istənilən şəhərətrafı obyektlər. .
Bu sahələrin hər biri üçün ayrı-ayrı cihazlar xətti istehsal edirik, lakin onların proqram hissəsi demək olar ki, eynidir və yüksək keyfiyyətli monitorinq sistemi onun əsas modullarından biridir, düzgün həyata keçirilmədən məhsulun istehsalı mümkün olmayacaqdır.

Bir neçə il ərzində biz çoxsəviyyəli, sürətli, çarpaz platforma və yüngül çəkiyə malik monitorinq sistemi yaratmağa nail olduq. Hörmətli cəmiyyətimizlə bölüşmək istədiyimiz budur.

Problem problemi

Monitorinq sistemi iki əsas fərqli sinifin ölçülərini təqdim edir: real vaxt göstəriciləri və digərləri. Monitorinq sisteminin yalnız aşağıdakı tələbləri var idi:

  1. Real vaxt rejimində ölçülərin yüksək tezlikli sinxron əldə edilməsi və gecikmədən rabitə idarəetmə sisteminə ötürülməsi.
    Yüksək tezlik və müxtəlif ölçülərin sinxronizasiyası təkcə vacib deyil, həm də məlumat ötürmə kanallarının entropiyasını təhlil etmək üçün çox vacibdir. Bir məlumat ötürmə kanalında orta gecikmə 30 millisaniyədirsə, onda cəmi bir millisaniyəlik qalan ölçülər arasında sinxronizasiya xətası yaranan kanalın sürətinin təxminən 5% azalmasına səbəb olacaqdır. 1 kanalda vaxtı 4 millisaniyə ilə səhv təyin etsək, sürətin azalması asanlıqla 30%-ə düşə bilər. Bundan əlavə, kanallardakı entropiya çox tez dəyişir, buna görə də onu hər 0.5 millisaniyədə bir dəfədən az ölçsək, kiçik bir gecikmə ilə sürətli kanallarda yüksək sürətli deqradasiya əldə edəcəyik. Əlbəttə ki, belə dəqiqlik bütün ölçülər üçün lazım deyil və bütün şərtlərdə deyil. Kanalda gecikmə 500 millisaniyə olduqda və biz belə işlədiyimiz zaman 1 millisaniyəlik səhv demək olar ki, nəzərə çarpmayacaq. Həmçinin, həyat dəstəyi sisteminin ölçüləri üçün 2 saniyəlik kifayət qədər sorğu və sinxronizasiya sürətimiz var, lakin monitorinq sisteminin özü ultra yüksək səsvermə dərəcələri və metriklərin ultra dəqiq sinxronizasiyası ilə işləməyi bacarmalıdır.
  2. Minimum resurs istehlakı və tək yığın.
    Son cihaz ya yolda vəziyyəti təhlil edə bilən və ya insanların biometrik qeydiyyatını apara bilən güclü bort kompleksi, ya da xüsusi təyinatlı əsgərin videonu ötürmək üçün zirehinin altına taxdığı xurma ölçülü bir bort kompüter ola bilər. pis ünsiyyət şəraitində real vaxt. Bu cür müxtəlif arxitektura və hesablama gücünə baxmayaraq, biz eyni proqram yığınına sahib olmaq istərdik.
  3. Şemsiye memarlığı
    Metriklər son cihazda toplanmalı və birləşdirilməli, yerli olaraq saxlanmalı və real vaxtda və retrospektiv olaraq vizuallaşdırılmalıdır. Bir əlaqə varsa, məlumatları mərkəzi monitorinq sisteminə köçürün. Heç bir əlaqə olmadıqda, göndərmə növbəsi yığılmalı və RAM istehlak etməməlidir.
  4. Müştərinin monitorinq sisteminə inteqrasiya üçün API, çünki heç kimin çoxlu monitorinq sisteminə ehtiyacı yoxdur. Müştəri istənilən cihaz və şəbəkələrdən məlumatları vahid monitorinqdə toplamalıdır.

Nə olub

Onsuz da təsir edici olan uzun oxunuşu yükləməmək üçün bütün monitorinq sistemlərinin nümunələri və ölçülərini verməyəcəyəm. Bu, başqa bir məqaləyə səbəb olacaq. Sadəcə onu deyim ki, 1 millisaniyədən az xəta ilə eyni vaxtda iki ölçü götürə bilən və həm 64 MB RAM ilə ARM arxitekturasında, həm də 86 ilə x64_32 arxitekturasında eyni dərəcədə effektiv işləyən bir monitorinq sistemi tapa bilmədik. GB RAM. Buna görə də, bütün bunları edə bilən özümüzü yazmağa qərar verdik. Əldə etdiyimiz budur:

Müxtəlif şəbəkə topologiyaları üçün üç kanalın ötürmə qabiliyyətinin ümumiləşdirilməsi


Bəzi əsas göstəricilərin vizuallaşdırılması

Başqa bir monitorinq sistemi
Başqa bir monitorinq sistemi
Başqa bir monitorinq sistemi
Başqa bir monitorinq sistemi

memarlıq

Qolanqdan həm cihazda, həm də məlumat mərkəzində əsas proqramlaşdırma dili kimi istifadə edirik. O, çoxlu tapşırıqların icrası və hər bir xidmət üçün bir statik olaraq əlaqəli icra edilə bilən ikili fayl əldə etmək imkanı ilə həyatı xeyli sadələşdirdi. Nəticədə, xidmətin son cihazlarda yerləşdirilməsi, inkişaf vaxtı və kodun sazlanması üçün resurslara, metodlara və trafikə əhəmiyyətli dərəcədə qənaət edirik.

Sistem klassik modul prinsipinə uyğun olaraq həyata keçirilir və bir neçə alt sistemdən ibarətdir:

  1. Metriklərin qeydiyyatı.
    Hər bir metrik öz mövzusu ilə xidmət edir və kanallar arasında sinxronlaşdırılır. Biz 10 nanosaniyə qədər sinxronizasiya dəqiqliyinə nail ola bildik.
  2. Metrik yaddaş
    Zaman seriyası üçün öz yaddaşımızı yazmaq və ya artıq mövcud olan bir şeydən istifadə etmək arasında seçim edirdik. Verilənlər bazası sonradan vizuallaşdırmaya məruz qalan retrospektiv məlumatlar üçün lazımdır.Yəni o, kanalda hər 0.5 millisaniyədən bir gecikmələr və ya nəqliyyat şəbəkəsində xəta oxunuşları haqqında məlumatları ehtiva etmir, lakin hər bir interfeysdə hər 500 millisaniyədən bir sürət var. Çarpaz platforma və aşağı resurs istehlakı üçün yüksək tələblərə əlavə olaraq, emal edə bilmək bizim üçün son dərəcə vacibdir. məlumatların saxlandığı yerdir. Bu, böyük hesablama resurslarına qənaət edir. Biz 2016-cı ildən bu layihədə Tarantool DBMS-dən istifadə edirik və indiyə qədər üfüqdə onun əvəzini görmürük. Optimal resurs istehlakı ilə çevik, adekvat texniki dəstəkdən daha çox. Tarantool həmçinin GIS modulunu həyata keçirir. Əlbəttə ki, bu, PostGIS qədər güclü deyil, lakin bəzi yerlə əlaqəli ölçüləri (nəqliyyat üçün uyğun) saxlamaq üçün tapşırıqlarımız üçün kifayətdir.
  3. Metriklərin vizuallaşdırılması
    Burada hər şey nisbətən sadədir. Biz anbardan məlumatları götürürük və ya real vaxtda, ya da retrospektiv olaraq göstəririk.
  4. Məlumatların mərkəzi monitorinq sistemi ilə sinxronlaşdırılması.
    Mərkəzi monitorinq sistemi bütün cihazlardan məlumatları qəbul edir, müəyyən tarixçə ilə saxlayır və API vasitəsilə Müştərinin monitorinq sisteminə göndərir. "Başın" gəzdiyi və məlumat topladığı klassik monitorinq sistemlərindən fərqli olaraq, bizdə əks sxem var. Bağlantı olduqda cihazların özləri məlumat göndərirlər. Bu, çox vacib bir məqamdır, çünki o, mövcud olmadığı müddətlər üçün cihazdan məlumat almağa və cihaz mövcud olmadığı müddətdə kanalları və resursları yükləməməyə imkan verir. Biz Influx monitorinq serverindən mərkəzi monitorinq sistemi kimi istifadə edirik. Analoqlarından fərqli olaraq, o, retrospektiv məlumatları idxal edə bilər (yəni, ölçülərin qəbul edildiyi andan fərqli vaxt möhürü ilə).Toplanılan ölçülər Grafana tərəfindən vizuallaşdırılır, fayl ilə dəyişdirilir. Bu standart yığın həm də ona görə seçilmişdir ki, o, demək olar ki, istənilən müştəri monitorinq sistemi ilə hazır API inteqrasiyasına malikdir.
  5. Mərkəzi cihaz idarəetmə sistemi ilə məlumatların sinxronizasiyası.
    Cihaz idarəetmə sistemi Zero Touch Provisioning (proshivka, konfiqurasiya və s. yenilənməsi) həyata keçirir və monitorinq sistemindən fərqli olaraq, hər bir cihaz üçün yalnız problemləri qəbul edir. Bunlar bortda olan aparat nəzarəti xidmətlərinin işləməsi və həyati dəstək sistemlərinin bütün göstəriciləri üçün tətiklərdir: CPU və SSD temperaturu, CPU yükü, boş yer və disklərdə SMART sağlamlığı. Alt sistem yaddaşı da Tarantool üzərində qurulub. Bu, bizə minlərlə cihaz arasında vaxt seriyalarını toplamaqda əhəmiyyətli sürət verir və həmçinin bu cihazlarla məlumatların sinxronlaşdırılması məsələsini tamamilə həll edir. Tarantool əla növbə və zəmanətli çatdırılma sisteminə malikdir. Bu vacib xüsusiyyəti qutudan çıxardıq, əla!

Şəbəkə idarəetmə sistemi

Başqa bir monitorinq sistemi

Nədir?

Hələlik bizim ən zəif halqamız mərkəzi monitorinq sistemidir. Standart bir yığında 99.9% həyata keçirilir və bir sıra çatışmazlıqlara malikdir:

  1. InfluxDB enerji kəsildikdə məlumatları itirir. Bir qayda olaraq, Müştəri cihazlardan gələn hər şeyi dərhal toplayır və verilənlər bazası özündə 5 dəqiqədən çox olan məlumatları ehtiva etmir, lakin gələcəkdə bu, ağrıya çevrilə bilər.
  2. Grafana-da məlumatların yığılması və ekranının sinxronlaşdırılması ilə bağlı bir sıra problemlər var. Ən çox rast gəlinən problem, verilənlər bazasında məsələn, 2:00:00-dan başlayaraq 00 saniyə intervalı olan zaman seriyasının olması və Grafana-nın +1 saniyədən etibarən məlumatları ümumiləşdirməyə başlamasıdır. Nəticədə istifadəçi rəqs edən bir qrafik görür.
  3. Üçüncü tərəfin monitorinq sistemləri ilə API inteqrasiyası üçün həddindən artıq kod miqdarı. Daha yığcam edilə bilər və əlbəttə ki, Go-da yenidən yazıla bilər)

Düşünürəm ki, siz hamınız Grafana-nın necə göründüyünü mükəmməl görmüsünüz və mənsiz onun problemlərini bilirsiniz, ona görə də postu şəkillərlə yükləməyəcəyəm.

Nəticə

Mən qəsdən texniki detalları təsvir etmədim, ancaq bu sistemin əsas dizaynını təsvir etdim. Birincisi, sistemi texniki cəhətdən tam təsvir etmək üçün başqa bir məqalə tələb olunacaq. İkincisi, hər kəs bununla maraqlanmayacaq. Hansı texniki detalları bilmək istədiyinizi şərhlərdə yazın.

Kiminsə bu məqalənin əhatə dairəsindən kənar sualları varsa, mənə a.rodin @ qedr.com ünvanına yaza bilərsiniz.

Mənbə: www.habr.com

Добавить комментарий