Monitorizazioa hil al da? — Bizi luzeko jarraipena

2008az geroztik, gure konpainiak azpiegituren kudeaketan eta web proiektuetarako etengabeko laguntza teknikoan dihardu nagusiki: 400 bezero baino gehiago ditugu, hau da, Errusiako merkataritza elektronikoaren %15 inguru. Horren arabera, arkitektura oso anitza onartzen da. Zerbait erortzen bada, 15 minutuko epean konpontzera behartuta gaude. Baina istripu bat gertatu dela ulertzeko, proiektuaren jarraipena egin behar da eta gorabeherak erantzun. Nola egin hau?

Uste dut arazo bat dagoela jarraipen sistema egoki bat antolatzeko. Arazorik izan ez balitz, nire hitzaldia tesi batek osatuko luke: "Mesedez, instalatu Prometheus + Grafana eta pluginak 1, 2, 3". Zoritxarrez, jada ez da horrela funtzionatzen. Eta arazo nagusia da mundu guztiak sinisten jarraitzen duela 2008an zegoen zerbaitetan, software osagaiei dagokienez.

Jarraipen sistemaren antolakuntzari dagokionez, ausartuko nintzateke esatera... monitorizazio eskuduna duten proiekturik ez dagoela. Eta egoera hain da txarra, non zerbait erortzen bada, oharkabean pasatzeko arriskua dago; azken finean, denak ziur daude "dena kontrolatuta" dagoela.
Agian dena kontrolatzen ari da. Baina nola?

Denok topatu dugu honako hau bezalako istorio bat: debops jakin bat, administratzaile jakin bat lanean ari da, garapen talde bat etortzen zaie eta esaten die: "askatuta gaude, orain monitorizatu". Zer monitorizatu? Nola dabil?

ADOS. Era zaharraren jarraipena egiten dugu. Dagoeneko aldatzen ari da, eta ikusten da A zerbitzua kontrolatu zenuela, B zerbitzu bihurtu zena, C zerbitzuarekin elkarreragiten duena. Baina garapen-taldeak esaten dizu: "Instalatu softwarea, dena kontrolatu beharko luke!"

Beraz, zer aldatu da? - Dena aldatu da!

2008 Dena ondo dago

Garatzaile pare bat daude, zerbitzari bat, datu-base zerbitzari bat. Hemendik doa dena. Informazioa dugu, zabbix, Nagios, cacti instalatzen ditugu. Eta gero alerta argiak ezartzen ditugu CPUan, diskoaren funtzionamenduan eta diskoko espazioan. Eskuzko egiaztapen pare bat ere egiten ditugu guneak erantzuten duela eta eskaerak datu-basera iristen direla ziurtatzeko. Eta kitto: gutxi gora behera babestuta gaude.

Administratzaileak monitorizazioa emateko orduan egin zuen lan kopurua konparatzen badugu, orduan %98 automatikoa izan zen: monitorizazioa egiten duenak Zabbix nola instalatu, nola konfiguratu eta alertak konfiguratu ulertu behar du. Eta %2 - kanpoko egiaztapenetarako: guneak erantzuten duela eta datu-baseari eskaera bat egiten diola, eskaera berriak iritsi direla.

2010 Karga hazten ari da

Weba eskalatzen hasiak gara, bilatzaile bat gehituz. Produktuen katalogoak produktu guztiak dituela ziurtatu nahi dugu. Eta produktuen bilaketa horrek funtzionatzen du. Datu-basea funtzionatzen ari dela, eskaerak egiten ari direla, guneak kanpotik erantzuten duela eta bi zerbitzarietatik erantzuten duela eta erabiltzailea ez dela gunetik kanporatzen beste zerbitzari batera orekatzen den bitartean, etab. Entitate gehiago daude.

Gainera, azpiegiturekin lotutako entitatea oraindik handiena izaten jarraitzen du kudeatzailearen buruan. Oraindik ideia bat daukat buruan monitorizazioa egiten duena zabbix instalatuko duena eta konfiguratu ahal izango duena dela.

Baina, aldi berean, kanpoko egiaztapenak egiteko lana agertzen da, bilaketa-indexatzaileen kontsulta-script-multzo bat sortzeko, indexazio-prozesuan bilaketa aldatzen dela egiaztatzeko script-multzo bat, ondasunak transferitzen direla egiaztatzen duten script multzo bat. entrega zerbitzua, etab. eta abar.

Oharra: 3 aldiz idatzi nuen "gidoi multzo bat". Hau da, monitorizazioaz arduratzen dena ez da zabbix besterik instalatzen duena. Hau kodetzen hasten den pertsona da. Baina oraindik ez da ezer aldatu taldearen buruan.

Baina mundua aldatzen ari da, gero eta konplexuagoa. Birtualizazio geruza bat eta hainbat sistema berri gehitzen dira. Elkarrekin harremanetan hasten dira. Nork esan zuen "mikrozerbitzuen usaina duela?" Baina zerbitzu bakoitzak banaka webgune baten itxura du oraindik. Bertara jo dezakegu eta beharrezko informazioa ematen duela eta bere kabuz funtzionatzen duela uler dezakegu. Eta 5-7-10 urtez garatzen ari den proiektu batean etengabe sartuta dagoen administratzailea bazara, ezagutza hori pilatzen da: maila berri bat agertzen da - konturatu zara, beste maila bat agertzen da - konturatu zara...

Baina oso gutxitan joaten da inor 10 urtez proiektu batekin.

Monitoringman-en curriculuma

Demagun berehala 20 garatzaile kontratatu dituen startup berri batera iritsi zarela, 15 mikrozerbitzu idatzi eta administratzaile bat zarela esaten zaiona: “Eraiki CI/CD. Mesedez." CI/CD eraiki duzu eta bat-batean entzuten duzu: “Zaila zaigu ekoizpenarekin “kubo” batean lan egitea, aplikazioak bertan nola funtzionatuko duen ulertu gabe. Egin iezaguzu harea-kutxa bat “kubo” berean.
Kubo honetan harea-kutxa bat egiten duzu. Berehala esaten dizute: «Ekoizpenetik egunero eguneratzen den etapa-datu-base bat nahi dugu, datu-basean funtzionatzen duela uler dezagun, baina, aldi berean, ekoizpen-datu-basea ez hondatu».

Honetan guztian bizi zara. 2 aste falta dira kaleratzeko, esaten dizute: “Orain ikus dezagun guzti hau...” Hau da. kluster azpiegitura monitorizatzea, mikrozerbitzuen arkitektura kontrolatzea, kanpoko zerbitzuekin lana kontrolatzea...

Eta nire lankideek ohiko eskema burutik kentzen dute eta esaten dute: “Bueno, hemen dena argi dago! Hau guztia kontrolatuko duen programa bat instalatu». Bai, bai: Prometheus + Grafana + pluginak.
Eta gaineratzen dute: "Bi aste dituzu, ziurtatu dena seguru dagoela".

Ikusten ditugun proiektu askotan, pertsona bat jartzen da jarraipena egiteko. Imajinatu 2 astez monitorizazioa egiteko pertsona bat kontratatu nahi dugula, eta curriculuma idazten diogula. Zein gaitasun izan behar ditu pertsona honek, orain arte esan dugun guztia ikusita?

• Burdinazko azpiegituren funtzionamenduaren jarraipena eta berezitasunak ulertu behar ditu.
• Kubernetes monitorizatzeko zehaztasunak ulertu behar ditu (eta denek "kubora" joan nahi dute, dena abstraktu dezakezulako, ezkutatu, administratzaileak gainontzekoaz arduratuko delako) - bera, bere azpiegitura eta aplikazioak nola kontrolatu ulertu behar ditu. barruan.
• Zerbitzuak elkarren artean modu berezi batean komunikatzen direla ulertu behar du, eta zerbitzuek elkarren arteko harremanaren berezitasunak ezagutu behar ditu. Oso posible da zerbitzu batzuk modu sinkronoan komunikatzen diren proiektu bat ikustea, beste biderik ez dagoelako. Adibidez, backend-a REST bidez doa, gRPC bidez katalogo zerbitzura, produktuen zerrenda bat jasotzen du eta itzultzen du. Ezin duzu hemen itxaron. Eta beste zerbitzu batzuekin modu asinkronoan funtzionatzen du. Eskaera entrega-zerbitzura transferitu, gutun bat bidali, etab.
  Ziurrenik dagoeneko igeri egin duzu honetatik guztietatik? Eta administratzailea, hau kontrolatu behar duena, are nahastuago zegoen.
• Behar bezala planifikatzeko eta planifikatzeko gai izan behar du, lana gero eta handiagoa denez.
• Beraz, sortutako zerbitzutik estrategia bat sortu behar du, berariaz kontrolatzen den ulertzeko. Proiektuaren arkitektura eta garapena ulertzea behar du + garapenean erabiltzen diren teknologien ulermena.

Gogora dezagun kasu guztiz normal bat: zerbitzu batzuk PHP-n daude, zerbitzu batzuk Go-n daude, beste zerbitzu batzuk JS-n. Nolabait elkarrekin lan egiten dute. Hortik dator "mikrozerbitzua" terminoa: sistema indibidual asko daude, non garatzaileek ezin baitute proiektua bere osotasunean ulertu. Taldearen zati batek bere kabuz funtzionatzen duten eta gainerako sistemak nola funtzionatzen duen ezagutzen ez duten zerbitzuak JSn idazten ditu. Beste zatiak zerbitzuak Python-en idazten ditu eta ez du beste zerbitzuen funtzionamendua oztopatzen; bere eremuan isolatuta daude. Hirugarrena PHPn edo beste zerbaitetan zerbitzuak idaztea da.
20 pertsona horiek guztiak 15 zerbitzutan banatuta daude, eta hori guztia ulertu behar duen administratzaile bakarra dago. Gelditu! sistema 15 mikrozerbitzutan banatu besterik ez dugu egin, 20 pertsonak ezin baitute sistema osoa ulertu.

Baina nolabait kontrolatu behar da...

Zein da emaitza? Ondorioz, pertsona bat dago garatzaile talde osoak ulertu ezin duen guztia ateratzen duena, eta, aldi berean, goian adierazi duguna ezagutu eta egiteko gai izan behar du -hardware azpiegitura, Kubernetes azpiegitura, etab.

Zer esango dut... Houston, arazoak ditugu.

Software-proiektu moderno baten jarraipena software-proiektu bat da berez

Monitorizazioa softwarea dela uste faltsutik, mirarien sinesmena garatzen dugu. Baina mirariak, ai, ez dira gertatzen. Ezin duzu zabbix instalatu eta dena funtzionatuko duela espero. Grafana instalatzeak eta dena ondo egongo den itxaropena ez du balio. Denbora gehiena zerbitzuen funtzionamenduaren eta elkarren arteko elkarrekintzaren egiaztapenak antolatzeko erabiliko da, kanpoko sistemen funtzionamendua egiaztatzen. Izan ere, denboraren %90 ez da gidoiak idazten, softwarea garatzen baizik. Eta proiektuaren lana ulertzen duen talde batek kudeatu beharko luke.
Egoera honetan pertsona bat monitorizaziora botatzen bada, hondamendia gertatuko da. Leku guztietan gertatzen dena.

Adibidez, Kafkaren bidez elkarren artean komunikatzen diren hainbat zerbitzu daude. Eskaera iritsi zen, eskaerari buruzko mezu bat bidali genion Kafkari. Eskaerari buruzko informazioa entzun eta salgaiak bidaltzen dituen zerbitzu bat dago. Eskaerari buruzko informazioa entzun eta erabiltzaileari gutun bat bidaltzen dion zerbitzu bat dago. Eta orduan zerbitzu pila bat gehiago agertzen dira, eta nahasten hasten gara.

Eta hori ere administratzaileari eta garatzaileei ematen badiezu kaleratu baino denbora gutxi falta den fasean, pertsonak protokolo hau osoa ulertu beharko du. Horiek. Eskala honetako proiektu batek denbora asko behar du, eta sistemaren garapenean kontuan hartu behar da.
Baina sarritan, batez ere startupetan, ikusten dugu nola monitorizazioa gerora arte atzeratzen den. "Orain Kontzeptu Froga bat egingo dugu, berarekin abiaraziko dugu, utzi erori - sakrifikatzeko prest gaude. Eta gero guztiaren jarraipena egingo dugu». Proiektua dirua irabazten hasten denean (edo bada), negozioak funtzio gehiago gehitu nahi ditu - lanean hasi delako, beraz, gehiago zabaldu behar da! Eta aurreko guztia kontrolatu behar duzun puntuan zaude, eta horrek ez du denboraren %1a hartzen, askoz gehiago baizik. Eta, bide batez, garatzaileak beharrezkoak izango dira monitorizazioa egiteko, eta errazagoa da funtzio berrietan lan egiten uztea. Ondorioz, funtzio berriak idazten dira, dena izorratzen da eta blokeo amaigabean zaude.

Beraz, nola egin proiektu baten jarraipena hasieratik hasita, eta zer egin jarraipena egin behar den proiektu bat lortzen baduzu, baina ez dakizu nondik hasi?

Lehenik eta behin, planifikatu behar duzu.

Digresio lirikoa: sarritan azpiegituren jarraipenarekin hasten dira. Adibidez, Kubernetes dugu. Has gaitezen Prometheus instalatzen Grafanarekin, “kuboa” monitorizatzeko pluginak instalatuz. Garatzaileek ez ezik, administratzaileek ere praktika tamalgarria dute: "Plugin hau instalatuko dugu, baina pluginak ziurrenik badaki nola egin". Jendeari gustatzen zaio sinple eta zuzenetik hastea, ekintza garrantzitsuekin baino. Eta azpiegituren jarraipena erraza da.

Lehenik eta behin, erabaki zer eta nola kontrolatu nahi duzun, eta, ondoren, hautatu tresna bat, besteek ezin dutelako zuregatik pentsatu. Eta beharko lukete? Beste batzuek beren artean pentsatu zuten sistema unibertsal bati buruz - edo ez zuten batere pentsatu plugin hau idatzi zenean. Eta plugin honek 5 mila erabiltzaile izateak ez du esan nahi ezertarako balio duenik. Beharbada, 5001.a bihurtuko zara, aurretik jada 5000 lagun zeudelako.

Azpiegitura monitorizatzen hasten bazara eta zure aplikazioaren backendak erantzutea uzten badu, erabiltzaile guztiek galduko dute mugikorreko aplikazioarekin konexioa. Errore bat agertuko da. Zuregana etorriko dira eta esango dizute: "Aplikazioa ez dabil, zer egiten ari zara hemen?" - "Segimendua egiten ari gara". — "Nola kontrolatzen duzu aplikazioa funtzionatzen ez duela ikusten ez baduzu?!"

1. Uste dut erabiltzailearen sarrera puntutik zehatz-mehatz kontrolatzen hasi behar duzula. Erabiltzaileak ez badu ikusten aplikazioa funtzionatzen ari dela, hori da, hutsegite bat da. Eta monitorizazio sistemak horri buruz ohartarazi beharko luke lehenik.
2. Eta orduan bakarrik egingo dugu jarraipena azpiegitura. Edo paraleloan egin. Azpiegiturarekin errazagoa da - hemen azkenean zabbix instalatu besterik ez dugu egin.
3. Eta orain aplikazioaren sustraietara joan behar duzu gauzak non funtzionatzen ez duten ulertzeko.

Nire ideia nagusia monitorizazioa garapen prozesuarekin batera joan behar dela da. Jarraipen-taldea beste zeregin batzuetarako distraitzen baduzu (CI/CD-a sortzea, sandboxinga, azpiegiturak berrantolatzea), monitorizazioa atzeratzen hasiko da eta agian ez duzu inoiz garapenarekin atzemateko (edo lehenago edo beranduago gelditu beharko duzu).

Dena mailaka

Horrela ikusten dut monitorizazio sistema baten antolaketa.

1) Aplikazio maila:

• aplikazioaren negozio-logika monitorizatzea;
• zerbitzuen osasun-neurriak kontrolatzea;
• integrazioaren jarraipena.

2) Azpiegitura maila:

• orkestrazio mailaren jarraipena;
• sistemaren softwarearen jarraipena;
• burdina mailaren jarraipena.

3) Berriz ere aplikazio maila - baina ingeniaritza produktu gisa:

• aplikazioen erregistroak biltzea eta kontrolatzea;
• APM;
• trazadura.

4) Abisua:

• abisu sistemaren antolaketa;
• betebehar-sistema baten antolaketa;
• «Ezagutza-base» baten antolaketa eta gertakariak prozesatzeko lan-fluxua.

Garrantzitsua da: alertara iristen gara ez ondoren, baina berehala! Ez dago monitorizazioa abiarazi beharrik eta "nolabait geroago" jakin ezazu zeinek jasoko dituen alertak. Azken finean, zein den monitorizazioaren zeregina: sisteman zerbait gaizki funtzionatzen duen ulertzea eta pertsona egokiei horren berri ematea. Hau amaierara arte uzten baduzu, pertsona egokiek jakingo dute zerbait gaizki doala "ezer ez dabil guretzat" deituz soilik.

Aplikazio-geruza - Negozio-logikaren jarraipena

Hemen aplikazioak erabiltzailearentzat funtzionatzen duela egiaztatzeaz ari gara.

Maila hau garapen fasean egin behar da. Adibidez, baldintzapeko Prometheus bat dugu: egiaztapenak egiten dituen zerbitzarira doa, amaierako puntua ateratzen du eta amaierako puntua APIa egiaztatzen du.

Askotan webgunea funtzionatzen ari dela ziurtatzeko hasierako orria kontrolatzeko eskatzen zaienean, programatzaileek APIa funtzionatzen ari dela ziurtatzeko behar duten bakoitzean atera daitekeen helduleku bat ematen dute. Eta une honetan programatzaileek oraindik /api/test/helloworld hartzen eta idazten dute
Dena funtzionatzen duela ziurtatzeko modu bakarra? - Ez!

• Egiaztapen horiek sortzea garatzaileen zeregina da funtsean. Unitate-probak kodea idazten duten programatzaileek idatzi behar dituzte. Administratzaileari filtratzen badiozu, "Aide, hona hemen 25 funtzio guztietarako API protokoloen zerrenda, mesedez kontrolatu guztia!" - Ez da ezer aterako.
• "Kaixo mundua" inprimatzen baduzu, inork ez du inoiz jakingo APIak funtzionatu behar duen eta funtzionatzen duen. API aldaketa bakoitzak egiaztapenen aldaketa ekarri behar du.
• Dagoeneko arazoren bat baduzu, gelditu eginbideak eta esleitu txeke hauek idatziko dituzten garatzaileak, edo galerak onartu, onartu ezer ez dela egiaztatu eta huts egingo duela.

Aholku teknikoak:

• Ziurtatu kanpoko zerbitzari bat antolatzen duzula egiaztapenak antolatzeko - ziurtatu behar duzu zure proiektua kanpoko munduarentzat eskuragarri dagoela.
• Antolatu egiaztapenak API protokolo osoan, ez bakarrik amaierako puntuetan.
• Sortu prometheus-endpoint bat probaren emaitzekin.

Aplikazio-geruza - osasun-neurrien jarraipena

Orain zerbitzuen kanpoko osasun-neurriez ari gara.

Aplikazioaren "helduleku" guztiak kontrolatzen ditugula erabaki dugu kanpoko egiaztapenak erabiliz, kanpoko monitorizazio sistema batetik deitzen ditugunak. Baina hauek dira erabiltzaileak "ikusten dituen heldulekuak". Gure zerbitzuak beraiek funtzionatzen dutela ziurtatu nahi dugu. Istorio hobe bat dago hemen: K8s-ek osasun-kontrolak ditu, gutxienez "kuboa" bera zerbitzua funtzionatzen ari dela sinetsi ahal izateko. Baina ikusi ditudan txekeen erdiak "kaixo mundua" inprimatu bera dira. Horiek. Beraz, behin zabaldu ondoren, dena ondo dagoela erantzun zuen, hori da guztia. Eta zerbitzuak, bere API propioa ematen badu, API horretarako sarrera-puntu izugarria du, eta hori ere kontrolatu behar da, funtzionatzen duela jakin nahi dugulako. Eta dagoeneko barruan jarraitzen ari gara.

Nola inplementatu behar bezala teknikoki: zerbitzu bakoitzak bere egungo errendimenduaren amaierako puntu bat erakusten du, eta Grafanaren (edo beste edozein aplikazioren) grafikoetan zerbitzu guztien egoera ikusten dugu.

• API aldaketa bakoitzak egiaztapenen aldaketa ekarri behar du.
• Sortu zerbitzu berri bat berehala osasun-neurriekin.
• Administratzaile bat garatzaileengana etor daiteke eta "gehi iezadazu funtzio pare bat, guztia ulertzeko eta honi buruzko informazioa nire monitorizazio sistemara gehitzeko". Baina garatzaileek normalean erantzuten dute: "Ez dugu ezer gehituko kaleratu baino bi aste lehenago".
  Jakinarazi garapen-zuzendariek halako galerak izango direla, jakin dezatela garapen-kudeatzaileen zuzendaritzak ere. Dena erortzen denean, norbaitek "etengabe erortzen den zerbitzua" kontrolatzeko eskatuko duelako oraindik (c)
• Bide batez, esleitu garatzaileak Grafanarako pluginak idazteko - hau laguntza ona izango da administratzaileentzat.

Aplikazio-geruza - Integrazioaren jarraipena

Integrazioaren monitorizazioa negozio-sistema kritikoen arteko komunikazioen monitorizazioan zentratzen da.

Esaterako, elkarren artean komunikatzen diren 15 zerbitzu daude. Hauek jada ez dira gune bereiziak. Horiek. ezin dugu zerbitzua bere kabuz atera, /helloworld lortu eta zerbitzua martxan dagoela ulertu. Eskaerak egiteko web-zerbitzuak eskaerari buruzko informazioa bidali behar duelako autobusera -autobusetik, biltegi-zerbitzuak mezu hau jaso eta gehiago lan egin behar du-. Eta posta elektronikoa banatzeko zerbitzuak hori nolabait gehiago prozesatu behar du, etab.

Horren arabera, ezin dugu ulertu, banakako zerbitzu bakoitzari begiratuta, guztiak funtzionatzen duela. Autobus jakin bat dugulako eta horren bidez dena komunikatzen eta elkarreragiten duen.
Hori dela eta, etapa honek beste zerbitzu batzuekin elkarrekintzarako zerbitzuak probatzeko etapa markatu beharko luke. Ezinezkoa da komunikazioaren jarraipena antolatzea mezu-artekariaren jarraipena eginez. Datuak igortzen dituen zerbitzuren bat eta horiek jasotzen dituen zerbitzuren bat baldin badago, broker-aren jarraipena egitean alde batetik bestera hegaldatzen diren datuak soilik ikusiko ditugu. Nahiz eta nolabait datu horien interakzioa kontrolatzea barnean lortu (ekoizle jakin batek datuak argitaratzen dituela, norbaitek irakurtzen dituela, fluxu honek Kafka-ra joaten jarraitzen duela) oraindik ez digu informaziorik emango zerbitzu batek mezua bertsio batean bidaliz gero. , baina beste zerbitzuak ez zuen bertsio hau espero eta saltatu egin zuen. Ez dugu honen berri izango, zerbitzuek dena funtzionatzen ari dela esango baitigute.

Zer egitea gomendatzen dut:

• Komunikazio sinkronikorako: amaierako puntuak erlazionatutako zerbitzuei eskaerak egiten dizkie. Horiek. amaierako puntu hau hartzen dugu, zerbitzuaren barruan dagoen script bat ateratzen dugu, puntu guztietara doana eta esaten duena: "Hara tira dezaket, eta hara tira, horra tira dezaket..."
• Komunikazio asinkronorako: sarrerako mezuak - amaierako puntuak probako mezuak dauden autobusean egiaztatzen du eta prozesatzeko egoera bistaratzen du.
• Komunikazio asinkronorako: irteerako mezuak - amaierako puntuak probako mezuak bidaltzen ditu autobusera.

Normalean gertatzen den bezala: datuak autobusera botatzen dituen zerbitzu bat dugu. Zerbitzu honetara etortzen gara eta bere integrazio-osasunaren berri emateko eskatzen dizugu. Eta zerbitzuak nonbait gehiago (WebApp) mezu bat ekoitzi behar badu, proba-mezu hau sortuko du. Eta Eskaerak Prozesatzeko aldean zerbitzu bat exekutatzen badugu, lehenik eta behin independentean argitaratu dezakeena argitaratzen du, eta menpeko gauza batzuk badaude, orduan autobusetik probako mezu multzo bat irakurtzen du, haiek prozesatu ditzakeela ulertzen du, jakinarazi eta , beharrezkoa bada, gehiago argitaratu, eta honi buruz esaten du - dena ondo dago, bizirik nago.

Askotan entzuten dugu galdera "nola probatu dezakegu hau borroka datuetan?" Esaterako, eskaera-zerbitzu berari buruz ari gara. Eskaerak mezuak bidaltzen ditu salgaiak kentzen diren biltegira: ezin dugu hori borroka datuetan probatu, "nire ondasunak kendu egingo direlako!" Irtenbidea: Planifikatu proba osoa hasieratik. Isekak egiten dituzten unitate-probak ere badituzu. Beraz, egin ezazu maila sakonago batean, non negozioaren funtzionamenduari kalterik egiten ez dion komunikazio kanal bat duzun.

Azpiegitura maila

Azpiegituren jarraipena aspalditik berez monitorizatzen den zerbait da.

• Azpiegituren jarraipena prozesu bereizi gisa abiarazi daiteke eta abiarazi behar da.
• Ez zenuke hasi behar abian den proiektu batean azpiegituren jarraipenarekin, benetan nahi baduzu ere. Hau devops guztien mina da. "Lehenengo klusterraren jarraipena egingo dut, azpiegituraren jarraipena egingo dut" - hau da. Lehenik eta behin, behean dagoena kontrolatuko du, baina ez da aplikazioan sartuko. Aplikazioa gauza ulertezina delako devopsentzat. Filtratu zitzaion, eta ez du ulertzen nola funtzionatzen duen. Eta azpiegitura ulertzen du eta horrekin hasten da. Baina ez - beti aplikazioa kontrolatu behar duzu lehenik.
• Ez ibili alerta kopuruarekin. Sistema modernoen konplexutasuna kontuan hartuta, alertak etengabe ari dira hegan, eta alerta mordo honekin bizi behar duzu nolabait. Eta guardiako pertsonak, hurrengo ehun abisu begiratuta, "Ez dut horretan pentsatu nahi" erabakiko du. Alertak gauza kritikoei buruz soilik jakinarazi behar dira.

Aplikazio-maila negozio-unitate gisa

Puntu nagusiak:

• ELK. Hau industria estandarra da. Arrazoiren batengatik ez bazara erregistroak biltzen, hasi berehala egiten.
• APM. Kanpoko APMak aplikazioen monitorizazioa azkar ixteko modu gisa (NewRelic, BlackFire, Datadog). Gauza hau aldi baterako instala dezakezu zurekin gertatzen ari zarena nolabait ulertzeko.
• Trazadura. Dozenaka mikrozerbitzutan, dena trazatu behar duzu, eskaera ez baita bere kabuz bizitzen. Oso zaila da geroago gehitzea, beraz, hobe da garapenean jarraipena berehala programatzea - ​​hau da garatzaileen lana eta erabilgarritasuna. Oraindik ezarri ez baduzu, inplementatu! Ikus Jaeger/Zipkin

Abisatzen

• Jakinarazpen-sistema baten antolaketa: gauza mordoa kontrolatzeko baldintzetan, jakinarazpenak bidaltzeko sistema bateratu bat egon beharko litzateke. Grafanan dezakezu. Mendebaldean, denek erabiltzen dute PagerDuty. Alertak argiak izan behar dira (adibidez, nondik datozen...). Eta jakinarazpenak jasotzen diren kontrolatzea komeni da
• Betebehar-sistema baten antolaketa: alertak ez zaizkie guztiei bidali behar (edo jende guztiak erreakzionatuko du, edo inork ez du erreakzionatuko). Garatzaileek ere arreta egon behar dute: ziurtatu ardura-eremuak zehazten dituztela, argibide argiak eman eta bertan idatzi nori deitu behar dioten astelehenean eta asteazkenean zehazki, eta nori deitu asteartean eta ostiralean (bestela, ez diote inori deituko ere arazo handi baten gertaera - beldurra izango dute zu esnatzeko edo traba egiteko: jendeari, oro har, ez zaio gustatzen beste jendea deitzea eta esnatzea, batez ere gauez). Eta azaldu laguntza eskatzea ez dela gaitasun ezaren adierazle (“Laguntza eskatzen dut, horrek esan nahi du langile txarra naizela”), bultzatu laguntza eskaerak.
• Gorabeherak prozesatzeko “ezagutza-basea” eta lan-fluxua antolatzea: gorabehera larri bakoitzeko, autopsia bat planifikatu behar da, eta behin-behineko neurri gisa, gertakaria konponduko duten ekintzak erregistratu behar dira. Eta egin ezazu praktika bat errepikatutako alertak bekatu direla; kodea edo azpiegitura lanetan konpondu behar dira.

Teknologia pila

Imajina dezagun gure pila honako hau dela:

• datu bilketa - Prometheus + Grafana;
• log azterketa - ELK;
• APM edo Tracing - Jaeger (Zipkin).

Aukerak aukeratzea ez da kritikoa. Zeren hasieran sistemaren jarraipena nola egin eta plan bat idatzi bazenuen, orduan zure eskakizunetara egokitzen diren tresnak aukeratzen hasten zara. Galdera da lehenik eta behin zer aukeratu duzun kontrolatzea. Beharbada hasieran aukeratutako tresna ez baita batere egokitzen zure beharretara.

Azkenaldian nonahi ikusten ditudan puntu tekniko batzuk:

Prometheus Kubernetesen barruan sartzen ari da - nork asmatu zuen hau?! Zure klusterrak huts egiten badu, zer egingo duzu? Barruan kluster konplexu bat baduzu, kluster barruan monitorizazio-sistemaren bat egon beharko litzateke, eta kanpoan beste batzuk, kluster barruko datuak bilduko dituena.

Kluster barruan erregistroak eta gainerako guztiak biltzen ditugu. Baina monitorizazio sistemak kanpoan egon behar du. Askotan, barnean Promtheus instalatuta dagoen kluster batean, gunearen funtzionamenduaren kanpoko egiaztapenak egiten dituzten sistemak ere badaude. Zer gertatzen da kanpoko munduarekiko konexioak behera egin eta aplikazioak funtzionatzen ez badu? Barruan dena ondo dagoela ematen du, baina erabiltzaileei gauzak ez dizkie errazten.

Findings

• Garapenaren jarraipena ez da utilitateen instalazioa, software produktu baten garapena baizik. Gaur egungo monitorizazioaren %98 kodetzea da. Zerbitzuetan kodetzea, kanpoko egiaztapenak kodetzea, kanpoko zerbitzuak egiaztatzea, eta kito.
• Ez galdu zure garatzaileen denbora monitorizazioan: haien lanaren %30eraino har dezake, baina merezi du.
• Devops, ez kezkatu ezin duzula zerbait kontrolatu, gauza batzuk pentsatzeko modu guztiz desberdinak direlako. Ez zinen programatzailea, eta monitorizazio lana da hain zuzen ere haien lana.
• Proiektua dagoeneko martxan badago eta monitorizatu gabe badago (eta kudeatzailea bazara), esleitu baliabideak jarraipena egiteko.
• Produktua dagoeneko ekoizten ari bada, eta "jarraipena konfiguratzeko" esan zioten devopsa bazara, saiatu zuzendaritzari hau guztia idatzi dudanari buruz azaltzen.

Saint Highload++ konferentziako txostenaren bertsio hedatua da hau.

Nire ideiak eta pentsamenduak eta erlazionatutako gaiak interesatzen bazaizu, hemen egin dezakezu irakurri kanala 🙂

Iturria: www.habr.com