ProHoster > Blogs > Administrācija > Vēl viena uzraudzības sistēma

Vēl viena uzraudzības sistēma

Vēl viena uzraudzības sistēma
16 modemi, 4 mobilo sakaru operatori = izejoŔā ātrums 933.45 Mbit/s

Ievads

Sveiki! Å is raksts ir par to, kā mēs izveidojām sev jaunu uzraudzÄ«bas sistēmu. Tas atŔķiras no esoÅ”ajiem ar spēju iegÅ«t augstfrekvences sinhronos rādÄ«tājus un ļoti zemu resursu patēriņu. Aptaujas ātrums var sasniegt 0.1 milisekundi ar sinhronizācijas precizitāti starp metrikas 10 nanosekundēm. Visi binārie faili aizņem 6 megabaitus.

Par projektu

Mums ir diezgan specifisks produkts. Mēs ražojam visaptveroÅ”u risinājumu datu pārraides kanālu caurlaidspējas un kļūdu tolerances apkopoÅ”anai. Tas ir tad, kad ir vairāki kanāli, teiksim Operator1 (40Mbit/s) + Operator2 (30Mbit/s)+ Kaut kas cits (5 Mbit/s), rezultāts ir viens stabils un ātrs kanāls, kura ātrums bÅ«s kaut kas lÄ«dzÄ«gs Å”is: (40+ 30+5)x0.92=75Ɨ0.92=69 Mbit/s.

Šādi risinājumi ir pieprasÄ«ti, ja viena kanāla jauda nav pietiekama. Piemēram, transports, videonovēroÅ”anas sistēmas un reāllaika video straumÄ“Å”ana, televÄ«zijas un radio tieÅ”raides, jebkuras piepilsētas iespējas, kur starp telekomunikāciju operatoriem ir tikai lielā četrinieka pārstāvji un ar ātrumu vienā modemā/kanālā nepietiek. .
Katrai no Ŕīm jomām ražojam atseviŔķu ierīču lÄ«niju, taču to programmatÅ«ras daļa ir gandrÄ«z vienāda un kvalitatÄ«va uzraudzÄ«bas sistēma ir viens no tās galvenajiem moduļiem, bez kura pareizas ievieÅ”anas produkts nebÅ«tu iespējams.

Vairāku gadu laikā mums izdevās izveidot daudzlīmeņu, ātru, starpplatformu un vieglu uzraudzības sistēmu. Tas ir tas, ko mēs vēlamies dalīties ar mūsu cienījamo kopienu.

Problēmas paziņojums

UzraudzÄ«bas sistēma nodroÅ”ina divu bÅ«tiski atŔķirÄ«gu klaÅ”u metriku: reāllaika metriku un visas pārējās. UzraudzÄ«bas sistēmai bija tikai Ŕādas prasÄ«bas:

  1. Augstas frekvences sinhrona reāllaika metriku iegÅ«Å”ana un to pārsÅ«tÄ«Å”ana uz sakaru vadÄ«bas sistēmu bez kavÄ“Å”anās.
    Augsta frekvence un dažādu metriku sinhronizācija ir ne tikai svarÄ«ga, tā ir bÅ«tiska datu pārraides kanālu entropijas analÄ«zei. Ja vienā datu pārraides kanālā vidējā aizkave ir 30 milisekundes, tad tikai vienas milisekundes sinhronizācijas kļūda starp atlikuÅ”ajiem rādÄ«tājiem izraisÄ«s iegÅ«tā kanāla ātruma samazināŔanos par aptuveni 5%. Ja 1 kanālos nepareizu laiku nofiksēsim par 4 milisekundi, ātruma samazināŔanās var viegli samazināties lÄ«dz 30%. Turklāt entropija kanālos mainās ļoti ātri, tāpēc, mērot to retāk kā reizi 0.5 milisekundēs, ātrajos kanālos ar nelielu aizkavi iegÅ«sim liela ātruma degradāciju. Protams, Ŕāda precizitāte nav nepiecieÅ”ama visiem rādÄ«tājiem un ne visos apstākļos. Kad kanāla aizkave ir 500 milisekundes un mēs ar tādu strādājam, tad 1 milisekundes kļūda gandrÄ«z nebÅ«s pamanāma. ArÄ« dzÄ«vÄ«bas uzturÄ“Å”anas sistēmas metrikai mums ir pietiekami daudz aptauju un sinhronizācijas 2 sekunžu, bet paÅ”ai uzraudzÄ«bas sistēmai ir jāspēj strādāt ar Ä«paÅ”i augstiem aptaujas rādÄ«tājiem un Ä«paÅ”i precÄ«zu metrikas sinhronizāciju.
  2. Minimāls resursu patēriņŔ un viena kaudze.
    Gala ierÄ«ce var bÅ«t vai nu jaudÄ«gs borta komplekss, kas var analizēt situāciju uz ceļa vai veikt cilvēku biometrisko ierakstu, vai arÄ« plaukstas izmēra viena borta dators, ko speciālo spēku karavÄ«rs nēsā zem bruņuvestēm, lai pārraidÄ«tu video. reāllaikā sliktos komunikācijas apstākļos. Neskatoties uz tik dažādajām arhitektÅ«rām un skaitļoÅ”anas jaudām, mēs vēlētos, lai programmatÅ«ra bÅ«tu vienāda.
  3. Lietussargu arhitektūra
    Metrika ir jāapkopo un jāapkopo gala ierÄ«cē, lokāli jāsaglabā un jāvizualizē reāllaikā un retrospektÄ«vi. Ja ir savienojums, pārsÅ«tiet datus uz centrālo uzraudzÄ«bas sistēmu. Ja nav savienojuma, sÅ«tÄ«Å”anas rindai vajadzētu uzkrāties, nevis patērēt RAM.
  4. API integrācijai klienta uzraudzības sistēmā, jo nevienam nav vajadzīgas daudzas uzraudzības sistēmas. Klientam ir jāapkopo dati no visām ierīcēm un tīkliem vienā uzraudzībā.

Kas notika

Lai nenoslogotu jau tā iespaidÄ«go garo lasÄ«Å”anu, es nesniegÅ”u visu monitoringa sistēmu piemērus un mērÄ«jumus. Tas novedÄ«s pie cita raksta. Es tikai teikÅ”u, ka mēs nevarējām atrast uzraudzÄ«bas sistēmu, kas spēj uzņemt divus rādÄ«tājus vienlaikus ar kļūdu, kas mazāka par 1 milisekundi un kas darbojas vienlÄ«dz efektÄ«vi gan ARM arhitektÅ«rā ar 64 MB RAM, gan x86_64 arhitektÅ«rā ar 32 MB. GB RAM. Tāpēc mēs nolēmām rakstÄ«t paÅ”i, kas to visu var izdarÄ«t. LÅ«k, ko mēs saņēmām:

Apkopojot trīs kanālu caurlaidspēju dažādām tīkla topoloģijām


Dažu galveno rādītāju vizualizācija

Vēl viena uzraudzības sistēma
Vēl viena uzraudzības sistēma
Vēl viena uzraudzības sistēma
Vēl viena uzraudzības sistēma

Arhitektūra

Mēs izmantojam Golang kā galveno programmÄ“Å”anas valodu gan ierÄ«cē, gan datu centrā. Tas ievērojami vienkārÅ”oja dzÄ«vi, ievieÅ”ot daudzuzdevumu veikÅ”anu un iespēju katram pakalpojumam iegÅ«t vienu statiski saistÄ«tu izpildāmo bināro failu. Rezultātā mēs ievērojami ietaupām resursus, metodes un trafiku pakalpojuma izvietoÅ”anai gala ierÄ«cēs, izstrādes laiku un koda atkļūdoÅ”anu.

Sistēma ir ieviesta pēc klasiskā moduļu principa un satur vairākas apakÅ”sistēmas:

  1. Metrikas reģistrācija.
    Katra metrika tiek apkalpota ar savu pavedienu un tiek sinhronizēta dažādos kanālos. Mēs varējām sasniegt sinhronizācijas precizitāti līdz 10 nanosekundēm.
  2. Metrikas glabāŔana
    Mēs izvēlējāmies rakstÄ«t savu krātuvi laikrindām vai izmantot kaut ko, kas jau bija pieejams. Datu bāze ir nepiecieÅ”ama retrospektÄ«viem datiem, kas tiek pakļauti turpmākai vizualizācijai, proti, tajā nav datu par kanāla aizkavÄ“Å”anos ik pēc 0.5 milisekundēm vai kļūdu rādÄ«jumiem transporta tÄ«klā, bet katrā saskarnē ir ātrums ik pēc 500 milisekundēm. Papildus augstajām prasÄ«bām attiecÄ«bā uz starpplatformu un zemu resursu patēriņu mums ir ārkārtÄ«gi svarÄ«gi, lai mēs varētu apstrādāt. dati ir vieta, kur tie tiek glabāti. Tas ietaupa milzÄ«gus skaitļoÅ”anas resursus. Tarantool DBVS Å”ajā projektā esam izmantojuÅ”i kopÅ” 2016. gada, un pagaidām neredzam, ka tā varētu aizstāt. ElastÄ«gs, ar optimālu resursu patēriņu, vairāk nekā atbilstoÅ”u tehnisko atbalstu. Tarantool ievieÅ” arÄ« Ä¢IS moduli. Protams, tas nav tik spēcÄ«gs kā PostGIS, taču ar to pietiek mÅ«su uzdevumiem, lai saglabātu dažus ar atraÅ”anās vietu saistÄ«tus rādÄ«tājus (kas attiecas uz transportu).
  3. Metrikas vizualizācija
    Å eit viss ir salÄ«dzinoÅ”i vienkārÅ”i. Mēs ņemam datus no noliktavas un parāda tos vai nu reāllaikā, vai retrospektÄ«vi.
  4. Datu sinhronizācija ar centrālo uzraudzības sistēmu.
    Centrālā uzraudzÄ«bas sistēma saņem datus no visām ierÄ«cēm, saglabā tos ar noteiktu vēsturi un nosÅ«ta Klienta uzraudzÄ«bas sistēmai, izmantojot API. AtŔķirÄ«bā no klasiskajām uzraudzÄ«bas sistēmām, kurās ā€œgalvaā€ staigā un vāc datus, mums ir pretēja shēma. PaÅ”as ierÄ«ces sÅ«ta datus, kad ir savienojums. Tas ir ļoti svarÄ«gs punkts, jo tas ļauj saņemt datus no ierÄ«ces par tiem laika periodiem, kuros tie nebija pieejami, un neielādēt kanālus un resursus, kamēr ierÄ«ce nav pieejama. Mēs izmantojam Influx monitoringa serveri kā centrālo uzraudzÄ«bas sistēmu. AtŔķirÄ«bā no analogiem, tas var importēt retrospektÄ«vus datus (tas ir, ar laika zÄ«mogu, kas atŔķiras no metrikas saņemÅ”anas brīža). Savāktos rādÄ«tājus vizualizē Grafana, modificē ar failu. Å is standarta steks tika izvēlēts arÄ« tāpēc, ka tai ir gatavas API integrācijas ar gandrÄ«z jebkuru klientu uzraudzÄ«bas sistēmu.
  5. Datu sinhronizācija ar centrālo ierīču vadības sistēmu.
    Ierīču pārvaldÄ«bas sistēma ievieÅ” Zero Touch Provisioning (atjaunina programmaparatÅ«ru, konfigurāciju utt.) un atŔķirÄ«bā no uzraudzÄ«bas sistēmas saņem tikai problēmas katrā ierÄ«cē. Tie ir aktivizētāji borta aparatÅ«ras sargsuņa pakalpojumu darbÄ«bai un visiem dzÄ«vÄ«bas uzturÄ“Å”anas sistēmu rādÄ«tājiem: CPU un SSD temperatÅ«ra, CPU slodze, brÄ«vā vieta un SMART stāvoklis diskos. ApakÅ”sistēmas krātuve arÄ« ir veidota uz Tarantool. Tas nodroÅ”ina ievērojamu ātrumu laika rindu apkopoÅ”anā tÅ«kstoÅ”iem ierīču, kā arÄ« pilnÄ«bā atrisina datu sinhronizÄ“Å”anas problēmu ar Ŕīm ierÄ«cēm. Tarantool ir lieliska rindu un garantēta piegādes sistēma. Mēs izņēmām Å”o svarÄ«go funkciju, lieliski!

Tīkla vadības sistēma

Vēl viena uzraudzības sistēma

Kas ir nākamais

LÄ«dz Å”im mÅ«su vājākais posms ir centrālā uzraudzÄ«bas sistēma. Tas ir ieviests par 99.9% standarta kaudzē, un tam ir vairāki trÅ«kumi:

  1. InfluxDB zaudē datus, kad tiek zaudēta jauda. Parasti Klients operatÄ«vi apkopo visu, kas nāk no ierÄ«cēm, un paŔā datu bāzē nav dati, kas vecāki par 5 minÅ«tēm, taču nākotnē tas var kļūt par sāpēm.
  2. Grafana ir vairākas problēmas ar datu apkopoÅ”anu un displeja sinhronizāciju. VisizplatÄ«tākā problēma ir tad, ja datu bāzē ir laika rindas ar 2 sekunžu intervālu, sākot, piemēram, 00:00:00, un Grafana sāk rādÄ«t datus apkopotā veidā no +1 sekundes. Rezultātā lietotājs redz dejojoÅ”u grafiku.
  3. PārmērÄ«gs koda daudzums API integrācijai ar treŔās puses uzraudzÄ«bas sistēmām. To var padarÄ«t daudz kompaktāku un, protams, pārrakstÄ«t Go)

Es domāju, ka jÅ«s visi esat lieliski redzējuÅ”i, kā izskatās Grafana, un zināt tās problēmas bez manis, tāpēc es nepārslogoÅ”u ierakstu ar attēliem.

Secinājums

Es apzināti neaprakstÄ«ju tehniskās detaļas, bet aprakstÄ«ju tikai Ŕīs sistēmas pamata dizainu. Pirmkārt, lai tehniski pilnÄ«bā aprakstÄ«tu sistēmu, bÅ«s nepiecieÅ”ams vēl viens raksts. Otrkārt, ne visus tas interesēs. Komentāros ierakstiet, kādas tehniskās detaļas vēlaties uzzināt.

Ja kādam ir jautājumi, kas neattiecas uz Ŕo rakstu, varat rakstīt man uz a.rodin @ qedr.com

Avots: www.habr.com

Pievieno komentāru