Jälgimine ja monitooring Istios: mikroteenused ja ebakindluse printsiip

Heisenbergi ebamugavuse põhimõte ütleb, et ei saa samal ajal mõõta objekti asukohta ja selle kiirus. Kui objekt liigub, siis ei ole tal asukohta. Ja kui asukoht on olemas – siis tal ei ole kiirus.

Mis puudutab mikroteenuseid Red Hat OpenShift platvormil (ja Kubernetes'i juhtimisel), siis tänu avatud koodiga tarkvarale saavad nad samal ajal raporteerida nii oma jõudlust kui ka töökindlust. Heisenbergi ebamugavus jääb kehtima, kuid see kõrvaldab ebamugavuse pilve rakenduste kasutamisel. Istio võimaldab hõlpsasti korraldada nende rakenduste jälgimist ja monitooringut, et kõik oleks kontrolli all.

Määratleme terminoloogia

Alustama jälgimine (Tracing) me mõistame süsteemi tegevuse logimist. See kõlab üsna üldiselt, kuid tegelikult on siin üks peamisi reegleid andmete jälgimise suunamine sobivasse salvestusse, muretsemata nende vormingu pärast. Kõik andmete otsimise ja analüüsimise töö jääb nende tarbija õlgadele. Istios kasutatakse jälgimissüsteemi Jaeger, mis rakendab OpenTracing andmemudelit.

Jäljed (Traces, ja sõna „jäljed” kasutatakse siin tähenduses „märke”, nagu näiteks ballistika eksamineerimisel) nimetame me andmeid, mis kirjeldavad täielikult päringu või tööülesande läbimist, nagu öeldakse, „kõik alates ja kuni”. Näiteks kõik, mis juhtub hetkest, kui kasutaja vajutab nuppu veebilehel, kuni andmete tagastamise hetkeni, sealhulgas kõik kaasatud mikroteenused. Ühe jälje kohta võib öelda, et see kirjeldab (või modelleerib) päringu läbimist sinna ja tagasi. Jaegeri liideses jagunevad jäljed ajateljel koostisosadeks, just nagu ahelat võiks jagada eraldi lülideks. Ainult et lülide asemel koosneb jälg nn span'idest.

Span – see on ajavahemik tööde tegemise algusest kuni nende lõpetamiseni. Jätkates analoogiat, võib öelda, et iga span esindab eraldi lüli ketis. Span võib omada (või mitte omada) ühte või mitut alam span'i. Seetõttu on kõige kõrgema taseme span'il (root span) sama kogukestus nagu rada, millele see viitab.

Jälgimine – see on tegelikult teie süsteemi jälgimine – silmade kaudu, kasutajaliidese kaudu või automatiseerimise vahendite abil. Jälgimise aluseks on jälgimisandmed. Istios on jälgimine rakendatud Prometheuse vahenditega, millel on ka vastav kasutajaliides. Prometheus toetab automaatset jälgimist, kasutades teavitusi Alerts ja Alert Managers.

Jätame märgid

Ette, et jälgimine oleks võimalik, peab rakendus looma span'ide kogumi. Seejärel tuleb need eksportida Jaegerisse, et see omakorda looks jälgimise visuaalse esituse. Nende span'ide hulka kuuluvad muu hulgas operatsiooni nimi ning ajamärke selle alguse ja lõpu kohta. Span'ide edastamine toimub Jaegerile suunatud HTTP-päringute pealkirjade samuti sisse- ja väljaminevate päringute vahelise suunamise teel. Sõltuvalt kasutatavast programmeerimiskeelest võib see nõuda väikseid muudatusi rakenduste lähtekoodis. Allpool on näide Java koodist (kasutades Spring Boot raamistikku), mis lisab B3 (Zipkin-stiilis) pealkirjad teie päringule Springi konfigureerimisklassis:

Kasutatakse järgmisi pealkirja seadeid:

Kui kasutate Java't, siis koodi pole vaja muuta, piisab, kui lisada paar rida Maven POM-faili ning määrata keskkonnamuutujad. Siin on read, mida peate lisama POM.XML faili, et Jaeger Tracer Resolverit integreerida:

Ja vastavad keskkonnamuutujad määratakse Dockerfile'is:

Nüüd on kõik seadistatud, ja meie mikroteenused hakkavad genereerima jälgimisandmeid.

Vaatame üldiselt

Istio sisaldab lihtsat juhtpaneeli, mis on üles ehitatud Grafana põhjal. Kui kõik on seadistatud ja töötab Red Hat OpenShift PaaS platvormil (meie näites on Red Hat OpenShift ja Kubernetes paigaldatud minishiftile), käivitatakse see paneel järgmise käsuga:

ava "$(minishift openshift service grafana -u)/d/1/istio-dashboard?refresh=5⩝Id=1"

Grafana paneel võimaldab kiiresti hinnata süsteemi toimimist. Selle paneeli fragment on näidatud alloleval joonisel:

Siit on näha, et mikroteenus customer kutsub mikroteenust preference v1, mis omakorda kutsub mikroteenuseid recommendation v1 ja v2. Grafana paneelil on Dashboard Row plokk kõrgetasemeliste mõõdikute jaoks, nagu globaalne päringute maht (Global Request Volume), edukaid päringute osakaal (success rates) ja 4xx vead. Samuti on seal Server Mesh esitus diagrammide kujul iga teenuse kohta ja Services Row plokk, et vaadata üksikasjalikke andmeid iga konteineri kohta iga teenuse jaoks.

Nüüd uurime sügavamale

Korrektselt seadistatud Istio jälgimine võimaldab kohe süvitsi minna süsteemi sooritusvõime analüüsi. Jaegeri kasutajaliideses saab jälgimisi vaadata ning näha, kui kaugele ja sügavale need ulatuvad, samuti visuaalselt lokaliseerida sooritusvõime kitsaskohti. Red Hat OpenShift platvormil minishift käivitate Jaegeri kasutajaliidese järgmise käsu abil:

minishift openshift service jaeger-query --in-browser

Mida saab sellel ekraanipildil jälgimise kohta öelda:

• See jaguneb 7 span'iks.
• Kogu täitmise aeg on 6,99 ms.
• Mikrosüsteemil recommendation, mis on ahelas viimane, kulub 0,69 ms.

Sellised diagrammid aitavad kiiresti olukorda mõista, kui mõni üksik toimiv teenus mõjutab kogu süsteemi sooritusvõimet.

Nüüd teeme asja keerulisemaks ja käivitame kaks eksemplari mikroteenusest recommendation:v2 käsuga oc scale —replicas=2 deployment/recommendation-v2. Siin on, millised pod'id meil pärast seda on:

Kui nüüd tagasi Jaegeri peale lülituda ja soovituse teenuse span'i laiendada, näeme, millisele pod'ile päringud suunatakse. Nii suudame hõlpsasti lokaliseerida viivitused konkreetse pod'i tasemel. Vaadata tuleb node_id välja.

Kuhu ja kuidas kõik liigub

Nüüd liikume Prometheuse liidese poole ja üsna oodatult näeme seal, et päringud soovituse teenuse teise ja esimese versiooni vahel jagunevad suhe 2:1, rangelt tegutsevate pod'ide arvu alusel. Samuti muutub see diagramm dünaamiliselt pod'ide üles- ja allaskaalumisel, mis on eriti kasulik Canary täitmisel (me vaatame seda deployment'i skeemi järgmine kord lähemalt).

Kõik on alles algamas

Tegelikult oleme täna, nagu öeldakse, vaid kergelt puudutanud kasuliku teabe varasalve Jaegeri, Grafana ja Prometheuse kohta. Üldiselt oli see meie eesmärk – suunata teid õiges suunas ja avada Istio võimalusi.

Ja pidage meeles, et kõik see on juba integreeritud Istiosse. Teatud programmeerimiskeelte (näiteks Java) ja raamistike (nt Spring Boot) kasutamisel saab seda kõike rakendada, puudutamata rakenduste enda koodi. Jah, koodi tuleb veidi muuta, kui kasutate teisi keeli, peamiselt Nodejs või C#. Kuid kuna jälgitavus (loe: „lingitamine”) on usaldusväärsete pilvesüsteemide loomise üks kohustuslikke tingimusi, peate te igal juhul koodi muutma, olgu teil Istio või mitte. Miks siis mitte suunata oma jõupingutusi kasulikuma eesmärgi nimel?

Isegi selleks, et vastata küsimustele „kus?” ja „kui kiiresti?” 100% kindlalt.

Kaosinseneria Istios: nii see oli ette nähtud

Asjade purustamise oskus aitab tagada, et need ei puruneks

Tarkvara testimine on mitte ainult keeruline, vaid ka oluline. Samas on testimine, et kontrollida, kas funktsioon tagastab õige tulemuse, üks asi, aga testimine usaldusväärse võrgu tingimustes on hoopis teine ülesanne (tihti arvatakse, et võrk töötab alati tõrgeteta, ja see on esimene kaheksast eksitusest jaotatud arvutustes). Üks raskusi selle ülesande lahendamisel seisneb selles, kuidas simuleerida süsteemi rikkeid või sisestada neid tahtlikult, tehes nii nimetatud fault injection. Seda saab teha, muutes rakenduse algkoodi. Kuid siis testite te mitte oma algset koodi, vaid selle versiooni, mis simuleerib spetsiaalselt rikkeid. Tulemusena riskite sattuda surmavate fault injection'ite embustesse ja kokku puutuda geisenbug'idega – tõrgetega, mis kaovad katsetamisel, et neid avastada.

Ja nüüd näitame, kuidas Istio aitab neid raskusi lahendada kiirelt ja lihtsalt.

Nii see välja näeb, kui kõik on suurepäraselt

Kaalu järgmine stsenaarium: meil on kaks pod'i meie soovitusmikroteenuses, mille võtsime Istio õpikust. Üks pod on märgitud kui v1 ja teine kui v2. Nagu näeme, töötab kõik praegu suurepäraselt:

(Muide, paremal number on lihtsalt igas pod'is tehtud kõnede loend)

Aga me ei vaja tõepoolest seda, eks? Proovime siis kõik purustada, puudutamata algseid koode.

Teeme mikroteenusele katkestusi

Allpool on näidatud yaml-fail Istio marsruutimisreegli jaoks, mis pooltel juhtudel tekitab vea (veateate). serverid 503):

Pange tähele, et me kirjeldame selgelt, et pooltel juhtudel peab toimuma viga 503.

Nii näeb välja pildiscreenshot jooksutatud curl'i käsust pärast reegli aktiveerimist, et simuleerida katkestusi. Nagu näeme, tagastab pool päringutest veateate 503, sõltumata sellest, kas need suunatakse pod'ile v1 või v2:

Normaalse töö taastamiseks piisab reegli kustutamisest, meie puhul käsuga istioctl delete routerule recommendation-503 -n tutorial. Siin on Tutorial Red Hat OpenShift'i projekti nimi, kus meie Istio õpik töötab.

Lisame kunstlikud viivitused

Tehislikud 503 vead aitavad testida süsteemi taluvust riketeks, kuid võime prognoosida ja hallata viivitusi peaks teid veelgi rohkem hämmastama. Ja tegelikus elus esinevad viivitused sageli rohkem kui rikete probleemid. Aeglaselt töötav mikroteenus on mürgine, mis mõjutab kogu süsteemi. Istio abil saame testida koodi, mis käsitleb viivitusi, seda muudatusi tegemata. Alustuseks näitame, kuidas seda teha kunstlikult tekitatud võrgu viivituste korral.

Pange tähele, et sellise testimise järel võib teil olla vajadus (või soov) oma koodi täiendada. Hea uudis on see, et sellisel juhul tegutsete proaktiivselt, mitte reaktiivselt. Just nii peaks olema üles ehitatud arendustsükkel: kodeerimine-testeerimine-tagasiside-kodeerimine-testeerimine…

Nii näeb välja reegel, mis… Kuigi teadsite, mis? Istio on nii lihtne ja see yaml-fail on nii arusaadav, et kõik selles näites räägib ise enda eest, lihtsalt vaadake:

Pooles juhtudel on meil 7-sekundiline viivitus. See ei ole sama, nagu oleksime sisestanud algkoodis käsu sleep, kuna Istio viivitab päringu tegelikult 7 sekundiks. Kuna Istio toetab Jaegeri jälitamist, on see viivitus selgelt nähtav Jaegeri kasutajaliideses, nagu on näidatud alloleval ekraanipildil. Pange tähele, et paremas ülanurgas on pikk päring – selle kestus on 7,02 sekundit:

See stsenaarium võimaldab testida koodi võrgu viivituse tingimustes. On selge, et kui eemaldame selle reegli, eemaldame ka kunstliku viivituse. Kordame end, kuid me tegime kõik selle, puutumatult algkoodi.

Ärge tagasi astuge ja ärge alla andke

Teine kasulik funktsioon Istios, mis aitab kaosetehnoloogiate valdkonnas, on võimalus teha teenusele korduvaid päringuid antud arvu kordi. Idee on see, et me ei katkestaks katseid, kui esimene päring lõppeb veaga 503 – ja võib-olla, N-ndal korral õnnestub meil. Võib-olla on teenus lihtsalt mõneks ajaks puhkusele läinud. Jah, see põhjus tuleks kindlasti välja selgitada ja kõrvaldada. Aga see on hiljem, praegu proovime süsteemi töös hoida.

Nii et me tahame, et teenus aeg-ajalt väljastaks vea 503, ja Istio püüab sellele järgnevalt uuesti ühendust võtta. Siinkohal on kindlasti vaja viisi genereerida viga 503, muutmata koodi ise…

Peatu, oota! Me just tegime seda.

See fail muudab nii, et teenus recommendation-v2 väljastab pooled korrad vea 503:

Ilmselgelt osa päringutest lõppeb ebaõnnestumisega:

Nüüd rakendame Istio retry funktsiooni:

See marsruutingureegel teeb kolm kordust kahe sekundi intervalliga ja peaks vähendama (ideaalis täiesti kõrvaldama) vea 503:

Kokkuvõtteks küsime: kuidas Istio, kõigepealt, genereerib 503 viga poolele päringutele. Ja teiseks, sama Istio teeb kolm katset, et uuesti ühendust võtta teenusega 503 vea ilmnemisel. Tulemuseks töötab kõik suurepäraselt. Seega, kasutades Retry funktsiooni, täitsime oma lubaduse mitte alla anda.

Ja jah, me tegime seda taas, puudutamata koodi. Kõik, mis meil vaja oli, oli kaks Istio marsruutimise reeglit:

Kuidas mitte kasutajat alt vedada või seitsmeühe ootamine

Ja nüüd keerame olukorra tagurpidi ja vaatame stsenaariumi, kus mitte alla anda on õigustatud ainult määratud ajavahemiku jooksul. Ja siis tuleb lihtsalt katsetest loobuda, et mitte sundida kõiki ootama ühte aeglast teenust. Teisisõnu, me ei kaitse kaduma läinud positsiooni, vaid taganeme varupositsioonile, et mitte kasutajat petta ja mitte sundida teda teadmatuses vaevlema.

Istios on võimalik seada päringu täitmise ajapiirang. Kui teenus ületab selle ajapiirangu, tagastatakse viga 504 (Gateway Timeout) – kõik see toimub taas läbi Istio konfiguratsiooni. Kuid meil tuleb lisada teenuse lähtekoodi käsk sleep (ja seejärel loomulikult teha rebuild ja redeploy), et simuleerida teenuse aeglast tööd. Kahjuks muidu ei õnnestu.

Nii et me lisasime teenuse recommendation v2 koodis kolmese kunduses sleep, rekonstrueerisime vastava pildi ja tegime konteineri rediplomatise, nüüd lisame ajapiirangu järgmise Istio marsruutimise reegli kaudu:

Ülaltoodud ekraanipildilt on näha, et katkestame katse ühendust võtta teenusega recommendation, kui me ei saa vastust ühe sekundi jooksul, st isegi enne, kui 504 viga esineb. Pärast selle marsruutimise reegli rakendamist (ja kolme sekundi sleep'i lisamist teenuse recommendation:v2 koodi) saame järgmist:

Korrame jälle, kuid ajapiirangut saab seadistada, puudutamata lähtekoodi. Täiendav boonus on see, et nüüd saate oma koodi muuta nii, et see reageerib ajapiirangule, ja hõlpsasti testida neid muudatusi Istio abil.

Ja nüüd kõik koos

Isto'ga kaose toomis on suurepärane viis katsetada oma koodi ja kogu süsteemi usaldusväärsust. Tagasilöögimallid, bulkhead ja circuit breaker, kunstlike rike ja viivitusmehhanismid, samuti uuesti kutsumised ja ajaülemised on äärmiselt kasulikud usaldusväärsete pilvesüsteemide loomisel. Koos Kubernetes'i ja Red Hat OpenShift'iga aitavad need tööriistad tulevikku kindlalt siseneda.

Allikas: habr.com