Is monitering dood? — Lank lewe monitering

Sedert 2008 is ons maatskappy hoofsaaklik besig met infrastruktuurbestuur en deurentyd tegniese ondersteuning vir webprojekte: ons het meer as 400 kliënte, wat ongeveer 15% van Russiese e-handel is. Gevolglik word 'n baie diverse argitektuur ondersteun. As iets val, is ons verplig om dit binne 15 minute reg te maak. Maar om te verstaan ​​dat 'n ongeluk plaasgevind het, moet jy die projek monitor en op voorvalle reageer. Hoe om dit te doen?

Ek glo dat daar 'n probleem is om 'n behoorlike moniteringstelsel te organiseer. As daar geen probleme was nie, sou my toespraak uit een tesis bestaan: "Installeer asseblief Prometheus + Grafana en plugins 1, 2, 3." Ongelukkig werk dit nie meer so nie. En die grootste probleem is dat almal aanhou glo in iets wat in 2008 bestaan ​​het, in terme van sagteware-komponente.

Wat die organisasie van die moniteringstelsel betref, wil ek dit waag om te sê dat... projekte met bekwame monitering nie bestaan ​​nie. En die situasie is so erg dat as iets val, daar 'n risiko is dat dit ongemerk sal bly - almal is immers seker dat "alles gemonitor word."
Miskien word alles gemonitor. Maar hoe?

Ons het almal 'n storie soos die volgende teëgekom: 'n sekere devops, 'n sekere admin werk, 'n ontwikkelingspan kom na hulle en sê - "ons is vrygelaat, monitor nou." Monitor wat? Hoe dit werk?

OK. Ons monitor die outydse manier. En dit is reeds besig om te verander, en dit blyk dat jy diens A gemonitor het, wat diens B geword het, wat interaksie het met diens C. Maar die ontwikkelingspan sê vir jou: "Installeer die sagteware, dit moet alles monitor!"

So wat het verander? - Alles het verander!

2008 Alles is reg

Daar is 'n paar ontwikkelaars, een bediener, een databasisbediener. Dit gaan alles van hier af. Ons het 'n bietjie inligting, ons installeer zabbix, Nagios, kaktusse. En dan stel ons duidelike waarskuwings op die SVE, oor skyfwerking en op skyfspasie. Ons doen ook 'n paar handkontroles om te verseker dat die webwerf reageer en dat bestellings in die databasis aankom. En dit is dit - ons is min of meer beskerm.

As ons die hoeveelheid werk vergelyk wat die administrateur toe gedoen het om monitering te verskaf, dan was 98% daarvan outomaties: die persoon wat die monitering doen, moet verstaan ​​hoe om Zabbix te installeer, hoe om dit op te stel en waarskuwings op te stel. En 2% - vir eksterne tjeks: dat die webwerf reageer en 'n versoek aan die databasis rig, dat nuwe bestellings aangekom het.

2010 Die las groei

Ons begin die web skaal deur 'n soekenjin by te voeg. Ons wil seker maak dat die produkkatalogus al die produkte bevat. En daardie produksoektog werk. Dat die databasis werk, dat bestellings gemaak word, dat die werf ekstern reageer en vanaf twee bedieners reageer en die gebruiker nie uit die werf geskop word terwyl dit na 'n ander bediener herbalanseer word nie, ens. Daar is meer entiteite.

Boonop bly die entiteit wat met infrastruktuur geassosieer word steeds die grootste in die bestuurder se kop. Daar is steeds 'n idee in my kop dat die persoon wat die monitering doen, die persoon is wat zabbix sal installeer en dit kan instel.

Maar terselfdertyd verskyn daar werk aan die uitvoer van eksterne kontroles, aan die skep van 'n stel soek-indekseerder-navraagskrifte, 'n stel skrifte om seker te maak dat die soektog verander tydens die indekseringsproses, 'n stel skrifte wat kontroleer dat goedere na die afleweringsdiens, ens. en so aan.

Let wel: Ek het 3 keer "'n stel skrifte" geskryf. Dit wil sê, die persoon wat verantwoordelik is vir monitering is nie meer die een wat bloot zabbix installeer nie. Dit is 'n persoon wat begin kodeer. Maar niks het nog in die span se gedagtes verander nie.

Maar die wêreld verander, word al hoe meer kompleks. 'n Virtualiseringslaag en verskeie nuwe stelsels word bygevoeg. Hulle begin interaksie met mekaar hê. Wie het gesê "ruik soos mikrodienste?" Maar elke diens lyk steeds individueel soos 'n webwerf. Ons kan ons daarheen wend en verstaan ​​dat dit die nodige inligting verskaf en op sy eie werk. En as jy 'n administrateur is wat voortdurend betrokke is by 'n projek wat al 5-7-10 jaar ontwikkel, versamel hierdie kennis: 'n nuwe vlak verskyn - jy het dit besef, 'n ander vlak verskyn - jy het dit besef ...

Maar selde vergesel iemand 'n projek vir 10 jaar.

Monitoringman se CV

Gestel jy het by 'n nuwe onderneming gekom wat onmiddellik 20 ontwikkelaars aangestel het, 15 mikrodienste geskryf het, en jy is 'n administrateur wat gesê word: "Bou CI/CD. Asseblief." Jy het CI/CD gebou en skielik hoor jy: “Dis moeilik vir ons om met produksie in ’n “kubus” te werk, sonder om te verstaan ​​hoe die toepassing daarin gaan werk. Maak vir ons 'n sandbox in dieselfde "kubus".
Jy maak 'n sandbox in hierdie kubus. Hulle sê dadelik vir jou: "Ons wil 'n verhoogdatabasis hê wat elke dag vanaf produksie opgedateer word, sodat ons verstaan ​​dat dit op die databasis werk, maar terselfdertyd nie die produksiedatabasis bederf nie."

Jy leef in dit alles. Daar is 2 weke oor voor die vrystelling, hulle sê vir jou: "Nou kom ons monitor dit alles ..." Dit wil sê. monitor die groepsinfrastruktuur, monitor die mikrodiensargitektuur, monitor werk met eksterne dienste ...

En my kollegas haal die gewone skema uit hul koppe en sê: “Wel, alles is duidelik hier! Installeer 'n program wat dit alles sal monitor." Ja, ja: Prometheus + Grafana + plugins.
En hulle voeg by: "Jy het twee weke, maak seker alles is veilig."

In baie projekte wat ons sien, word een persoon vir monitering toegewys. Stel jou voor dat ons 'n persoon wil aanstel om vir 2 weke monitering te doen, en ons skryf 'n CV vir hom. Watter vaardighede moet hierdie persoon hê, gegewe alles wat ons tot dusver gesê het?

• Hy moet die monitering en besonderhede van die werking van die ysterinfrastruktuur verstaan.
• Hy moet die besonderhede van die monitering van Kubernetes verstaan ​​(en almal wil na die "kubus" gaan, want jy kan uit alles abstraheer, wegsteek, want die admin sal die res hanteer) - homself, sy infrastruktuur, en verstaan ​​hoe om toepassings te monitor binne.
• Hy moet verstaan ​​dat dienste op spesiale maniere met mekaar kommunikeer, en die besonderhede ken van hoe dienste met mekaar omgaan. Dit is heel moontlik om 'n projek te sien waar sommige dienste sinchroon kommunikeer, want daar is geen ander manier nie. Byvoorbeeld, die backend gaan via REST, via gRPC na die katalogusdiens, ontvang 'n lys van produkte en stuur dit terug. Jy kan nie wag hier nie. En met ander dienste werk dit asynchronies. Dra die bestelling oor na die afleweringsdiens, stuur 'n brief, ens.
  Het jy seker al van dit alles geswem? En die admin, wat dit moet monitor, het nog meer deurmekaar geraak.
• Hy moet reg kan beplan en beplan – soos die werk meer en meer word.
• Hy moet dus 'n strategie uit die geskepte diens skep om te verstaan ​​hoe om dit spesifiek te monitor. Hy benodig 'n begrip van die projek se argitektuur en die ontwikkeling daarvan + 'n begrip van die tegnologieë wat in ontwikkeling gebruik word.

Kom ons onthou 'n absoluut normale geval: sommige dienste is in PHP, sommige dienste is in Go, sommige dienste is in JS. Hulle werk op een of ander manier met mekaar. Dit is waar die term "mikrodiens" vandaan kom: daar is soveel individuele stelsels dat ontwikkelaars nie die projek as geheel kan verstaan ​​nie. Een deel van die span skryf dienste in JS wat op hul eie werk en nie weet hoe die res van die stelsel werk nie. Die ander deel skryf dienste in Python en meng nie in met hoe ander dienste werk nie; hulle is geïsoleer in hul eie area. Die derde een is skryfdienste in PHP of iets anders.
Al hierdie 20 mense is in 15 dienste verdeel, en daar is net een admin wat dit alles moet verstaan. Stop! ons het net die stelsel in 15 mikrodienste verdeel omdat 20 mense nie die hele stelsel kan verstaan ​​nie.

Maar dit moet op een of ander manier gemonitor word ...

Wat is die resultaat? Gevolglik is daar een persoon wat met alles vorendag kom wat die hele span ontwikkelaars nie kan verstaan ​​nie, en terselfdertyd moet hy ook weet en kan doen wat ons hierbo aangedui het – hardeware-infrastruktuur, Kubernetes-infrastruktuur, ens.

Wat kan ek sê... Houston, ons het probleme.

Monitering van 'n moderne sagtewareprojek is 'n sagtewareprojek op sigself

Vanuit die valse oortuiging dat monitering sagteware is, ontwikkel ons 'n geloof in wonderwerke. Maar wonderwerke, helaas, gebeur nie. Jy kan nie zabbix installeer en verwag dat alles sal werk nie. Dit is geen sin om Grafana te installeer en te hoop dat alles in orde sal wees nie. Die meeste van die tyd sal bestee word aan die organisering van kontroles van die werking van dienste en hul interaksie met mekaar, om te kyk hoe eksterne stelsels werk. Trouens, 90% van die tyd sal nie aan die skryf van skrifte bestee word nie, maar aan die ontwikkeling van sagteware. En dit moet hanteer word deur 'n span wat die werk van die projek verstaan.
As in hierdie situasie een persoon in monitering gegooi word, sal 'n ramp gebeur. Wat is wat oral gebeur.

Daar is byvoorbeeld verskeie dienste wat via Kafka met mekaar kommunikeer. Die bestelling het aangekom, ons het 'n boodskap oor die bestelling aan Kafka gestuur. Daar is 'n diens wat na inligting oor die bestelling luister en die goedere versend. Daar is 'n diens wat na inligting oor die bestelling luister en 'n brief aan die gebruiker stuur. En dan verskyn nog 'n klomp dienste, en ons begin deurmekaar raak.

En as jy dit ook vir die admin en ontwikkelaars gee op die stadium wanneer daar 'n kort tydjie oor is voor die vrystelling, sal die persoon hierdie hele protokol moet verstaan. Dié. 'n Projek van hierdie skaal neem 'n aansienlike hoeveelheid tyd, en dit moet in die stelselontwikkeling in ag geneem word.
Maar baie dikwels, veral by beginondernemings, sien ons hoe monitering tot later uitgestel word. “Nou sal ons 'n Proof of Concept maak, ons sal daarmee begin, laat dit val - ons is gereed om op te offer. En dan sal ons dit alles monitor.” Wanneer (of as) die projek begin geld maak, wil die besigheid nog meer funksies byvoeg – want dit het begin werk, dus moet dit verder uitgerol word! En jy is op die punt waar jy eers alles wat vorige moet monitor, wat nie 1% van die tyd neem nie, maar baie meer. En terloops, ontwikkelaars sal nodig wees vir monitering, en dit is makliker om hulle aan nuwe funksies te laat werk. Gevolglik word nuwe kenmerke geskryf, alles word deurmekaar en jy is in 'n eindelose dooiepunt.

So hoe om 'n projek te monitor wat van die begin af begin, en wat om te doen as jy 'n projek kry wat gemonitor moet word, maar jy weet nie waar om te begin nie?

Eerstens moet jy beplan.

Liriese afwyking: hulle begin baie dikwels met infrastruktuurmonitering. Ons het byvoorbeeld Kubernetes. Kom ons begin deur Prometheus met Grafana te installeer, plugins te installeer om die "kubus" te monitor. Nie net ontwikkelaars nie, maar ook administrateurs het die ongelukkige praktyk van: "Ons sal hierdie inprop installeer, maar die inprop weet waarskynlik hoe om dit te doen." Mense begin graag met die eenvoudige en reguit, eerder as met die belangrike aksies. En infrastruktuurmonitering is maklik.

Besluit eers wat en hoe jy wil monitor, en kies dan 'n instrument, want ander mense kan nie vir jou dink nie. En moet hulle? Ander mense het by hulself gedink aan 'n universele stelsel - of glad nie gedink toe hierdie inprop geskryf is nie. En net omdat hierdie inprop 5 duisend gebruikers het, beteken dit nie dat dit van enige nut is nie. Miskien sal jy die 5001ste word bloot omdat daar voorheen reeds 5000 mense daar was.

As jy die infrastruktuur begin monitor en die agterkant van jou toepassing ophou reageer, sal alle gebruikers verbinding met die mobiele toepassing verloor. 'n Fout sal verskyn. Hulle sal na jou toe kom en sê: "Die toepassing werk nie, wat doen jy hier?" - "Ons monitor." — “Hoe monitor jy as jy nie sien dat die toepassing nie werk nie?!”

1. Ek glo dat u presies vanaf die gebruiker se toegangspunt moet begin monitor. As die gebruiker nie sien dat die toepassing werk nie, is dit dit, dit is 'n mislukking. En die moniteringstelsel moet eers hieroor waarsku.
2. En eers dan kan ons die infrastruktuur monitor. Of doen dit parallel. Dit is makliker met infrastruktuur - hier kan ons uiteindelik net zabbix installeer.
3. En nou moet jy na die wortels van die toepassing gaan om te verstaan ​​waar dinge nie werk nie.

My hoofgedagte is dat monitering parallel met die ontwikkelingsproses moet verloop. As jy die moniteringspan se aandag aflei vir ander take (skep van CI/CD, sandboxing, infrastruktuurherorganisasie), sal monitering begin sloer en jy sal dalk nooit ontwikkeling inhaal nie (of vroeër of later sal jy dit moet stop).

Alles volgens vlakke

Dit is hoe ek die organisasie van 'n moniteringstelsel sien.

1) Toepassingsvlak:

• monitering van toepassing besigheidslogika;
• monitering van gesondheidsmetrieke van dienste;
• integrasie monitering.

2) Infrastruktuurvlak:

• monitering van orkestrasievlak;
• stelsel sagteware monitering;
• ystervlak monitering.

3) Weereens die toepassingsvlak - maar as 'n ingenieursproduk:

• die versameling en monitering van toepassingslogboeke;
• APM;
• opspoor.

4) Waarskuwing:

• organisasie van 'n waarskuwingstelsel;
• organisasie van 'n diensstelsel;
• organisasie van 'n "kennisbasis" en werkvloei vir insidentverwerking.

Dit is belangrik om: ons kom by die waarskuwing nie na nie, maar dadelik! Dit is nie nodig om monitering te begin en "op een of ander manier later" uit te vind wie waarskuwings sal ontvang nie. Wat is immers die taak van monitering: om te verstaan ​​waar in die stelsel iets verkeerd werk, en om die regte mense daarvan te laat weet. As jy dit tot die einde laat, dan sal die regte mense weet dat iets verkeerd gaan net deur te noem "niks werk vir ons nie."

Toepassingslaag - Besigheidslogika-monitering

Hier praat ons oor die feit dat die toepassing vir die gebruiker werk.

Hierdie vlak moet tydens die ontwikkelingsfase gedoen word. Byvoorbeeld, ons het 'n voorwaardelike Prometheus: dit gaan na die bediener wat die kontroles doen, die eindpunt trek, en die eindpunt gaan die API na.

Wanneer hulle gereeld gevra word om die tuisblad te monitor om seker te maak dat die webwerf werk, gee programmeerders 'n handvatsel wat elke keer getrek kan word as hulle moet seker maak dat die API werk. En programmeerders op hierdie oomblik neem en skryf steeds /api/test/helloworld
Die enigste manier om seker te maak alles werk? - Geen!

• Die skep van sulke tjeks is in wese die taak van ontwikkelaars. Eenheidtoetse moet geskryf word deur die programmeerders wat die kode skryf. Want as jy dit aan die admin uitlek, "Man, hier is 'n lys van API-protokolle vir al 25 funksies, monitor asseblief alles!" - niks sal uitwerk nie.
• As jy "hallo wêreld" druk, sal niemand ooit weet dat die API moet en werk nie. Elke API-verandering moet lei tot 'n verandering in tjeks.
• As jy reeds so 'n probleem het, stop die kenmerke en ken ontwikkelaars toe wat hierdie tjeks sal skryf, of die verliese aanvaar, aanvaar dat niks gekontroleer is nie en sal misluk.

Tegniese wenke:

• Maak seker dat jy 'n eksterne bediener organiseer om tjeks te organiseer - jy moet seker wees dat jou projek toeganklik is vir die buitewêreld.
• Organiseer tjeks oor die hele API-protokol, nie net individuele eindpunte nie.
• Skep 'n prometheus-eindpunt met die toetsresultate.

Toepassingslaag - monitering van gesondheidsstatistieke

Nou praat ons van eksterne gesondheidsstatistieke van dienste.

Ons het besluit dat ons al die "handvatsels" van die toepassing monitor deur eksterne kontrole te gebruik, wat ons vanaf 'n eksterne moniteringstelsel oproep. Maar dit is die "handvatsels" wat die gebruiker "sien". Ons wil seker wees dat ons dienste self werk. Daar is 'n beter storie hier: K8s het gesondheidsondersoeke, sodat ten minste die "kubus" self oortuig kan word dat die diens werk. Maar die helfte van die tjeks wat ek gesien het, is dieselfde gedrukte “hallo wêreld”. Dié. So hy trek een keer na ontplooiing, hy het geantwoord dat alles reg is - dis al. En die diens, as dit sy eie API verskaf, het 'n groot aantal toegangspunte vir daardie selfde API, wat ook gemonitor moet word, want ons wil weet dat dit werk. En ons monitor dit reeds binne.

Hoe om dit tegnies korrek te implementeer: elke diens stel 'n eindpunt bloot oor sy huidige prestasie, en in die grafieke van Grafana (of enige ander toepassing) sien ons die status van alle dienste.

• Elke API-verandering moet lei tot 'n verandering in tjeks.
• Skep dadelik 'n nuwe diens met gesondheidsstatistieke.
• 'n Admin kan na die ontwikkelaars kom en vra "voeg vir my 'n paar kenmerke by sodat ek alles verstaan ​​en inligting hieroor by my moniteringstelsel voeg." Maar ontwikkelaars antwoord gewoonlik: "Ons sal niks twee weke voor die vrystelling byvoeg nie."
  Laat weet die ontwikkelingsbestuurders dat daar sulke verliese gaan wees, laat die bestuur van die ontwikkelingsbestuurders ook weet. Want wanneer alles val, sal iemand steeds bel en eis om die “voortdurend dalende diens” te monitor (c)
• Terloops, ken ontwikkelaars toe om plugins vir Grafana te skryf - dit sal 'n goeie hulp wees vir admins.

Toepassingslaag - Integrasiemonitering

Integrasiemonitering fokus op die monitering van kommunikasie tussen besigheidskritiese stelsels.

Daar is byvoorbeeld 15 dienste wat met mekaar kommunikeer. Dit is nie meer aparte werwe nie. Dié. ons kan nie die diens op sy eie trek nie, kry /helloworld en verstaan ​​dat die diens aan die gang is. Omdat die bestelwebdiens inligting oor die bestelling na die bus moet stuur – vanaf die bus, moet die pakhuisdiens hierdie boodskap ontvang en verder daarmee werk. En die e-posverspreidingsdiens moet dit op een of ander manier verder verwerk, ens.

Gevolglik kan ons nie verstaan, terwyl ons na elke individuele diens kyk, dat dit alles werk nie. Want ons het 'n sekere bus waardeur alles kommunikeer en interaksie het.
Daarom moet hierdie stadium die stadium van toetsdienste vir interaksie met ander dienste aandui. Dit is onmoontlik om kommunikasiemonitering te organiseer deur die boodskapmakelaar te monitor. As daar 'n diens is wat data uitreik en 'n diens wat dit ontvang, wanneer ons die makelaar monitor, sal ons net data sien wat van kant tot kant vlieg. Selfs as ons op een of ander manier daarin geslaag het om die interaksie van hierdie data intern te monitor - dat 'n sekere produsent die data plaas, iemand dit lees, hierdie vloei gaan voort om na Kafka te gaan - sal dit steeds nie vir ons inligting gee as een diens die boodskap in een weergawe gestuur het nie , maar die ander diens het nie hierdie weergawe verwag nie en het dit oorgeslaan. Ons sal nie hiervan weet nie, aangesien die dienste ons sal vertel dat alles werk.

Wat ek aanbeveel om te doen:

• Vir sinchroniese kommunikasie: die eindpunt rig versoeke aan verwante dienste. Dié. ons neem hierdie eindpunt, trek 'n skrif binne die diens, wat na al die punte gaan en sê "Ek kan daarheen trek, en trek daarheen, ek kan daarheen trek ..."
• Vir asinchroniese kommunikasie: inkomende boodskappe - die eindpunt kontroleer die bus vir toetsboodskappe en vertoon die verwerkingstatus.
• Vir asinchroniese kommunikasie: uitgaande boodskappe - die eindpunt stuur toetsboodskappe na die bus.

Soos gewoonlik gebeur: ons het 'n diens wat data in die bus gooi. Ons kom na hierdie diens en vra u om ons te vertel van die integrasiegesondheid daarvan. En as die diens 'n boodskap iewers verder moet produseer (WebApp), dan sal dit hierdie toetsboodskap produseer. En as ons 'n diens aan die OrderProcessing-kant bedryf, plaas dit eers wat dit onafhanklik kan plaas, en as daar 'n paar afhanklike dinge is, dan lees dit 'n stel toetsboodskappe van die bus af, verstaan ​​dat dit dit kan verwerk, dit kan rapporteer en , indien nodig, plaas hulle verder, en hieroor sê hy - alles is ok, ek lewe.

Baie dikwels hoor ons die vraag "hoe kan ons dit op gevegsdata toets?" Ons praat byvoorbeeld van dieselfde besteldiens. Die bestelling stuur boodskappe na die pakhuis waar die goedere afgeskryf word: ons kan dit nie op gevegsdata toets nie, want "my goedere sal afgeskryf word!" Oplossing: Beplan hierdie hele toets aan die begin. Jy het ook eenheidstoetse wat bespotting maak. So, doen dit op 'n dieper vlak waar jy 'n kommunikasiekanaal het wat nie die bedryf van die besigheid benadeel nie.

Infrastruktuur vlak

Infrastruktuurmonitering is iets wat lank reeds beskou word as om self te monitor.

• Infrastruktuurmonitering kan en moet as 'n aparte proses van stapel gestuur word.
• U moet nie begin met infrastruktuurmonitering op 'n lopende projek nie, selfs al wil u regtig. Dit is 'n pyn vir alle devops. "Ek sal eers die groep monitor, ek sal die infrastruktuur monitor" - d.w.s. Eerstens sal dit monitor wat hieronder lê, maar sal nie in die aansoek ingaan nie. Want die toepassing is 'n onverstaanbare ding vir devops. Dit is aan hom uitgelek, en hy verstaan ​​nie hoe dit werk nie. En hy verstaan ​​die infrastruktuur en begin daarmee. Maar nee - jy moet altyd eers die toepassing monitor.
• Moenie oorboord gaan met die aantal waarskuwings nie. Met inagneming van die kompleksiteit van moderne stelsels, vlieg waarskuwings voortdurend, en jy moet op een of ander manier met hierdie klomp waarskuwings saamleef. En die aanroepende persoon, nadat hy na honderd van die volgende waarskuwings gekyk het, sal besluit "Ek wil nie daaraan dink nie." Waarskuwings moet slegs oor kritieke dinge in kennis stel.

Toepassingsvlak as 'n besigheidseenheid

Kern punte:

• ELK. Dit is die industrie standaard. As jy om een ​​of ander rede nie logs bymekaarmaak nie, begin dit dadelik doen.
• APM. Eksterne APM's as 'n manier om toepassingmonitering vinnig te sluit (NewRelic, BlackFire, Datadog). Jy kan hierdie ding tydelik installeer om ten minste op een of ander manier te verstaan ​​wat met jou aangaan.
• Opsporing. In tientalle mikrodienste moet jy alles opspoor, want die versoek leef nie meer op sy eie nie. Dit is baie moeilik om later by te voeg, daarom is dit beter om onmiddellik opsporing in ontwikkeling te skeduleer - dit is die werk en nut van die ontwikkelaars. As jy dit nog nie geïmplementeer het nie, implementeer dit! Sien Jaeger/Zipkin

Waarskuwing

• Organisasie van 'n kennisgewingstelsel: in toestande om 'n klomp dinge te monitor, moet daar 'n verenigde stelsel wees om kennisgewings te stuur. Jy kan in Grafana. In die Weste gebruik almal PagerDuty. Waarskuwings moet duidelik wees (bv. waar hulle vandaan kom...). En dit is raadsaam om te beheer dat kennisgewings hoegenaamd ontvang word
• Organisering van 'n diensstelsel: waarskuwings moet nie aan almal gestuur word nie (óf almal sal in 'n skare reageer, óf niemand sal reageer nie). Ontwikkelaars moet ook beskikbaar wees: maak seker dat jy areas van verantwoordelikheid definieer, maak duidelike instruksies en skryf daarin wie presies om op Maandag en Woensdag te bel, en wie om op Dinsdag en Vrydag te bel (anders sal hulle niemand bel nie, selfs in die gebeurtenis van 'n groot probleem - hulle sal bang wees om jou wakker te maak of te steur: mense hou gewoonlik nie daarvan om ander mense te bel en wakker te maak nie, veral in die nag). En verduidelik dat om hulp te vra nie 'n aanduiding van onbevoegdheid is nie ("Ek vra vir hulp, dit beteken ek is 'n slegte werker"), moedig versoeke om hulp aan.
• Organisering van 'n "kennisbasis" en werkvloei vir insidentverwerking: vir elke ernstige voorval moet 'n nadoodse ondersoek beplan word, en as 'n tydelike maatreël moet aksies wat die voorval sal oplos, aangeteken word. En maak dit 'n praktyk dat herhaalde waarskuwings 'n sonde is; hulle moet in kode- of infrastruktuurwerk reggemaak word.

Tegnologie stapel

Kom ons stel ons voor dat ons stapel soos volg is:

• data-insameling - Prometheus + Grafana;
• log analise - ELK;
• vir APM of Tracing - Jaeger (Zipkin).

Die keuse van opsies is nie krities nie. Want as jy aan die begin verstaan ​​het hoe om die stelsel te monitor en 'n plan neergeskryf het, dan begin jy gereedskap kies om by jou vereistes te pas. Die vraag is wat jy in die eerste plek gekies het om te monitor. Want miskien pas die instrument wat jy aan die begin gekies het glad nie by jou vereistes nie.

'n Paar tegniese punte wat ek die afgelope tyd oral sien:

Prometheus word Kubernetes binne gedruk – wie het hiermee vorendag gekom?! As jou groep ineenstort, wat sal jy doen? As u 'n komplekse groep binne het, moet daar 'n soort moniteringstelsel binne die groep wees, en 'n paar buite, wat data van binne die groep sal insamel.

Binne die groep versamel ons houtblokke en alles anders. Maar die moniteringstelsel moet buite wees. Baie dikwels, in 'n groep waar Promtheus intern geïnstalleer is, is daar ook stelsels wat eksterne kontrole van die werf se werking uitvoer. Wat as jou verbindings met die buitewêreld gedaal het en die toepassing nie werk nie? Dit blyk dat alles binne goed is, maar dit maak dinge nie makliker vir gebruikers nie.

Bevindinge

• Monitering van ontwikkeling is nie die installering van nutsprogramme nie, maar die ontwikkeling van 'n sagtewareproduk. 98% van vandag se monitering is kodering. Kodering in dienste, kodering van eksterne tjeks, kontrolering van eksterne dienste, en dit is al.
• Moenie jou ontwikkelaars se tyd mors op monitering nie: dit kan tot 30% van hul werk neem, maar dit is die moeite werd.
• Devops, moenie bekommerd wees dat jy iets nie kan monitor nie, want sommige dinge is 'n heeltemal ander manier van dink. Jy was nie 'n programmeerder nie, en monitering werk is presies hul taak.
• As die projek reeds aan die gang is en nie gemonitor word nie (en jy is 'n bestuurder), ken hulpbronne toe vir monitering.
• As die produk reeds in produksie is, en jy is 'n devops wat aangesê is om "monitering op te stel" - probeer om aan die bestuur te verduidelik waaroor ek dit alles geskryf het.

Dit is 'n uitgebreide weergawe van die verslag by die Saint Highload++-konferensie.

As jy belangstel in my idees en gedagtes daaroor en verwante onderwerpe, dan kan jy hier lees die kanaal 🙂

Bron: will.com