16 modemoj, 4 ĉelaj funkciigistoj = Elira rapideco 933.45 Mbit/s
Enkonduko
Saluton! Ĉi tiu artikolo temas pri kiel ni verkis novan monitoran sistemon por ni mem. Ĝi diferencas de ekzistantaj en sia kapablo akiri altfrekvencajn sinkronajn metrikojn kaj tre malaltan rimedkonsumon. La balota indico povas atingi 0.1 milisekundojn kun sinkroniga precizeco inter metrikoj de 10 nanosekundoj. Ĉiuj binaraj dosieroj okupas 6 megabajtojn.
Pri la projekto
Ni havas sufiĉe specifan produkton. Ni produktas ampleksan solvon por resumi la trairon kaj misfunkciadon de datumtranssendokanaloj. Jen kiam ekzistas pluraj kanaloj, ni diru Operator1 (40Mbit/s) + Operator2 (30Mbit/s)+ Io alia (5 Mbit/s), la rezulto estas unu stabila kaj rapida kanalo, kies rapido estos io kiel ĉi tio: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.
Tiaj solvoj estas postulataj kie la kapablo de iu ajn kanalo estas nesufiĉa. Ekzemple, transporto, videogvatsistemoj kaj realtempa videofluado, elsendo de vivaj televidaj kaj radioelsendoj, ajnaj antaŭurbaj instalaĵoj kie inter la telekomunikaj funkciigistoj estas nur reprezentantoj de la Grandaj Kvar kaj la rapideco sur unu modemo/kanalo ne sufiĉas. .
Por ĉiu el ĉi tiuj areoj, ni produktas apartan linion de aparatoj, sed ilia programaro estas preskaŭ la sama kaj altkvalita monitora sistemo estas unu el ĝiaj ĉefaj moduloj, sen la ĝusta efektivigo de kiu la produkto ne eblus.
Dum pluraj jaroj, ni sukcesis krei plurnivelan, rapidan, transplatforman kaj malpezan monitoradsistemon. Jen kion ni volas dividi kun nia respektata komunumo.
Formulado de la problemo
La monitora sistemo disponigas metrikon de du principe malsamaj klasoj: realtempa metriko kaj ĉiuj aliaj. La monitora sistemo havis nur la sekvajn postulojn:
- Altfrekvenca sinkrona akiro de realtempaj metrikoj kaj ilia translokigo al la komunika administradsistemo senprokraste.
Altfrekvenco kaj sinkronigado de malsamaj metrikoj estas ne nur gravaj, ĝi estas esenca por analizi la entropion de datumtranssendokanaloj. Se en unu datumtranssendokanalo la averaĝa prokrasto estas 30 milisekundoj, tiam eraro en sinkronigado inter la ceteraj metrikoj de nur unu milisekundo kondukos al degenero de la rapideco de la rezulta kanalo je proksimume 5%. Se ni malĝustegas la tempon je 1 milisekundo tra 4 kanaloj, la rapideca degenero povas facile fali ĝis 30%. Krome, entropio en kanaloj ŝanĝiĝas tre rapide, do se ni mezuras ĝin malpli ol unufoje ĉiujn 0.5 milisekundojn, ĉe rapidaj kanaloj kun malgranda prokrasto ni ricevos altarapidan degradadon. Kompreneble, tia precizeco ne estas necesa por ĉiuj metrikoj kaj ne en ĉiuj kondiĉoj. Kiam la malfruo en la kanalo estas 500 milisekundoj, kaj ni laboras kun tia, tiam eraro de 1 milisekundo estos preskaŭ ne rimarkebla. Ankaŭ, por vivsubtenaj sistemaj metrikoj, ni havas sufiĉajn balotajn kaj sinkronigajn indicojn de 2 sekundoj, sed la monitora sistemo mem devas povi funkcii kun ultra-altaj balotaj indicoj kaj ultrapreciza sinkronigo de metrikoj. - Minimuma konsumo de rimedoj kaj ununura stako.
La fina aparato povas esti aŭ potenca surŝipa komplekso, kiu povas analizi la situacion sur la vojo aŭ fari biometrikan registradon de homoj, aŭ palm-granda unu-tabula komputilo, kiun specialforta soldato portas sub sia korpokiraso por transdoni videon enen. reala tempo en malbonaj komunikadokondiĉoj. Malgraŭ tia vario de arkitekturoj kaj komputa potenco, ni ŝatus havi la saman programaron stakon. - Ombrela arkitekturo
Metriko devas esti kolektitaj kaj kunigitaj sur la fina aparato, loke konservitaj kaj bildigitaj en reala tempo kaj retrospektive. Se estas konekto, transigu datumojn al la centra monitora sistemo. Kiam ne ekzistas konekto, la sendovico devas akumuliĝi kaj ne konsumi RAM. - API por integriĝo en la monitoradsistemon de la kliento, ĉar neniu bezonas multajn monitoradsistemojn. La kliento devas kolekti datumojn de iuj aparatoj kaj retoj en ununuran monitoradon.
Kio okazis
Por ne ŝarĝi la jam imponan longan legadon, mi ne donos ekzemplojn kaj mezurojn de ĉiuj monitoraj sistemoj. Ĉi tio kondukos al alia artikolo. Mi nur diros, ke ni ne povis trovi monitoran sistemon, kiu kapablas preni du metrikojn samtempe kun eraro de malpli ol 1 milisekundo kaj kiu funkcias same efike kaj sur ARM-arkitekturo kun 64 MB da RAM kaj sur x86_64-arkitekturo kun 32. GB da RAM. Tial, ni decidis skribi nian propran, kiu povas fari ĉion ĉi. Jen kion ni ricevis:
Resumante la trairon de tri kanaloj por malsamaj retaj topologioj
Bildigo de kelkaj ŝlosilaj metrikoj
arkitekturo
Ni uzas Golang kiel la ĉefan programlingvon, kaj sur la aparato kaj en la datumcentro. Ĝi ege simpligis la vivon per sia efektivigo de multitasking kaj la kapablo akiri unu statike ligitan plenumeblan binaran dosieron por ĉiu servo. Kiel rezulto, ni signife ŝparas en rimedoj, metodoj kaj trafiko por disfaldi la servon por fini aparatojn, disvolvan tempon kaj kodan sencimigon.
La sistemo estas efektivigita laŭ la klasika modula principo kaj enhavas plurajn subsistemojn:
- Registro de metrikoj.
Ĉiu metriko estas servata de sia propra fadeno kaj sinkronigita trans kanaloj. Ni povis atingi sinkronigan precizecon de ĝis 10 nanosekundoj. - Stokado de metrikoj
Ni elektis inter skribi nian propran stokadon por temposerio aŭ uzi ion, kio jam estis havebla. La datumbazo estas bezonata por retrospektivaj datumoj, kiuj estas submetitaj al posta bildigo, tio estas, ĝi ne enhavas datumojn pri malfruoj en la kanalo ĉiujn 0.5 milisekundojn aŭ erarajn legadojn en la transportreto, sed estas rapideco sur ĉiu interfaco ĉiujn 500 milisekundojn. Krom la altaj postuloj por transplataforma kaj malalta konsumo de rimedoj, estas ege grave por ni povi prilabori. datumoj estas kie ĝi estas konservita. Ĉi tio ŝparas enormajn komputigajn rimedojn. Ni uzas la Tarantool DBMS en ĉi tiu projekto ekde 2016 kaj ĝis nun ni ne vidas anstataŭaĵon por ĝi ĉe la horizonto. Fleksebla, kun optimuma konsumo de rimedoj, pli ol taŭga teknika subteno. Tarantool ankaŭ efektivigas GIS-modulon. Kompreneble, ĝi ne estas tiel potenca kiel PostGIS, sed ĝi sufiĉas por niaj taskoj konservi iujn lok-rilatajn metrikojn (gravajn por transporto). - Bildigo de metrikoj
Ĉio estas relative simpla ĉi tie. Ni prenas datumojn de la magazeno kaj montras ĝin aŭ en reala tempo aŭ retrospektive. - Sinkronigo de datumoj kun la centra monitora sistemo.
La centra monitora sistemo ricevas datumojn de ĉiuj aparatoj, konservas ĝin kun specifita historio kaj sendas ĝin al la monitora sistemo de la Kliento per API. Male al klasikaj monitoraj sistemoj, en kiuj la "kapo" promenas kaj kolektas datumojn, ni havas la kontraŭan skemon. La aparatoj mem sendas datumojn kiam estas konekto. Ĉi tio estas tre grava punkto, ĉar ĝi ebligas al vi ricevi datumojn de la aparato dum tiuj tempodaŭroj dum kiuj ĝi ne estis disponebla kaj ne ŝargi kanalojn kaj rimedojn dum la aparato ne estas disponebla. Ni uzas Influx-monitoran servon kiel centran monitoran sistemon. Male al siaj analogoj, ĝi povas importi retrospektivajn datumojn (t.e. kun tempomarko malsama al la momento, kiam la metrikoj estis ricevitaj).La kolektitaj metrikoj estas bildigitaj de Grafana, modifitaj per dosiero. Ĉi tiu norma stako ankaŭ estis elektita ĉar ĝi havas pretajn API-integriĝojn kun preskaŭ ajna klienta monitoradsistemo. - Sinkronigado de datumoj kun centra aparato-administra sistemo.
La aparato-administra sistemo efektivigas Zero Touch Provisioning (ĝisdatigado de firmvaro, agordo, ktp.) kaj, male al la monitora sistemo, ricevas nur problemojn per aparato. Ĉi tiuj estas ellasiloj por la funkciado de surŝipe aparataj gardoservoj kaj ĉiuj metrikoj de vivsubtenaj sistemoj: CPU kaj SSD-temperaturo, CPU-ŝarĝo, libera spaco kaj SMART-sano sur diskoj. La subsistemstokado ankaŭ estas konstruita sur Tarantool. Ĉi tio donas al ni signifan rapidecon en agregado de temposerio tra miloj da aparatoj, kaj ankaŭ tute solvas la problemon de sinkronigado de datumoj kun ĉi tiuj aparatoj. Tarantool havas bonegan vica kaj garantiita liversistemo. Ni akiris ĉi tiun gravan funkcion el la skatolo, bonege!
Reta mastruma sistemo
Kio sekvas
Ĝis nun, nia plej malforta ligo estas la centra monitora sistemo. Ĝi estas efektivigita 99.9% sur norma stako kaj havas kelkajn malavantaĝojn:
- InfluxDB perdas datumojn kiam potenco estas perdita. Kiel regulo, la Kliento senprokraste kolektas ĉion, kio venas de la aparatoj kaj la datumbazo mem ne enhavas datumojn pli malnovajn ol 5 minutojn, sed estonte tio povas iĝi doloro.
- Grafana havas kelkajn problemojn kun datuma agregado kaj sinkronigado de sia ekrano. La plej ofta problemo estas kiam la datumbazo enhavas temposerion kun intervalo de 2 sekundoj ekde, ekzemple, 00:00:00, kaj Grafana komencas montri datumojn en agregado de +1 sekundo. Kiel rezulto, la uzanto vidas dancan grafeon.
- Troa kvanto de kodo por API-integriĝo kun triaj monitoraj sistemoj. Ĝi povas esti multe pli kompakta kaj kompreneble reverkita en Go)
Mi pensas, ke vi ĉiuj perfekte vidis, kiel aspektas Grafana kaj konas ĝiajn problemojn sen mi, do mi ne troŝarĝos la afiŝon per bildoj.
konkludo
Mi intence ne priskribis la teknikajn detalojn, sed priskribis nur la bazan dezajnon de ĉi tiu sistemo. Unue, por teknike plene priskribi la sistemon, alia artikolo estos postulata. Due, ne ĉiuj interesiĝos pri tio. Skribu en la komentoj kiajn teknikajn detalojn vi ŝatus scii.
Se iu havas demandojn ekster la amplekso de ĉi tiu artikolo, vi povas skribi al mi ĉe a.rodin @ qedr.com
fonto: www.habr.com