Dit ferhaal giet oer hoe't wy konteners brûke yn in produksjeomjouwing, spesifyk Kubernetes. It artikel is wijd oan it sammeljen fan metriken en logs út konteners, lykas it bouwen fan ôfbyldings.

Wy binne fan it fintechbedriuw Exness, dat tsjinsten ûntwikkelet foar online hannel en fintechprodukten foar B2B en B2C. Us R & D hat in protte ferskillende teams, de ûntwikkeling ôfdieling hat 100+ meiwurkers.

Wy fertsjintwurdigje it team dat ferantwurdlik is foar it platfoarm foar ús ûntwikkelders om koade te sammeljen en út te fieren. Yn it bysûnder binne wy ​​ferantwurdlik foar it sammeljen, opslaan en rapportearjen fan metriken, logs en eveneminten fan applikaasjes. Wy operearje op it stuit sawat trijetûzen Docker-konteners yn in produksjeomjouwing, ûnderhâlde ús 50 TB grutte data-opslach, en leverje arsjitektoanyske oplossingen dy't binne boud om ús ynfrastruktuer: Kubernetes, Rancher, en ferskate iepenbiere wolkproviders. 

Us motivaasje

Wat baarnt? Nimmen kin antwurdzje. Wêr is de hert? It is dreech te begripen. Wannear foel it fjoer? Jo kinne útfine, mar net direkt. 

Wêrom steane guon konteners wylst oaren fallen binne? Hokker kontener wie de skuld? Ommers, de bûtenkant fan de konteners binne itselde, mar binnen elk hat syn eigen Neo.

Us ûntwikkelders binne kompetinte jonges. Se meitsje goede tsjinsten dy't winst bringe oan it bedriuw. Mar d'r binne mislearrings as konteners mei applikaasjes ferdwale. Ien kontener ferbrûkt te folle CPU, in oare ferbrûkt it netwurk, in tredde ferbrûkt I / O-operaasjes, en de fjirde is folslein ûndúdlik wat it docht mei sockets. It falt allegear en it skip sinkt. 

Aginten

Om te begripen wat der binnen bart, besletten wy aginten direkt yn konteners te pleatsen.

Dizze aginten binne beheiningsprogramma's dy't konteners yn sa'n steat hâlde dat se inoar net brekke. Aginten wurde standerdisearre, en dit soarget foar in standerdisearre oanpak foar it betsjinjen fan konteners. 

Yn ús gefal moatte aginten logs leverje yn in standertformaat, tagged en smoarch. Se moatte ús ek standertisearre metriken leverje dy't útwreidzje kinne fanút in perspektyf fan bedriuwsapplikaasje.

Aginten betsjutte ek nutsbedriuwen foar operaasje en ûnderhâld dy't wurkje kinne yn ferskate orkestraasjesystemen dy't ferskate ôfbyldings stypje (Debian, Alpine, Centos, ensfh.).

Uteinlik moatte aginten ienfâldige CI / CD stypje dy't Docker-bestannen omfettet. Oars sil it skip útinoar falle, om't konteners begjinne te leverjen lâns "krûmke" rails.

Bou proses en doelôfbyldingsapparaat

Om alles standerdisearre en beheare te hâlden, moat in soarte fan standertbouproses folge wurde. Dêrom hawwe wy besletten om konteners te sammeljen troch konteners - dit is rekursje.

Hjir binne de konteners fertsjintwurdige troch solide konturen. Tagelyk besleaten se distribúsjekits yn har te setten sadat "it libben net as frambozen liket." Wêrom dit dien is, sille wy hjirûnder útlizze.
 
It resultaat is in build-ark - in ferzje-spesifike kontener dy't ferwiist nei spesifike distribúsjeferzjes en spesifike skriptferzjes.

Hoe brûke wy it? Wy hawwe in Docker Hub dy't in kontener befettet. Wy spegelje it yn ús systeem om eksterne ôfhinklikens kwyt te reitsjen. It resultaat is in kontener markearre yn giel. Wy meitsje in sjabloan om alle distribúsjes en skripts te ynstallearjen dy't wy nedich binne yn 'e kontener. Dêrnei sammelje wy in klear te brûken ôfbylding: ûntwikkelders sette koade en guon fan har eigen spesjale ôfhinklikens yn. 

Wat is goed oan dizze oanpak? 

• Earst, folsleine ferzjekontrôle fan bouwark - bouwe kontener, skript en distribúsjeferzjes. 
• Twads, wy hawwe berikt standerdisearring: wy meitsje sjabloanen, tuskenlizzende en klear te brûken ôfbylding op deselde wize. 
• Tredde, konteners jouwe ús portabiliteit. Hjoed brûke wy Gitlab, en moarn sille wy oerstappe nei TeamCity of Jenkins en kinne wy ​​​​ús konteners op deselde manier útfiere. 
• Fjirde, minimalisearje ôfhinklikens. It wie gjin tafal dat wy distribúsjekits yn 'e kontener setten, om't wy dit kinne foarkomme om se elke kear fan it ynternet te downloaden. 
• Fyfde is de bousnelheid tanommen - de oanwêzigens fan lokale kopyen fan ôfbyldings kinne jo foarkomme dat jo tiid fergrieme by it downloaden, om't d'r in lokale ôfbylding is. 

Mei oare wurden, wy hawwe berikt in kontrolearre en fleksibele gearkomste proses. Wy brûke deselde ark om alle folslein ferzjekonteners te bouwen. 

Hoe't ús bouproseduere wurket

De gearkomste wurdt lansearre mei ien kommando, it proses wurdt útfierd yn 'e ôfbylding (markearre yn read). De ûntwikkelder hat in Docker-bestân (markearre yn giel), wy meitsje it, ferfange fariabelen mei wearden. En ûnderweis foegje wy kop- en fuotteksten ta - dit binne ús aginten. 

Header foeget distribúsjes ta fan 'e oerienkommende ôfbyldings. En foettekst ynstallearret ús tsjinsten binnen, konfigurearret de lansearring fan wurkdruk, logging en oare aginten, ferfangt yngongspunt, ensfh. 

We ha lang tochten oft we in tafersjochhâlder ynstallearje moasten. Op it lêst hawwe wy besletten dat wy him nedich hawwe. Wy hawwe keazen foar S6. De tafersjochhâlder soarget foar kontenerbehear: kinne jo dermei ferbine as it haadproses crasht en leveret hânmjittich behear fan 'e kontener sûnder it opnij oan te meitsjen. Logs en metriken binne prosessen dy't yn 'e kontener rinne. Se moatte ek op ien of oare manier kontrolearre wurde, en dat dogge wy mei help fan in tafersjochhâlder. Uteinlik soarget de S6 foar húshâlding, sinjaalferwurking en oare taken.

Om't wy ferskate orkestraasjesystemen brûke, moat de kontener nei it bouwen en rinnen begripe hokker omjouwing it is en hannelje neffens de situaasje. Bygelyks:
Hjirmei kinne wy ​​​​ien ôfbylding bouwe en it útfiere yn ferskate orkestraasjesystemen, en it sil lansearre wurde mei rekkening mei de spesifikaasjes fan dit orkestraasjesysteem.

 

Foar deselde kontener krije wy ferskate prosesbeammen yn Docker en Kubernetes:

De lading wurdt útfierd ûnder tafersjoch fan S6. Jou omtinken oan samler en eveneminten - dit binne ús aginten ferantwurdlik foar logs en metriken. Kubernetes hat se net, mar Docker wol. Wêrom? 

As wy sjogge nei de spesifikaasje fan de "pod" (hjirnei - Kubernetes pod), wy sille sjen dat de barren container wurdt útfierd yn in pod, dat hat in aparte samler container dy't fiert de funksje fan it sammeljen fan metriken en logs. Wy kinne de mooglikheden fan Kubernetes brûke: konteners útfiere yn ien pod, yn ien proses en/of netwurkromte. Yntrodusearje jo aginten wirklik en fier wat funksjes út. En as deselde kontener yn Docker lansearre wurdt, sil it alle deselde mooglikheden krije as útfier, dat is, it sil logs en metriken kinne leverje, om't de aginten yntern wurde lansearre. 

Metriken en logs

Metriken en logs leverje is in komplekse taak. D'r binne ferskate aspekten oan har beslút.
De ynfrastruktuer is makke foar de útfiering fan 'e lading, en net foar massale levering fan logs. Dat is, dit proses moat wurde útfierd mei minimale easken foar kontenerboarne. Wy stribje dernei om ús ûntwikkelders te helpen: "Krij in Docker Hub-container, rinne it, en wy kinne de logs leverje." 

It twadde aspekt is it beheinen fan it folume fan logs. As in tanimming yn it folume fan logs yn ferskate konteners plakfynt (de applikaasje jout in stack-trace út yn in lus), nimt de lading op 'e CPU, kommunikaasjekanalen en logferwurkingssysteem ta, en dit hat ynfloed op de wurking fan' e host as in hiele en oare konteners op de host, dan soms liedt dit ta "fal" fan de host. 

It tredde aspekt is dat it nedich is om safolle mooglik metriken sammelje metoaden út it fak te stypjen. Fan it lêzen fan bestannen en it pollen fan Prometheus-einpunt oant it brûken fan applikaasjespesifike protokollen.

En it lêste aspekt is it minimalisearjen fan boarneferbrûk.

Wy hawwe keazen foar in iepen boarne Go-oplossing neamd Telegraf. Dit is in universele ferbining dy't mear as 140 soarten ynfierkanalen (ynput-plugins) en 30 soarten útfierkanalen (útfier-plugins) stipet. Wy hawwe it finalisearre en no sille wy jo fertelle hoe't wy it brûke mei Kubernetes as foarbyld. 

Litte wy sizze dat in ûntwikkelder in wurkdruk ynset en Kubernetes ûntfangt in fersyk om in pod te meitsjen. Op dit punt wurdt automatysk in kontener neamd Collector makke foar elke pod (wy brûke mutaasjewebhook). Samler is ús agent. Oan it begjin konfigureart dizze kontener himsels om te wurkjen mei Prometheus en it logkolleksjesysteem.

• Om dit te dwaan, it brûkt pod annotaasjes, en ôfhinklik fan syn ynhâld, skept, sizze, in Prometheus einpunt; 
• Op grûn fan 'e podspesifikaasje en spesifike kontenerynstellingen beslút it hoe't logs wurde levere.

Wy sammelje logs fia de Docker API: ûntwikkelders moatte se gewoan yn stdout of stderr pleatse, en Collector sil it sortearje. Logs wurde sammele yn brokken mei wat fertraging om mooglike host-overload te foarkommen. 

Metriken wurde sammele oer workload-eksimplaren (prosessen) yn konteners. Alles is tagged: nammeromte, ûnder, ensafuorthinne, en dan omboud ta Prometheus-formaat - en wurdt beskikber foar kolleksje (útsein logs). Wy stjoere ek logs, metriken en eveneminten nei Kafka en fierder:

• Logs binne beskikber yn Graylog (foar fisuele analyze);
• Logs, metriken, eveneminten wurde stjoerd nei Clickhouse foar opslach op lange termyn.

Alles wurket krekt itselde yn AWS, allinich ferfange wy Graylog mei Kafka mei Cloudwatch. Wy stjoere de logs dêr, en alles blykt tige handich: it is fuortendaliks dúdlik hokker kluster en kontener se hearre. Itselde jildt foar Google Stackdriver. Dat is, ús skema wurket sawol on-premise mei Kafka as yn 'e wolk. 

As wy gjin Kubernetes hawwe mei pods, is it skema in bytsje komplisearre, mar it wurket op deselde prinsipes.

Deselde prosessen wurde útfierd binnen de kontener, se wurde orkestreare mei S6. Alle deselde prosessen rinne yn deselde kontener.

As gefolch,

Wy hawwe in folsleine oplossing makke foar it bouwen en lansearjen fan ôfbyldings, mei opsjes foar it sammeljen en leverjen fan logs en metriken:

• Wy ûntwikkele in standerdisearre oanpak foar it gearstallen fan ôfbyldings, en basearre op it wy ûntwikkele CI sjabloanen;
• Aginten foar gegevenssammeling binne ús Telegraf-útwreidingen. Wy testen se goed yn produksje;
• Wy brûke mutaasje webhook te ymplemintearjen konteners mei aginten yn pods; 
• Yntegreare yn it Kubernetes/Rancher-ekosysteem;
• Wy kinne deselde konteners yn ferskate orkestraasjesystemen útfiere en it resultaat krije dat wy ferwachtsje;
• In folslein dynamyske konfiguraasje foar kontenerbehear makke. 

Co-auteur: Ilya Prudnikov

Boarne: www.habr.com