Ĉi tiu rakonto temas pri kiel ni uzas ujojn en produktadmedio, specife Kubernetes. La artikolo estas dediĉita al kolektado de metrikoj kaj protokoloj el ujoj, kaj ankaŭ al konstruado de bildoj.

Ni estas de la fintech-kompanio Exness, kiu disvolvas servojn por interreta komerco kaj fintech-produktojn por B2B kaj B2C. Nia R&D havas multajn malsamajn teamojn, la disvolva fako havas 100+ dungitojn.

Ni reprezentas la teamon, kiu respondecas pri la platformo por niaj programistoj kolekti kaj ruli kodon. Aparte, ni respondecas pri kolektado, stokado kaj raportado de metrikoj, protokoloj kaj eventoj de aplikaĵoj. Ni nuntempe funkciigas proksimume tri mil Docker-ujojn en produktadmedio, konservas nian 50 TB-datuman stokadon kaj provizas arkitekturajn solvojn, kiuj estas konstruitaj ĉirkaŭ nia infrastrukturo: Kubernetes, Rancher kaj diversaj publikaj nubaj provizantoj. 

Nia instigo

Kio brulas? Neniu povas respondi. Kie estas la kameno? Estas malfacile kompreni. Kiam ĝi ekbrulis? Vi povas ekscii, sed ne tuj. 

Kial iuj ujoj staras dum aliaj falis? Kiu ujo estis kulpa? Post ĉio, la ekstero de la ujoj estas la sama, sed ene ĉiu havas sian propran Neo.

Niaj programistoj estas kompetentaj uloj. Ili faras bonajn servojn, kiuj alportas profiton al la kompanio. Sed estas misfunkciadoj kiam ujoj kun aplikoj erarvas. Unu ujo konsumas tro da CPU, alia konsumas la reton, tria konsumas I/O-operaciojn, kaj la kvara estas tute neklara, kion ĝi faras kun ingoj. Ĉio falas kaj la ŝipo sinkas. 

Agentoj

Por kompreni kio okazas interne, ni decidis meti agentojn rekte en ujojn.

Ĉi tiuj agentoj retenas programojn, kiuj tenas ujojn en tia stato, ke ili ne rompas unu la alian. Agentoj estas normigitaj, kaj tio permesas normigitan aliron al servado de ujoj. 

En nia kazo, agentoj devas provizi protokolojn en norma formato, etikeditaj kaj strekitaj. Ili ankaŭ devus provizi al ni normigitajn metrikojn, kiuj estas etendeblaj de komerca aplika perspektivo.

Agentoj ankaŭ signifas utilecojn por funkciado kaj prizorgado, kiuj povas funkcii en malsamaj orkestradsistemoj, kiuj subtenas malsamajn bildojn (Debian, Alpine, Centos, ktp.).

Fine, agentoj devas subteni simplajn CI/KD, kiuj inkluzivas Docker-dosierojn. Alie, la ŝipo disfalos, ĉar ujoj komencos esti liveritaj laŭ "kurbaj" reloj.

Konstruu procezo kaj cela bilda aparato

Por konservi ĉion normigita kaj regebla, ia norma konstruprocezo devas esti sekvita. Tial ni decidis kolekti ujojn per ujoj - tio estas rekursio.

Ĉi tie la ujoj estas reprezentitaj per solidaj konturoj. Samtempe ili decidis enmeti distribuajn ilojn por ke "la vivo ne ŝajnu framboj". Kial ĉi tio estis farita, ni klarigos sube.
 
La rezulto estas konstrua ilo—versiospecifa ujo, kiu referencas specifajn distribuajn versiojn kaj specifajn skriptversiojn.

Kiel ni uzas ĝin? Ni havas Docker Hub kiu enhavas ujon. Ni spegulas ĝin ene de nia sistemo por forigi eksterajn dependecojn. La rezulto estas ujo markita flava. Ni kreas ŝablonon por instali ĉiujn distribuojn kaj skriptojn, kiujn ni bezonas en la ujo. Post tio, ni kunmetas pretan uzeblan bildon: programistoj metas kodon kaj kelkajn el siaj propraj specialaj dependecoj en ĝin. 

Kio estas bona pri ĉi tiu aliro? 

• Unue, plena versio-kontrolo de konstruaj iloj - konstruu ujon, skripton kaj distribuajn versiojn. 
• Due, ni atingis normigon: ni kreas ŝablonojn, mezan kaj uzeblan bildon sammaniere. 
• Trie, ujoj donas al ni porteblon. Hodiaŭ ni uzas Gitlab, kaj morgaŭ ni ŝanĝos al TeamCity aŭ Jenkins kaj ni povos funkcii niajn ujojn same. 
• Kvare, minimumigi dependecojn. Ne hazarde ni metis distribuajn ilojn en la ujo, ĉar ĉi tio ebligas al ni ĉiufoje eviti elŝuti ilin el Interreto. 
• Kvine, la konstrurapideco pliiĝis - la ĉeesto de lokaj kopioj de bildoj permesas eviti malŝpari tempon dum elŝutado, ĉar ekzistas loka bildo. 

Alivorte, ni atingis kontrolitan kaj flekseblan kunigprocezon. Ni uzas la samajn ilojn por konstrui ajnajn plene versionitajn ujojn. 

Kiel funkcias nia konstruprocedo

La aro estas lanĉita per unu komando, la procezo estas ekzekutita en la bildo (markita en ruĝa). La programisto havas Docker-dosieron (markitan flave), ni redonas ĝin, anstataŭigante variablojn per valoroj. Kaj survoje ni aldonas kapliniojn kaj piedliniojn - ĉi tiuj estas niaj agentoj. 

Kapo aldonas distribuojn de la respondaj bildoj. Kaj piedlinio instalas niajn servojn interne, agordas la lanĉon de laborŝarĝo, protokolo kaj aliaj agentoj, anstataŭigas enirpunkton, ktp. 

Ni pensis dum longa tempo ĉu instali kontroliston. Fine ni decidis, ke ni bezonas lin. Ni elektis S6. La kontrolisto provizas ujo-administradon: permesas vin konekti al ĝi se la ĉefa procezo kraŝas kaj provizas manan administradon de la ujo sen rekrei ĝin. Registroj kaj metrikoj estas procezoj kurantaj en la ujo. Ili ankaŭ devas esti kontrolitaj iel, kaj ni faras tion kun la helpo de kontrolisto. Fine, la S6 zorgas pri mastrumado, signal-prilaborado kaj aliaj taskoj.

Ĉar ni uzas malsamajn orkestradsistemojn, post konstruado kaj funkciado, la ujo devas kompreni en kia medio ĝi estas kaj agi laŭ la situacio. Ekzemple:
Ĉi tio permesas al ni konstrui unu bildon kaj ruli ĝin en malsamaj orkestradsistemoj, kaj ĝi estos lanĉita konsiderante la specifaĵoj de ĉi tiu orkestradsistemo.

 

Por la sama ujo ni ricevas malsamajn procezajn arbojn en Docker kaj Kubernetes:

La utila ŝarĝo estas efektivigita sub la superrigardo de S6. Atentu kolektanton kaj eventojn - ĉi tiuj estas niaj agentoj respondecaj pri protokoloj kaj metrikoj. Kubernetes ne havas ilin, sed Docker havas. Kial? 

Se ni rigardas la specifon de la "pod" (ĉi-poste - Kubernetes pod), ni vidos, ke la evento-ujo estas ekzekutita en pod, kiu havas apartan kolektan ujon, kiu plenumas la funkcion kolekti metrikojn kaj protokolojn. Ni povas uzi la kapablojn de Kubernetes: ruli ujojn en unu pod, en ununura procezo kaj/aŭ retspaco. Efektive prezentu viajn agentojn kaj plenumu kelkajn funkciojn. Kaj se la sama ujo estas lanĉita en Docker, ĝi ricevos ĉiujn samajn kapablojn kiel eligo, tio estas, ĝi povos liveri protokolojn kaj mezurojn, ĉar la agentoj estos lanĉitaj interne. 

Metriko kaj ŝtipoj

Liveri metrikojn kaj protokolojn estas kompleksa tasko. Estas pluraj aspektoj al ŝia decido.
La infrastrukturo estas kreita por la ekzekuto de la utila ŝarĝo, kaj ne por amasa livero de ŝtipoj. Tio estas, ĉi tiu procezo devas esti farita kun minimumaj ujresursaj postuloj. Ni strebas helpi niajn programistojn: "Akiru ujon Docker Hub, rulu ĝin, kaj ni povas liveri la protokolojn." 

La dua aspekto estas limigi la volumon de ŝtipoj. Se pliiĝo en la volumo de ŝtipoj okazas en pluraj ujoj (la aplikaĵo eligas stakspuron en buklo), la ŝarĝo sur la CPU, komunikaj kanaloj kaj ŝtip-pretigsistemo pliiĝas, kaj tio influas la funkciadon de la gastiganto kiel tutaj kaj aliaj ujoj sur la gastiganto, tiam foje tio kondukas al "falo" de la gastiganto. 

La tria aspekto estas, ke necesas subteni kiel eble plej multajn metrikajn kolektajn metodojn el la skatolo. De legado de dosieroj kaj sondado de Prometheus-endpoint ĝis uzado de specifaj protokoloj de aplikaĵo.

Kaj la lasta aspekto estas minimumigi la konsumon de rimedoj.

Ni elektis malfermfontan Go-solvon nomatan Telegraf. Ĉi tio estas universala konektilo, kiu subtenas pli ol 140 specojn de enigkanaloj (enigokromaĵoj) kaj 30 specoj de eligokanaloj (eligaj kromaĵoj). Ni finpretigis ĝin kaj nun ni rakontos al vi kiel ni uzas ĝin uzante Kubernetes kiel ekzemplon. 

Ni diru, ke programisto deplojas laborkvanton kaj Kubernetes ricevas peton por krei pod. Je ĉi tiu punkto, ujo nomita Kolektanto estas aŭtomate kreita por ĉiu pod (ni uzas mutacian rethokon). Kolektanto estas nia agento. Komence, ĉi tiu ujo agordas sin por labori kun Prometheus kaj la ŝtipkolekta sistemo.

• Por fari tion, ĝi uzas podkotadojn, kaj depende de sia enhavo, kreas, ekzemple, Prometheus-finpunkton; 
• Surbaze de la podspecifo kaj specifaj uj-agordoj, ĝi decidas kiel liveri ŝtipojn.

Ni kolektas protokolojn per la Docker API: programistoj nur bezonas meti ilin en stdout aŭ stderr, kaj Kolektanto ordigos ĝin. Registroj estas kolektitaj en pecoj kun iom da prokrasto por malhelpi eblan gastigan troŝarĝon. 

Metrikoj estas kolektitaj tra laborkvantoj (procezoj) en ujoj. Ĉio estas etikedita: nomspaco, sub, kaj tiel plu, kaj poste konvertita al Prometheus-formato - kaj fariĝas havebla por kolekto (krom protokoloj). Ni ankaŭ sendas protokolojn, metrikojn kaj eventojn al Kafka kaj plu:

• Registroj haveblas en Graylog (por vida analizo);
• Registroj, metrikoj, eventoj estas senditaj al Clickhouse por longdaŭra konservado.

Ĉio funkcias ekzakte same en AWS, nur ni anstataŭigas Graylog per Kafka kun Cloudwatch. Ni sendas la ŝtipojn tien, kaj ĉio montriĝas tre oportuna: tuj estas klare al kiu areto kaj ujo ili apartenas. La sama validas por Google Stackdriver. Tio estas, nia skemo funkcias kaj surloke kun Kafka kaj en la nubo. 

Se ni ne havas Kubernetes kun podoj, la skemo estas iom pli komplika, sed ĝi funkcias laŭ la samaj principoj.

La samaj procezoj estas ekzekutitaj ene de la ujo, ili estas reĝisoritaj per S6. Ĉiuj samaj procezoj funkcias en la sama ujo.

En la fino

Ni kreis kompletan solvon por konstrui kaj lanĉi bildojn, kun ebloj por kolekti kaj liveri protokolojn kaj metrikojn:

• Ni evoluigis normigitan aliron por kunmeti bildojn, kaj surbaze de ĝi ni evoluigis CI-ŝablonojn;
• Datumkolektaj agentoj estas niaj Telegraf-etendaĵoj. Ni bone testis ilin en produktado;
• Ni uzas mutacian rethokon por efektivigi ujojn kun agentoj en podoj; 
• Integrita en la ekosistemon Kubernetes/Rancher;
• Ni povas ekzekuti la samajn ujojn en malsamaj orkestradsistemoj kaj akiri la rezulton, kiun ni atendas;
• Kreis tute dinamikan kontenan administradon agordon. 

Kunaŭtoro: Ilja Prudnikov

fonto: www.habr.com