Annað eftirlitskerfi

16 mótald, 4 farsímafyrirtæki = Útsendingarhraði 933.45 Mbit/s

Inngangur

Halló! Þessi grein fjallar um hvernig við skrifuðum nýtt eftirlitskerfi fyrir okkur sjálf. Það er frábrugðið þeim sem fyrir eru í getu sinni til að fá samstilltar hátíðnimælingar og mjög litla auðlindanotkun. Könnunartíðni getur náð 0.1 millisekúndum með samstillingarnákvæmni milli mæligilda upp á 10 nanósekúndur. Allar tvöfaldar skrár taka 6 megabæti.

Um verkefnið

Við erum með frekar ákveðna vöru. Við framleiðum alhliða lausn til að draga saman afköst og bilanaþol gagnaflutningsrása. Þetta er þegar það eru nokkrar rásir, segjum Operator1 (40Mbit/s) + Operator2 (30Mbit/s)+ Eitthvað annað (5 Mbit/s), niðurstaðan er ein stöðug og hröð rás, hraðinn á henni verður eitthvað eins og þetta: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.

Slíkar lausnir eru eftirsóttar þar sem afkastageta einhverrar rásar er ófullnægjandi. Til dæmis, samgöngur, myndbandseftirlitskerfi og rauntíma straumspilun myndbanda, útsendingar á beinum sjónvarps- og útvarpsútsendingum, hvers kyns úthverfaaðstöðu þar sem meðal fjarskiptafyrirtækja eru aðeins fulltrúar stóru fjögurra og hraðinn á einni mótaldi/rás er ekki nægur. .
Fyrir hvert þessara svæða framleiðum við sérstaka línu af tækjum, en hugbúnaðarhluti þeirra er nánast sá sami og hágæða eftirlitskerfi er ein af aðaleiningum þess, án réttrar útfærslu sem varan væri ekki möguleg.

Á nokkrum árum tókst okkur að búa til fjölþrepa, hratt, þvert á vettvang og létt eftirlitskerfi. Þetta er það sem við viljum deila með okkar virta samfélagi.

Samsetning vandans

Vöktunarkerfið veitir mælikvarða fyrir tvo í grundvallaratriðum mismunandi flokka: rauntímamælingar og alla aðra. Vöktunarkerfið hafði aðeins eftirfarandi kröfur:

1. Hátíðni samstillt öflun rauntímamælinga og flutning þeirra yfir í samskiptastjórnunarkerfið án tafar.
   Hátíðni og samstilling mismunandi mælikvarða er ekki bara mikilvægt, það er mikilvægt til að greina óreiðu gagnaflutningsrása. Ef í einni gagnaflutningsrás er meðaltöfin 30 millisekúndur, þá mun villa í samstillingu á milli mæligildanna sem eftir eru, aðeins eina millisekúnda leiða til lækkunar á hraða rásarinnar sem myndast um það bil 5%. Ef við mistakum tímasetninguna um 1 millisekúndu yfir 4 rásir, getur hraðaskerðingin auðveldlega farið niður í 30%. Að auki breytist óreiðu í rásum mjög hratt, þannig að ef við mælum hana sjaldnar en einu sinni á 0.5 millisekúndna fresti, á hröðum rásum með lítilli töf munum við fá hraða niðurbrot. Auðvitað er slík nákvæmni ekki nauðsynleg fyrir allar mælingar og ekki við allar aðstæður. Þegar seinkunin í rásinni er 500 millisekúndur, og við vinnum með slíkt, þá verður villa upp á 1 millisekúnd nánast ekki áberandi. Einnig, fyrir mælikvarða á lífsbjörgunarkerfi, höfum við nóg könnunar- og samstillingartíðni upp á 2 sekúndur, en eftirlitskerfið sjálft verður að geta unnið með ofurháum könnunartíðni og ofurnákvæmri samstillingu mæligilda.
2. Lágmarks auðlindanotkun og stakur stakkur.
   Endabúnaðurinn getur verið annað hvort öflugt flókið um borð sem getur greint aðstæður á veginum eða framkvæmt líffræðileg tölfræðiupptöku af fólki, eða lófastærð eins borðs tölva sem sérsveitarhermaður klæðist undir herklæðum sínum til að senda myndbönd í rauntíma við slæmar samskiptaaðstæður. Þrátt fyrir svo fjölbreyttan arkitektúr og tölvugetu viljum við hafa sama hugbúnaðarstokkinn.
3. Regnhlífararkitektúr
   Mælingum verður að safna og safna saman á lokatækinu, hafa staðbundna geymslu og vera sýndar í rauntíma og afturvirkt. Ef tenging er til staðar skaltu flytja gögn yfir í miðlæga eftirlitskerfið. Þegar engin tenging er til staðar ætti sendiröðin að safnast upp og neyta ekki vinnsluminni.
4. API fyrir samþættingu í eftirlitskerfi viðskiptavinarins, því enginn þarf mörg eftirlitskerfi. Viðskiptavinurinn verður að safna gögnum úr öllum tækjum og netkerfum í eina vöktun.

Hvað gerðist

Til að íþyngja ekki hinum þegar áhrifamikla langlestri mun ég ekki gefa dæmi og mælingar á öllum vöktunarkerfum. Þetta mun leiða til annarrar greinar. Ég segi bara að við gátum ekki fundið eftirlitskerfi sem er fær um að taka tvær mælingar samtímis með villu sem er innan við 1 millisekúndu og sem virkar jafn áhrifaríkt bæði á ARM arkitektúr með 64 MB af vinnsluminni og á x86_64 arkitektúr með 32 GB af vinnsluminni. Þess vegna ákváðum við að skrifa okkar eigin, sem getur allt þetta. Hér er það sem við fengum:

Tekur saman afköst þriggja rása fyrir mismunandi netkerfi

Sýning á nokkrum lykilmælingum

arkitektúr

Við notum Golang sem aðal forritunarmál, bæði í tækinu og í gagnaverinu. Það einfaldaði lífið til muna með útfærslu sinni á fjölverkavinnslu og getu til að fá eina kyrrstöðutengda keyranlega tvöfalda skrá fyrir hverja þjónustu. Fyrir vikið spörum við umtalsvert fjármagn, aðferðir og umferð til að dreifa þjónustunni til að loka tækjum, þróunartíma og kembiforrit.

Kerfið er útfært í samræmi við klassíska mátregluna og inniheldur nokkur undirkerfi:

1. Skráning mæligilda.
   Hver mælikvarði er þjónað af sínum eigin þræði og samstilltur á milli rása. Okkur tókst að ná samstillingarnákvæmni upp á allt að 10 nanósekúndur.
2. Geymsla mæligilda
   Við vorum að velja á milli þess að skrifa okkar eigin geymslu fyrir tímaraðir eða nota eitthvað sem þegar var til. Gagnagrunnurinn er nauðsynlegur fyrir afturskyggn gögn sem eru háð síðari myndsýn, það er að hann inniheldur ekki gögn um tafir í rásinni á 0.5 millisekúndna fresti eða villuálestur í flutningsnetinu heldur er hraði á hverju viðmóti á 500 millisekúndna fresti. Til viðbótar við miklar kröfur um þvert á vettvang og litla auðlindanotkun er afar mikilvægt fyrir okkur að geta unnið. gögn eru þar sem þau eru geymd. Þetta sparar gífurlegar tölvuauðlindir. Við höfum notað Tarantool DBMS í þessu verkefni síðan 2016 og enn sem komið er sjáum við ekki staðgengil fyrir það á sjóndeildarhringnum. Sveigjanlegur, með bestu auðlindanotkun, meira en fullnægjandi tækniaðstoð. Tarantool útfærir einnig GIS mát. Auðvitað er það ekki eins öflugt og PostGIS, en það er nóg fyrir verkefni okkar að geyma nokkrar staðsetningartengdar mælikvarða (sem skiptir máli fyrir flutninga).
3. Sjónræn mæling
   Hér er allt tiltölulega einfalt. Við tökum gögn úr vöruhúsinu og birtum þau annað hvort í rauntíma eða afturvirkt.
4. Samstilling gagna við miðlæga eftirlitskerfið.
   Miðlæga eftirlitskerfið tekur við gögnum frá öllum tækjum, geymir þau með tilgreindri sögu og sendir til eftirlitskerfis viðskiptavinar í gegnum API. Ólíkt klassískum vöktunarkerfum, þar sem „hausinn“ gengur um og safnar gögnum, höfum við hið gagnstæða kerfi. Tækin sjálf senda gögn þegar tenging er. Þetta er mjög mikilvægt atriði, þar sem það gerir þér kleift að taka á móti gögnum frá tækinu fyrir þau tímabil sem þau voru ekki tiltæk og ekki hlaða rásum og tilföngum á meðan tækið er ekki tiltækt. Við notum innflæðiseftirlitsþjón sem miðlægt eftirlitskerfi. Ólíkt hliðstæðum þess getur það flutt inn afturskyggn gögn (þ.e. með öðrum tímastimpli frá því augnabliki sem mælingarnar voru mótteknar) Safnaða mælikvarða er sýndur af Grafana, breytt með skrá. Þessi staðall stafli var einnig valinn vegna þess að hann hefur tilbúnar API samþættingar við nánast hvaða eftirlitskerfi sem er fyrir viðskiptavini.
5. Gagnasamstilling við miðlægt tækjastjórnunarkerfi.
   Tækjastjórnunarkerfið innleiðir Zero Touch Provisioning (uppfærslu vélbúnaðar, stillingar osfrv.) og, ólíkt eftirlitskerfinu, fær aðeins vandamál á hvert tæki. Þetta eru kveikjur fyrir rekstur vélbúnaðarvaktarþjónustu um borð og allar mælikvarðar lífstuðningskerfa: CPU og SSD hitastig, CPU álag, laust pláss og SMART heilsa á diskum. Geymsla undirkerfisins er einnig byggð á Tarantool. Þetta gefur okkur umtalsverðan hraða við að safna tímaröðum yfir þúsundir tækja og leysir einnig algjörlega vandamálið við að samstilla gögn við þessi tæki. Tarantool er með frábæra biðröð og tryggt afhendingarkerfi. Við fengum þennan mikilvæga eiginleika úr kassanum, frábært!

Netstjórnunarkerfi

Hvað er næst

Hingað til er veikasti hlekkurinn okkar miðlæga eftirlitskerfið. Það er útfært 99.9% á venjulegum stafla og hefur fjölda ókosta:

1. InfluxDB tapar gögnum þegar rafmagn tapast. Viðskiptavinurinn safnar að jafnaði öllu sem kemur frá tækjunum án tafar og gagnagrunnurinn sjálfur inniheldur ekki gögn eldri en 5 mínútur, en í framtíðinni gæti þetta orðið sársaukafullt.
2. Grafana hefur ýmis vandamál með gagnasöfnun og samstillingu á skjánum. Algengasta vandamálið er þegar gagnagrunnurinn inniheldur tímaröð með 2 sekúndna millibili sem byrjar frá td 00:00:00 og Grafana byrjar að sýna gögn samanlagt frá +1 sekúndu. Fyrir vikið sér notandinn dansandi línurit.
3. Of mikið af kóða fyrir API samþættingu við eftirlitskerfi þriðja aðila. Það er hægt að gera það mun þéttara og að sjálfsögðu endurskrifa það í Go)

Ég held að þið hafið öll séð fullkomlega hvernig Grafana lítur út og þekki vandamál þess án mín, svo ég mun ekki ofhlaða færslunni með myndum.

Ályktun

Ég lýsti vísvitandi ekki tæknilegum smáatriðum, heldur lýsti aðeins grunnhönnun þessa kerfis. Í fyrsta lagi, til að lýsa kerfinu tæknilega að fullu, verður önnur grein krafist. Í öðru lagi munu ekki allir hafa áhuga á þessu. Skrifaðu í athugasemdirnar hvaða tæknilegu upplýsingar þú vilt vita.

Ef einhver hefur spurningar utan gildissviðs þessarar greinar geturðu skrifað mér á a.rodin @ qedr.com

Heimild: www.habr.com