Is monitoring dea? - Lang libje tafersjoch

Sûnt 2008 is ús bedriuw primêr dwaande west mei ynfrastruktuerbehear en rûn-de-klok technyske stipe foar webprojekten: wy hawwe mear as 400 kliïnten, dat is sawat 15% fan Russyske e-commerce. Dêrtroch wurdt in heul ferskaat arsjitektuer stipe. As der wat falt, binne wy ​​ferplichte om it binnen 15 minuten te reparearjen. Mar om te begripen dat der in ûngelok bard is, moatte jo it projekt kontrolearje en reagearje op ynsidinten. Hoe dit te dwaan?

Ik leau dat der in probleem is by it organisearjen fan in goed tafersjochsysteem. As d'r gjin problemen west hie, dan soe myn taspraak bestean út ien proefskrift: "Ynstallearje asjebleaft Prometheus + Grafana en plugins 1, 2, 3." Spitigernôch wurket it sa net mear. En it wichtichste probleem is dat elkenien bliuwt te leauwen yn eat dat bestie yn 2008, yn termen fan software komponinten.

Oangeande de organisaasje fan it monitoaringsysteem soe ik it weagje om te sizzen dat... projekten mei foechhawwende monitoaring net bestean. En de situaasje is sa slim dat as der wat falt, d'r in risiko is dat it ûngemurken sil gean - ommers, elkenien is der wis fan dat "alles wurdt kontrolearre."
Miskien wurdt alles kontrolearre. Mar hoe?

Wy hawwe allegear in ferhaal tsjinkaam lykas it folgjende: in bepaalde devops, in bepaalde admin wurket, in ûntwikkelteam komt nei har en seit - "wy binne frijlitten, no kontrolearje." Monitor wat? Hoe't it wurket?

OK. Wy folgje de âlderwetske manier. En it feroaret al, en it docht bliken dat jo tsjinst A kontroleare, dy't tsjinst B waard, dy't ynteraksje mei tsjinst C. Mar it ûntwikkelteam fertelt jo: "Ynstallearje de software, it moat alles kontrolearje!"

Dus wat is feroare? - Alles is feroare!

2008 Alles is ynoarder

D'r binne in pear ûntwikkelders, ien server, ien databaseserver. It giet allegear hjirwei. Wy hawwe wat ynformaasje, wy ynstallearje zabbix, Nagios, kaktussen. En dan sette wy dúdlike warskôgings op 'e CPU, op skiifoperaasje en op skiifromte. Wy dogge ek in pear manuele kontrôles om te soargjen dat de side reagearret en dat bestellingen yn 'e database oankomme. En dat is it - wy binne min of mear beskerme.

As wy de hoemannichte wurk fergelykje dat de behearder doe dien hat om tafersjoch te leverjen, dan wie 98% fan it automatysk: de persoan dy't de tafersjoch docht moat begripe hoe't jo Zabbix ynstallearje, hoe't jo it konfigurearje en warskôgings konfigurearje. En 2% - foar eksterne kontrôles: dat de side reagearret en makket in fersyk oan 'e databank, dat nije oarders binne oankommen.

2010 De lading groeit

Wy begjinne it web te skaaljen, in sykmasine tafoegje. Wy wolle derfoar soargje dat de produktkatalogus alle produkten befettet. En dat produktsykjen wurket. Dat de databank wurket, dat der oarders wurde makke, dat de side ekstern reagearret en reagearret fan twa servers en de brûker net út de side skopt wurdt wylst it opnij balansearre is nei in oare server, ensfh. D'r binne mear entiteiten.

Boppedat bliuwt de entiteit ferbûn mei ynfrastruktuer noch altyd de grutste yn 'e holle fan' e manager. D'r is noch in idee yn myn holle dat de persoan dy't de tafersjoch docht de persoan is dy't zabbix sil ynstallearje en it kin konfigurearje.

Mar tagelyk ferskynt der wurk oan it útfieren fan eksterne kontrôles, oan it meitsjen fan in set fan queryscripts foar sykyndeksearring, in set skripts om te kontrolearjen dat it sykjen feroaret tidens it yndeksearringsproses, in set skripts dy't kontrolearje dat guod wurdt oerbrocht nei de leveringstsjinst, ensfh. ensafuorthinne.

Opmerking: ik haw 3 kear "in set skripts" skreaun. Dat is, de persoan dy't ferantwurdlik is foar tafersjoch is net langer dejinge dy't gewoan zabbix ynstalleart. Dit is in persoan dy't begjint te kodearjen. Mar der is noch neat feroare yn de tinzen fan it team.

Mar de wrâld feroaret, wurdt hieltyd komplekser. In virtualisaasjelaach en ferskate nije systemen wurde tafoege. Se begjinne te ynteraksje mei elkoar. Wa sei "rûkt nei mikrotsjinsten?" Mar elke tsjinst liket noch altyd op in webside yndividueel. Wy kinne der nei draaie en begripe dat it de nedige ynformaasje leveret en op himsels wurket. En as jo in behearder binne dy't konstant belutsen binne by in projekt dat al 5-7-10 jier ûntwikkele hat, sammelet dizze kennis: in nij nivo ferskynt - jo hawwe it realisearre, in oar nivo ferskynt - jo hawwe it realisearre ...

Mar komselden begeliedt immen in projekt foar 10 jier.

Resume fan Monitoringman

Stel dat jo by in nije opstart kamen dy't fuortendaliks 20 ûntwikkelders ynhierd, 15 mikrotsjinsten skreau, en jo binne in admin dy't wurdt ferteld: "Bou CI / CD. Asjebleaft." Jo hawwe boud CI / CD en ynienen jo hearre: "It is dreech foar ús om te wurkjen mei produksje yn in" kubus ", sûnder te begripen hoe't de applikaasje sil wurkje yn it. Meitsje ús in sânbak yn deselde "kubus".
Jo meitsje in sânbak yn dizze kubus. Se fertelle jo fuortendaliks: "Wy wolle in poadiumdatabase dy't elke dei wurdt bywurke fanút produksje, sadat wy begripe dat it wurket op 'e database, mar tagelyk de produksjedatabase net bedjerre."

Jo wenje yn dit alles. Der binne noch 2 wiken foar de frijlitting, se fertelle jo: "No litte wy dit alles kontrolearje ..." Dat is. kontrolearje de klusterynfrastruktuer, kontrolearje de arsjitektuer fan mikrotsjinsten, kontrolearje wurk mei eksterne tsjinsten ...

En myn kollega's nimme it gewoane skema út 'e holle en sizze: "Nou, hjir is alles dúdlik! Ynstallearje in programma dat dit alles sil kontrolearje." Ja, ja: Prometheus + Grafana + plugins.
En se foegje ta: "Jo hawwe twa wiken, soargje derfoar dat alles feilich is."

Yn in protte projekten dy't wy sjogge, wurdt ien persoan tawiisd foar monitoring. Stel jo foar dat wy in persoan wolle hiere om 2 wiken te kontrolearjen, en wy skriuwe in resume foar him. Hokker feardichheden moat dizze persoan hawwe, sjoen alles wat wy oant no ta hawwe sein?

• Hy moat de tafersjoch en spesifikaasjes fan 'e wurking fan' e izeren ynfrastruktuer begripe.
• Hy moat de spesifikaasjes fan it kontrolearjen fan Kubernetes begripe (en elkenien wol nei de "kubus" gean, om't jo fan alles kinne abstrahere, ferbergje, om't de admin mei de rest sil omgean) - sels, syn ynfrastruktuer, en begripe hoe't jo applikaasjes kinne kontrolearje binnenkant.
• Hy moat begripe dat tsjinsten op spesjale manieren mei-inoar kommunisearje, en de spesifiken witte fan hoe't tsjinsten mei-inoar omgeane. It is goed mooglik om in projekt te sjen wêr't guon tsjinsten syngroan kommunisearje, om't d'r gjin oare manier is. Bygelyks, de backend giet fia REST, fia gRPC nei de katalogus tsjinst, ûntfangt in list fan produkten en jout it werom. Jo kinne hjir net wachtsje. En mei oare tsjinsten wurket it asynchronysk. Oermeitsje de bestelling nei de levering tsjinst, stjoer in brief, etc.
  Hawwe jo wierskynlik al fan dit alles swommen? En de admin, dy't dit kontrolearje moat, waard noch mear yn 'e war.
• Hy moat goed planne en planne kinne - as it wurk mear en mear wurdt.
• Hy moat dêrom in strategy meitsje fan 'e oanmakke tsjinst om te begripen hoe't it spesifyk kontrolearje kin. Hy hat in begryp nedich fan 'e arsjitektuer fan it projekt en syn ûntwikkeling + in begryp fan' e technologyen brûkt yn ûntwikkeling.

Litte wy in absolút normaal gefal ûnthâlde: guon tsjinsten binne yn PHP, guon tsjinsten binne yn Go, guon tsjinsten binne yn JS. Se wurkje op ien of oare manier mei elkoar. Dit is wêr't de term "mikroservice" komt: d'r binne safolle yndividuele systemen dat ûntwikkelders it projekt as gehiel net kinne begripe. Ien diel fan it team skriuwt tsjinsten yn JS dy't op har eigen wurkje en net witte hoe't de rest fan it systeem wurket. It oare diel skriuwt tsjinsten yn Python en bemuoit net mei hoe't oare tsjinsten wurkje, se binne isolearre yn har eigen gebiet. De tredde is it skriuwen fan tsjinsten yn PHP of wat oars.
Al dizze 20 minsken binne ferdield yn 15 tsjinsten, en d'r is mar ien admin dy't dit alles moat begripe. Ophâlde! wy splitst it systeem krekt yn 15 microservices omdat 20 minsken kinne net begripe it hiele systeem.

Mar it moat op ien of oare manier kontrolearre wurde ...

Wat is it resultaat? As resultaat is d'r ien persoan dy't komt mei alles dat it heule team fan ûntwikkelders net kin begripe, en tagelyk moat hy ek witte en kinne dwaan wat wy hjirboppe oanjûn hawwe - hardware-ynfrastruktuer, Kubernetes-ynfrastruktuer, ensfh.

Wat kin ik sizze ... Houston, wy hawwe problemen.

It kontrolearjen fan in modern softwareprojekt is in softwareprojekt op himsels

Fanút it falske leauwen dat tafersjoch software is, ûntwikkelje wy in leauwen yn wûnders. Mar wûnders, helaas, net barre. Jo kinne zabbix net ynstallearje en ferwachtsje dat alles wurket. It hat gjin punt om Grafana te ynstallearjen en te hoopjen dat alles goed sil wêze. It grutste part fan 'e tiid wurdt bestege oan it organisearjen fan kontrôles fan de wurking fan tsjinsten en harren ynteraksje mei elkoar, kontrolearjen hoe't eksterne systemen wurkje. Yn feite sil 90% fan 'e tiid net bestege wurde oan it skriuwen fan skripts, mar oan it ûntwikkeljen fan software. En it moat wurde behannele troch in team dat it wurk fan it projekt begrypt.
As yn dizze situaasje ien persoan wurdt smiten yn tafersjoch, dan sil ramp barre. Wat is wat bart oeral.

Der binne bygelyks ferskate tsjinsten dy't fia Kafka mei-inoar kommunisearje. De bestelling kaam, wy hawwe in berjocht oer de bestelling stjoerd nei Kafka. Der is in tsjinst dy't harket nei ynformaasje oer de bestelling en ferstjoert it guod. Der is in tsjinst dy't harket nei ynformaasje oer de bestelling en stjoert in brief oan de brûker. En dan ferskine in bosk mear tsjinsten, en wy begjinne yn 'e war te wurden.

En as jo dit ek jouwe oan de behearder en ûntwikkelders op it poadium dat der in koarte tiid oer is foar de frijlitting, sil de persoan dit heule protokol moatte begripe. Dy. In projekt fan dizze skaal nimt in wichtige hoemannichte tiid, en dit moat wurde rekken holden yn 'e systeemûntwikkeling.
Mar heul faak, foaral by startups, sjogge wy hoe't tafersjoch wurdt útsteld oant letter. "No sille wy in Proof of Concept meitsje, wy sille dermei lansearje, lit it falle - wy binne ree om te offerjen. En dan sille wy it allegear kontrolearje.” As (of as) it projekt jild begjint te meitsjen, wol it bedriuw noch mear funksjes tafoegje - om't it begon te wurkjen, dus it moat fierder útrol wurde! En jo binne op it punt wêr't jo earst alles moatte kontrolearje, wat net 1% fan 'e tiid nimt, mar folle mear. En trouwens, ûntwikkelders sille nedich wêze foar tafersjoch, en it is makliker om se te litten wurkje oan nije funksjes. As gefolch, nije funksjes wurde skreaun, alles wurdt geschroefd, en jo binne yn in einleaze deadlock.

Dus hoe kinne jo in projekt folgje fan it begjin ôf, en wat te dwaan as jo in projekt krije dat kontrolearre wurde moat, mar jo net witte wêr't jo moatte begjinne?

Earst moatte jo planje.

Lyryske digression: se begjinne faak mei ynfrastruktuermonitoring. Wy hawwe bygelyks Kubernetes. Litte wy begjinne mei it ynstallearjen fan Prometheus mei Grafana, it ynstallearjen fan plugins foar it kontrolearjen fan de "kubus". Net allinich ûntwikkelders, mar ek behearders hawwe de ûngelokkige praktyk fan: "Wy sille dizze plugin ynstallearje, mar de plugin wit wierskynlik hoe't it moat." Minsken wolle graach begjinne mei it ienfâldige en rjochtlinige, ynstee fan mei de wichtige aksjes. En ynfrastruktuermonitoring is maklik.

Beslute earst wat en hoe't jo wolle kontrolearje, en selektearje dan in ark, om't oare minsken net foar jo kinne tinke. En moatte se? Oare minsken tochten by harsels, oer in universele systeem - of tochten hielendal net doe't dizze plugin waard skreaun. En gewoan om't dizze plugin 5 tûzen brûkers hat, betsjuttet net dat it fan ien of oare nut is. Miskien wurde jo de 5001e gewoan om't d'r earder al 5000 minsken wiene.

As jo ​​de ynfrastruktuer begjinne te kontrolearjen en de efterkant fan jo applikaasje stopet te reagearjen, sille alle brûkers de ferbining mei de mobile applikaasje ferlieze. In flater sil ferskine. Se sille nei jo komme en sizze "De applikaasje wurket net, wat dogge jo hjir?" - "Wy kontrolearje." - "Hoe kontrolearje jo as jo net sjogge dat de applikaasje net wurket?!"

1. Ik leau dat jo krekt moatte begjinne te kontrolearjen fanôf it yngongspunt fan 'e brûker. As de brûker net sjocht dat de applikaasje wurket, dat is it, it is in mislearring. En dêr moat it tafersjochsysteem earst foar warskôgje.
2. En pas dan kinne wy ​​de ynfrastruktuer kontrolearje. Of doch it parallel. It is makliker mei ynfrastruktuer - hjir kinne wy ​​einlings gewoan zabbix ynstallearje.
3. En no moatte jo nei de woartels fan 'e applikaasje gean om te begripen wêr't dingen net wurkje.

Myn haadgedachte is dat tafersjoch moat gean parallel mei it ûntwikkeling proses. As jo ​​it tafersjochteam ôfliede foar oare taken (meitsje CI / CD, sânboksen, reorganisaasje fan ynfrastruktuer), sil tafersjoch begjinne te bliuwen en jo kinne de ûntwikkeling noait ynhelje (of ier of letter moatte jo it stopje).

Alles troch nivo's

Sa sjoch ik de organisaasje fan in tafersjochsysteem.

1) Applikaasjenivo:

• tafersjoch op applikaasje saaklike logika;
• tafersjoch op sûnensmetriken fan tsjinsten;
• yntegraasje monitoring.

2) Ynfrastruktuernivo:

• monitoaring fan orkestraasjenivo;
• monitoring fan systeemsoftware;
• izer nivo monitoring.

3) Nochris it tapassingsnivo - mar as technysk produkt:

• sammelje en tafersjoch op applikaasje logs;
• APM;
• tracing.

4) Alarm:

• organisaasje fan in warskôgingssysteem;
• organisaasje fan in plicht systeem;
• organisaasje fan in "kennisbasis" en workflow foar ynsidint ferwurking.

wichtich: wy komme nei de warskôging net nei, mar daliks! D'r is gjin need om tafersjoch te starten en "op ien of oare manier letter" út te finen wa't warskôgings sil ûntfange. Ommers, wat is de taak fan tafersjoch: om te begripen wêr't yn it systeem wat ferkeard wurket, en de goeie minsken derfan witte te litten. As jo ​​​​dit oant it ein litte, dan sille de juste minsken witte dat der wat mis giet, allinich troch te roppen "neat wurket foar ús."

Applikaasje Layer - Business Logic Monitoring

Hjir prate wy oer it kontrolearjen fan it feit dat de applikaasje wurket foar de brûker.

Dit nivo moat dien wurde yn 'e ûntwikkelingsfaze. Bygelyks, wy hawwe in betingst Prometheus: it giet nei de tsjinner dy't docht de kontrôles, lûkt it einpunt, en it einpunt giet en kontrolearret de API.

Wannear't faak frege wurdt om de thússide te kontrolearjen om te soargjen dat de side wurket, jouwe programmeurs in handgreep dy't elke kear kin wurde lutsen as se moatte soargje dat de API wurket. En programmeurs op dit stuit noch nimme en skriuwe /api/test/helloworld
De ienige manier om te soargjen dat alles wurket? - Nee!

• It meitsjen fan sokke kontrôles is yn wêzen de taak fan ûntwikkelders. Ienheidstests moatte wurde skreaun troch de programmeurs dy't de koade skriuwe. Want as jo it lekke nei de admin, "Dude, hjir is in list mei API-protokollen foar alle 25 funksjes, kontrolearje asjebleaft alles!" - neat sil slagje.
• As jo ​​"hallo wrâld" printsje, sil gjinien ea witte dat de API moat en wurket. Elke API-feroaring moat liede ta in feroaring yn kontrôles.
• As jo ​​al sa'n probleem hawwe, stopje de funksjes en allocearje ûntwikkelders dy't dizze kontrôles sille skriuwe, of de ferliezen akseptearje, akseptearje dat neat wurdt kontrolearre en sil mislearje.

Technyske tips:

• Soargje derfoar dat jo in eksterne server organisearje om kontrôles te organisearjen - jo moatte der wis fan wêze dat jo projekt tagonklik is foar de bûtenwrâld.
• Organisearje kontrôles oer it heule API-protokol, net allinich yndividuele einpunten.
• Meitsje in prometheus-einpunt mei de testresultaten.

Applikaasjelaach - tafersjoch op sûnensmetriken

No hawwe wy it oer eksterne sûnensmetriken fan tsjinsten.

Wy besletten dat wy alle "hannels" fan 'e applikaasje kontrolearje mei eksterne kontrôles, dy't wy neame fan in ekstern tafersjochsysteem. Mar dit binne de "handgrepen" dy't de brûker "sjocht". Wy wolle der wis fan wêze dat ús tsjinsten sels wurkje. D'r is hjir in better ferhaal: K8s hat sûnenskontrôles, sadat op syn minst de "kubus" sels oertsjûge wurde kin dat de tsjinst wurket. Mar de helte fan 'e kontrôles dy't ik haw sjoen binne deselde print "hallo wrâld". Dy. Dus hy lûkt ien kear nei ynset, hy antwurde dat alles goed is - dat is alles. En de tsjinst, as it in eigen API leveret, hat in enoarm oantal yngongspunten foar deselde API, dy't ek kontrolearre wurde moat, om't wy wolle witte dat it wurket. En wy kontrolearje it al binnen.

Hoe kinne jo dit technysk korrekt útfiere: elke tsjinst bleatret in einpunt oer har hjoeddeistige prestaasjes, en yn 'e grafiken fan Grafana (as elke oare applikaasje) sjogge wy de status fan alle tsjinsten.

• Elke API-feroaring moat liede ta in feroaring yn kontrôles.
• Meitsje direkt in nije tsjinst mei sûnensmetriken.
• In behearder kin nei de ûntwikkelders komme en freegje "foegje my in pear funksjes ta, sadat ik alles begryp en ynformaasje oer dit tafoegje oan myn tafersjochsysteem." Mar ûntwikkelders antwurdzje normaal: "Wy sille twa wiken foar de frijlitting neat tafoegje."
  Lit de ûntwikkelingsmanagers witte dat der sokke ferliezen sille wêze, lit it management fan de ûntwikkelingsmanagers ek witte. Want as alles falt, sil immen noch belje en easkje om de "konstant fallende tsjinst" te kontrolearjen (c)
• Trouwens, allocearje ûntwikkelders om plugins te skriuwen foar Grafana - dit sil in goede help wêze foar admins.

Applikaasjelaach - Yntegraasjemonitoring

Yntegraasjemonitoring rjochtet him op it kontrolearjen fan kommunikaasje tusken bedriuwskrityske systemen.

Der binne bygelyks 15 tsjinsten dy't mei-inoar kommunisearje. Dit binne gjin aparte siden mear. Dy. wy kinne de tsjinst net op har eigen lûke, krije / helloworld en begripe dat de tsjinst rint. Om't de bestelwebtsjinst ynformaasje oer de bestelling nei de bus stjoere moat - fanút de bus, moat de magazijntsjinst dit berjocht krije en der fierder mei wurkje. En de tsjinst foar e-postdistribúsje moat dit op ien of oare manier fierder ferwurkje, ensfh.

Dêrtroch kinne wy ​​​​net begripe, pokken op elke yndividuele tsjinst, dat it allegear wurket. Om't wy in bepaalde bus hawwe wêrmei alles kommunisearret en ynteraksje.
Dêrom moat dizze faze it poadium markearje fan testen fan tsjinsten foar ynteraksje mei oare tsjinsten. It is ûnmooglik om kommunikaasjemonitoring te organisearjen troch de berjochtmakelaar te kontrolearjen. As d'r in tsjinst is dy't gegevens útjout en in tsjinst dy't it ûntfangt, by it kontrolearjen fan 'e brokker sille wy allinich gegevens sjen dy't fan kant nei kant fleane. Sels as wy it op ien of oare manier slagge om de ynteraksje fan dizze gegevens yntern te kontrolearjen - dat in bepaalde produsint de gegevens pleatst, immen it lêst, dizze stream bliuwt nei Kafka - sil dit ús noch gjin ynformaasje jaan as ien tsjinst it berjocht yn ien ferzje stjoerde , mar de oare tsjinst ferwachte dizze ferzje net en sloech it oer. Wy sille dit net witte, om't de tsjinsten ús sille fertelle dat alles wurket.

Wat ik advisearje te dwaan:

• Foar syngroane kommunikaasje: it einpunt makket oanfragen oan relatearre tsjinsten. Dy. wy nimme dit einpunt, lûke in skript yn 'e tsjinst, dy't nei alle punten giet en seit "Ik kin derhinne lûke, en dêr lûke, ik kin dêr lûke ..."
• Foar asynchrone kommunikaasje: ynkommende berjochten - it einpunt kontrolearret de bus foar testberjochten en toant de ferwurkingsstatus.
• Foar asynchrone kommunikaasje: útgeande berjochten - it einpunt stjoert testberjochten nei de bus.

Lykas gewoanlik bart: wy hawwe in tsjinst dy't gegevens yn 'e bus smyt. Wy komme nei dizze tsjinst en freegje jo om ús te fertellen oer har yntegraasje sûnens. En as de tsjinst earne fierder in berjocht moat produsearje (WebApp), dan sil it dit testberjocht produsearje. En as wy in tsjinst oan 'e kant fan' e OrderProcessing útfiere, pleatst it earst wat it ûnôfhinklik kin pleatse, en as d'r wat ôfhinklike dingen binne, dan lêst it in set testberjochten fan 'e bus, begrypt dat it se kin ferwurkje, rapportearje en , as it nedich is, post se fierder, en dêroer seit er - alles is ok, ik libje.

Hiel faak hearre wy de fraach "hoe kinne wy ​​dit testen op gefjochtsgegevens?" Bygelyks, wy prate oer deselde besteltsjinst. De bestelling stjoert berjochten nei it pakhús wêr't it guod ôfskreaun is: wy kinne dit net testen op gefjochtsgegevens, om't "myn guod wurdt ôfskreaun!" Oplossing: Plan dizze hiele test oan it begjin. Jo hawwe ek ienheidstests dy't spots meitsje. Dat, doch it op in djipper nivo wêr't jo in kommunikaasjekanaal hawwe dat de wurking fan it bedriuw net skea docht.

Ynfrastruktuer nivo

Ynfrastruktuermonitoring is iets dat al lang beskôge wurdt as it kontrolearjen fan sels.

• Ynfrastruktuermonitoring kin en moat wurde lansearre as in apart proses.
• Jo moatte net begjinne mei ynfrastruktuermonitoring op in rinnend projekt, sels as jo echt wolle. Dit is in pine foar alle devops. "Earst sil ik it kluster kontrolearje, ik sil de ynfrastruktuer kontrolearje" - d.w.s. Earst sil it kontrolearje wat hjirûnder leit, mar sil net yn 'e applikaasje gean. Om't de applikaasje in ûnbegryplik ding is foar devops. It waard útlekt oan him, en hy begrypt net hoe't it wurket. En hy begrypt de ynfrastruktuer en begjint dermei. Mar nee - jo moatte de applikaasje altyd earst kontrolearje.
• Gean net oerboard mei it oantal warskôgings. Sjoen de kompleksiteit fan moderne systemen fleane warskôgings konstant, en jo moatte op ien of oare manier libje mei dizze bondel warskôgings. En de oproppersoan, nei't se nei hûndert fan 'e folgjende warskôgings sjoen hat, sil beslute "Ik wol der net oan tinke." Alerts moatte allinich ynformearje oer krityske dingen.

Applikaasjenivo as saaklike ienheid

Wichtige punten:

• ELK. Dit is de yndustry standert. As jo ​​om ien of oare reden logs net aggregearje, begjin dan daliks te dwaan.
• APM. Eksterne APM's as in manier om applikaasjemonitoring fluch te sluten (NewRelic, BlackFire, Datadog). Jo kinne dit ding tydlik ynstallearje om op syn minst ien of oare manier te begripen wat der mei jo bart.
• Tracing. Yn tsientallen mikrotsjinsten moatte jo alles opspoare, om't it fersyk net mear op himsels libbet. It is heul lestich om letter ta te foegjen, dus it is better om fuortendaliks tracing yn ûntwikkeling te plannen - dit is it wurk en it nut fan 'e ûntwikkelders. As jo ​​​​it noch net hawwe ymplementearre, ymplementearje it dan! Sjoch Jaeger/Zipkin

Alert

• Organisaasje fan in notifikaasjesysteem: yn betingsten foar it kontrolearjen fan in protte dingen soe d'r in unifoarm systeem wêze moatte foar it ferstjoeren fan notifikaasjes. Jo kinne yn Grafana. Yn it Westen brûkt elkenien PagerDuty. Warskôgings moatte dúdlik wêze (bgl. wêr komme se wei...). En it is oan te rieden om te kontrolearjen dat notifikaasjes hielendal wurde ûntfongen
• Organisaasje fan in plichtsysteem: warskôgings moatte net nei elkenien stjoerd wurde (of elkenien sil reagearje yn in mannichte, of gjinien sil reagearje). Untwikkelders moatte ek oproppen wêze: wês wis dat jo ferantwurdlikensgebieten definiearje, dúdlike ynstruksjes meitsje en dêryn skriuwe wa't se op moandei en woansdei moatte belje, en wa't jo op tiisdei en freed moatte skilje (oars belje se sels net ien yn 'e gefal fan in grut probleem - se sille bang wêze om jo wekker te meitsjen of te fersteuren: minsken wolle oer it algemien net graach oare minsken belje en wekker meitsje, benammen nachts). En ferklearje dat it freegjen fan help gjin yndikator is fan inkompetinsje ("Ik freegje om help, dat betsjut dat ik in minne arbeider bin"), stimulearje fersiken om help.
• Organisaasje fan in "kennisbasis" en workflow foar ynsidintferwurking: foar elke serieuze ynsidint moat in post-mortem pland wurde, en as tydlike maatregel moatte aksjes wurde opnommen dy't it ynsidint oplosse. En meitsje it in praktyk dat werhelle warskôgings in sûnde binne; se moatte wurde fêstmakke yn koade of ynfrastruktuer wurk.

Technology stack

Litte wy ús foarstelle dat ús stapel as folget is:

• gegevenssammeling - Prometheus + Grafana;
• log analyze - ELK;
• foar APM of Tracing - Jaeger (Zipkin).

De kar fan opsjes is net kritysk. Want as jo oan it begjin begrepen hoe't jo it systeem kontrolearje en in plan opskriuwe, dan begjinne jo ark te kiezen foar jo easken. De fraach is wat jo keazen hawwe om yn it earste plak te kontrolearjen. Om't miskien it ark dat jo oan it begjin keazen hawwe, hielendal net past by jo easken.

In pear technyske punten dy't ik de lêste tiid oeral sjoch:

Prometheus wurdt binnen Kubernetes skood - wa kaam mei dit?! As jo ​​kluster crasht, wat sille jo dwaan? As jo ​​​​in komplekse kluster binnen hawwe, dan moat d'r in soarte fan tafersjochsysteem binnen it kluster wêze, en wat bûten, dat gegevens fan binnen it kluster sammelje.

Binnen it kluster sammelje wy logs en al it oare. Mar it tafersjochsysteem moat bûten wêze. Hiel faak, yn in kluster wêr't Promtheus yntern ynstalleare is, binne d'r ek systemen dy't eksterne kontrôles fan 'e operaasje fan' e side útfiere. Wat as jo ferbiningen mei de bûtenwrâld binne sakke en de applikaasje net wurket? It docht bliken dat alles goed is binnen, mar it makket dingen net makliker foar brûkers.

befinings

• Untwikkeling tafersjoch is net de ynstallaasje fan nutsbedriuwen, mar de ûntwikkeling fan in softwareprodukt. 98% fan de hjoeddeiske tafersjoch is kodearring. Kodearjen yn tsjinsten, kodearjen fan eksterne kontrôles, kontrolearje fan eksterne tsjinsten, en dat is alles.
• Fergrieme de tiid fan jo ûntwikkelders net oan tafersjoch: it kin oant 30% fan har wurk duorje, mar it is it wurdich.
• Devops, meitsje jo gjin soargen dat jo wat net kontrolearje kinne, om't guon dingen in folslein oare manier fan tinken binne. Jo wiene gjin programmeur, en tafersjochwurk is krekt harren wurk.
• As it projekt al rint en net kontrolearre (en do bist in manager), allocearje middels foar tafersjoch.
• As it produkt al yn produksje is, en jo binne in devops dy't waard ferteld om "kontrôle yn te stellen" - besykje it management út te lizzen wat ik dit alles oer skreau.

Dit is in útwreide ferzje fan it rapport op 'e Saint Highload ++ konferinsje.

As jo ​​​​ynteressearre binne yn myn ideeën en tinzen deroer en relatearre ûnderwerpen, dan kinne jo hjir lês it kanaal 🙂

Boarne: www.habr.com