Traceroute ja jälgimine Istios: mikroteenused ja ebakindluse põhimõte

Heisenbergi ebamugavuse printsiip ütleb, et ei saa samaaegselt mõõta objekti asukohta ja selle kiirus. Kui objekt liigub, pole tal asukohta. Kui asukoht on olemas – tähendab, et tal pole kiirus.

Mis puudutab mikroteenuseid Red Hat OpenShifti (ja Kubernetes'i) platvormil, siis tänu sobivale avatud lähtekoodiga tarkvarale saavad nad samal ajal edastada teavet oma jõudluse ja toimivuse kohta. See ei vaidlusta vanameest Heisenbergi, kuid kaotab ebamugavuse pilve rakenduste haldamisel. Istio võimaldab hõlpsasti korraldada selliste rakenduste jälgimist ja monitooringut, et kõik püsiks kontrolli all.

Määratleme terminoloogia

Pod jälgimine Jälgimise (Tracing) all mõistame süsteemi tegevuse logimist. See kõlab üsna üldiselt, kuid tõeliselt üks olulisemaid reegleid on siin visata jälgimisandmed vastavasse salvestusruumi, ilma et oleks vaja nende vormindamisega muretseda. Ning kogu andmete otsimise ja analüüsi töö lasub nende tarbija õlul. Istios kasutatakse jälgimissüsteemi Jaeger, mis rakendab OpenTracing'i andmemudelit.

Jälgedeks Jälgedeks (Traces, ja sõna "jäljed" kasutatakse siin tähenduses "märgid", nagu näiteks ballistilise ekspertiisi puhul) nimetame andmeid, mis kirjeldavad täielikult päringu või tööülesande kulgemist, nagu öeldakse, "algusest lõpuni". Näiteks kõik, mis toimub hetkel, kui kasutaja vajutab nuppu veebilehel, ja kuni andmete tagastamiseni, sealhulgas kõik kaasatud mikroteenused. Üks jälg kirjeldab täielikult (või mudeldab) päringu kulgemist edasi-tagasi. Jaegeri liideses jagunevad jäljed ajakava järgi nagu ahel, mida saab jagada eraldi lüli. Ainult selle asemel, et lülid oleksid ahelas, koosneb jälg nn span'idest.

Span – see on intervall tööülesande algusest kuni selle lõpuni. Jätkates analoogiat, võib öelda, et iga span on eraldi ahela lüli. Span'il võib olla (või mitte olla) üks või mitu alam-spani. Seega on kõige ülemise taseme span (root span) sama üldine kestus nagu jälg, millele see kuulub.

Jälgimine – see, this is the actual observation of your system – through the eyes, via the UI or through automation tools. The basis of monitoring lies in tracing data. In Istio, monitoring is implemented using Prometheus and has the corresponding UI. Prometheus supports automatic monitoring with alert notifications and Alert Managers.

We keep score

To enable tracing, the application must create a collection of spans. They then need to be exported to Jaeger so it can create a visual representation of the trace. Among other things, these spans label the name of the operation, as well as timestamp markers for its start and end. The transmission of spans is carried out by redirecting the HTTP request headers meant for Jaeger from incoming requests to outgoing requests. Depending on the programming language used, this may require slight modifications to the application's source code. Below is an example of Java code (using the Spring Boot framework) that adds B3 (Zipkin-style) headers to your request in the Spring configuration class:

The following header settings are used:

If you are using Java, you can leave the code unchanged and simply add a few lines to the Maven POM file and set environment variables. Here are the lines to add to the POM.XML file to integrate the Jaeger Tracer Resolver:

And the corresponding environment variables are set in the Dockerfile:

That's it, everything is set up now, and our microservices will start generating trace data.

Taking a general look

Istio includes a simple control panel based on Grafana. Once everything is configured and running on the Red Hat OpenShift PaaS platform (in our example, Red Hat OpenShift and Kubernetes are deployed on minishift), this panel can be launched with the following command:

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

The Grafana panel allows for a quick assessment of the system's performance. A snippet of this panel is shown in the picture below:

Siit on näha, et klienditeeninduse mikroteenus kutsub välja eelistuste mikroteenuse versioon 1, mis omakorda kutsub välja soovituste mikroteenuseid versioon 1 ja 2. Grafana armatuurlaud sisaldab Dashboard Row plokki kõrgetasemeliste mõõdikute jaoks, nagu globaalne päringute maht, eduka päringu osakaal, 4xx vead. Lisaks on seal Server Mesh esitus, kus on graafikud iga teenuse jaoks ja Services Row plokk, et vaadata üksikasjalikke andmeid iga konteineri kohta igas teenuses.

Nüüd kaevame sügavamale

Korralikult seadistatud Istio jälgimine võimaldab otse välja võtta süsteemi jõudluse analüüs. Jaegeri kasutajaliideses saab jälgimisi vaadata ja näha, kui kaugele ja sügavale need ulatuvad, samuti visuaalselt tuvastada jõudluse kitsaskohti. Kui kasutada Red Hat OpenShift platvormil minishift, käivitatakse Jaegeri kasutajaliides järgmise käsuga:

minishift openshift service jaeger-query --in-browser

Mida saab sellel ekraanil jälgimise kohta öelda:

• See jaguneb 7 span'iks.
• Kogu töötlusaeg on 6.99 ms.
• Mikroteenusele soovitus, mis on ahela viimane, kulub 0.69 ms.

Selle tüüpi diagrammid aitavad kiiresti mõista olukorda, kui mõni vähem oluline teenus mõjutab kogu süsteemi jõudlust.

Nüüd keerame ülesande keerukamaks ja käivitame kaks eksemplari mikroteenust soovitus:v2 käsuga oc scale —replicas=2 deployment/recommendation-v2. Siin on, millised pod'id pärast seda meil on:

Kui nüüd lülituda tagasi Jaegerisse ja avada soovituste teenuse span, näeme, kuhu pod'id jagunevad. Nii saame hõlpsasti tuvastada tõrkeid konkreetse pod'i tasemel. Selleks tuleb vaadata node_id välja:

Kuhu ja kuidas kõik liigub

Nüüd liigume Prometheuse liidesesse ja ootuspäraselt näeme seal, et päringud teise ja esimese versiooni vahel jagunevad suhtega 2:1, rangelt vastavalt töökindlate pod'ide arvule. Lisaks muutub see graafik dünaamiliselt, kui pod'e üles-alla skaleerida, mis on eriti kasulik Canary Deployment'i puhul (me vaatame selle rakendusskeemi lähemalt järgmine kord).

Kõik on alles alguses

Tegelikult puudutasime täna vaid kergelt Jaegeri, Grafana ja Prometheuse väärtuslikku teavet. See oli meie eesmärk – suunata teid õigesse suunda ja avada Istio perspektiive.

Ja pidage meeles, et see kõik on juba Istios sisse ehitatud. Teatud programmeerimiskeelte (nt Java) ja raamistike (nt Spring Boot) kasutamisel saab kõik selle realiseerida, puutumata rakenduste koodi. Jah, koodi tuleb veidi kohandada, kui kasutate teisi keeli, eelkõige Nodejs või C#. Kuid kuna jälgitavus (loe: "tracing") on usaldusväärsete pilvesüsteemide loomise üks peamisi tingimusi, peate koodi igal juhul muutma, olgu teil Istio või mitte. Miks mitte investeerida oma pingutusi tugevamalt?

Kasvõi selleks, et alati vastata küsimustele "kus?" ja "kui kiiresti?" 100% kindlusega.

Kaosetehnika Istios: see oli nii kavandatud

Asjade purustamise oskus aitab tagada, et need ei puruneks

Tarkvara testimine ei ole mitte ainult keeruline, vaid ka oluline. Samas on korrektsete testide (nt kas funktsioon tagastab õige tulemuse) tegemine üks asi, aga testi tegemine ebastabiilses võrgus on hoopis teine ülesanne (tihti arvatakse, et võrk töötab alati tõrgeteta, ja see on esimene kaheksast valeideest jaotatud arvutuste kohta). Üks selle ülesande keerukustest seisneb selles, kuidas süsteemis tõrkeid simuleerida või neid tahtlikult põhjustada, tehes nn fault injection'i. Seda saab teha rakenduse algkoodi modifitseerimise teel. Kuid siis testite mitte oma algset koodi, vaid selle versiooni, mis simuleerib tõrkeid. Tulemuseks on risk sattuda fault injection'i surmavatesse embustesse ja silmitsi seista geizenbug'idega – tõrked, mis kaovad katsetamise katsete ajal.

Ja nüüd näitame, kuidas Istio aitab nendest raskustest hõlpsasti üle saada.

Kuidas kõik välja näeb, kui kõik on suurepärane

Vaatame järgmist stsenaariumi: meil on kaks pod'i meie soovituste mikroteenusele, mille võtsime Istio õpikust. Üks pod on tähistatud kui v1 ja teine kui v2. Nagu näeme, töötab kõik praegu suurepäraselt:

(Muide, number paremal – see on lihtsalt iga pod'i kõnede loendur)

Aga me ei vaja tegelikult seda, eks? Proovime kõik purustada, puudutamata allika koodi.

Teeme mikroteenuse töö katkestusi

Allpool on yaml-fail Istio marsruutimisse reegli kohta, mis katkub pooled korrad (vea) serverilt 503):

Pange tähele, et oleme selgelt määranud, et pooled korrad peab tagastama vea 503.

Nii näeb välja ekraanipilt tsükli käivitamisel curl käsust pärast reegli aktiveerimist, et simuleerida katkestusi. Nagu näeme, tagastab pool päringutest vea 503, olenemata sellest, millisele pod'ile – v1 või v2 – need saadetakse:

Tavapärase töö taastamiseks piisab reegli eemaldamisest, meie puhul käsuga istioctl delete routerule recommendation-503 -n tutorial. Siin Tutorial on Red Hat OpenShift'i projekti nimi, kus meie Istio õpetus toimub.

Toome sisse kunstlikud viivitused

Kunstlikud vead 503 aitavad testida süsteemi tõrgetele vastupidavust, kuid võime ennustada ja töödelda viivitusi peaks teid veelgi enam muljet avaldama. Ja tegelikus elus juhtuvad viivitused sageli rohkem kui tõrked. Aeglaselt töötav mikroteenus on mürk, millest kannatab kogu süsteem. Istio abil saab testida viivituste töötlemise koodi, muutes seda samal ajal mitte. Alustame näitamisega, kuidas seda teha kunstlikult sisse toodud võrgu viivituste korral.

Pange tähele, et pärast sellist testimist võib teil olla vajadus (või soov) oma koodi täiustada. Hea uudis on see, et sel juhul tegutsete proaktiivselt, mitte reaktiivselt. Just nii peaks arengutsükkel välja nägema: kodeerimine-testimine-tagasiside-kodeerimine-testimine…

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

Pooles juhtudel tekib meil 7-sekundiline viivitus. Ja see ei ole võrreldav sellega, kui me lisaksime lähtekoodi käsu sleep, sest Istio viivitab päringu tõeliselt 7 sekundiks. Kuna Istio toetab Jaegeri jälgimist, on see viivitus hästi nähtav Jaegeri kasutajaliideses, nagu on näidatud alloleval ekraanipildil. Pöörake tähelepanu pika päringu põhja paremas servas – selle kestus on 7,02 sekundit:

See stsenaarium võimaldab testida koodi võrgu viivituste tingimustes. Ja on selge, et kui me selle reegli eemaldame, kaotame me kunstliku viivituse. Korrame, et oleme kõik selle teinud, mitte puutudes lähtekoodi.

Ära tagane ega anna alla

Teine kasulik funktsioon Istios, mis puudutab kaose inseneritete, on teenusele korduvad päringud määratud arvu kordi. Idee on selles, et me ei peata katseid, kui esimene päring lõppeb veaga 503 – ja siis, võib-olla, N-ndal korral me õnnestume. Võib-olla on teenus lihtsalt mingil põhjusel ühtäkki madalal. Jah, selle põhjuse tuleks välja leida ja kõrvaldada. Kuid see on hiljem, nüüd proovime teha nii, et süsteem jätkab tööd.

Nii et tahame, et teenus aeg-ajalt annaks vea 503, ja Istio proovib seejärel selle ühenduse loomist. Siin on ilmne vajadus genereerida viga 503, puutumatult koodi...

Peatu, oota! Me tegime just seda.

See fail muudab nii, et teenus recommendation-v2 annab pooled juhtudest vea 503:

On ilmne, et osa päringutest lõppeb ebaõnnestumisega:

Ja nüüd rakendame Istio Retry-funktsiooni:

See marsruutimisreegel teeb kolm kordust kahe sekundi intervalliga ja peaks vähendama (ja ideaalis täielikult kõrvaldama) vead 503:

Kokkuvõttes oleme teinud nii, et Istio, kõigepealt, genereerib vea 503 pooltele päringutele. Teiseks, sama Istio teeb kolme katset teenusega uuesti ühenduse loomise korral vea 503 esinedes. Tulemus on lihtsalt suurepärane. Nii et kasutades Retry-funktsiooni, täitsime oma lubaduse mitte taganeda ega alla anda.

Ja jah, me tegime seda jälle, täiesti puutumatult koodi. Kõik, mida me vajasime, olid kaks Istio marsruurimisreeglit:

Kuidas kasutaja mitte petta või seitse ühte ei oota

Ja nüüd keerame olukorra pea peale ja vaatame stsenaariumi, kus mitte taganeda ja mitte alla anda tasub ainult mingil kindlal ajal. Ja siis tuleb lihtsalt lõpetada katseid päringu töötlemiseks, et mitte sundida kõiki ootama mingit ühte pidurdavat teenust. Teisisõnu, me ei kaitse kaotatud positsiooni, vaid loovume tagavaraliinile, et mitte petta veebisaidi kasutajat ja mitte sundida teda teadmatuses viibima.

Istios saab seada päringu töötlemise ajaületuse. Kui teenus ületab selle aja, tagastatakse viga 504 (Gateway Timeout) – see kõik toimub jälle Istio konfiguratsiooni kaudu. Kuid me peame teenuse lähtekoodi lisama käsu sleep (ja seejärel loomulikult täitma rebuild ja redeploy), et simuleerida teenuse aeglast tööd. Kahjuks muud moodi ei saa.

Nii et me lisasime kolmesekundilise sleep käsu soovitus teenuse koodis v2, koostasime vastava pildi ümber ja tegime konteineri redeploy, nüüd lisame aegumise järgmise Istio suunamisreegliga:

Eelmisel ekraanipildil on näha, et me loobume katsetest ühendust võtta soovitus teenusega, kui me ei saa vastust ühe sekundi jooksul, st enne, kui ilmneb viga 504. Pärast selle suunamisreegli rakendamist (ja kolme sekundi sleep'i lisamist soovitus teenuse koodi v2), saame järgmise tulemuse:

Korratakse, aga aega saab seada, puudutamata lähtekoodi. Ja siin on veel üks boonus, et nüüd saate oma koodi kohandada nii, et see reageeriks ajaületusele, ja lihtsalt testida seda täiustamist Istio abil.

Ja nüüd kõik koos

Veidi kaose tekitamine Istio abil on suurepärane viis oma koodi ja süsteemi usaldusväärsuse testimiseks. Tagasirikka, bulkhead ja circuit breaker mudelid, kunstlike riketeni ja viivitusteni viimise mehhanismid, samuti uuesti kutsed ja aegumised on väga kasulikud talitlushäiretega pilvesüsteemide loomiseks. Koos Kubernetes'e ja Red Hat OpenShift'iga aitavad need tööriistad kindlalt tulevikku vastu võtta.

Allikas: habr.com