Heizenberga nenoteiktības princips nosaka, ka jūs nevarat izmērīt objekta pozīciju un tā ātrumu vienlaikus. Ja objekts pārvietojas, tam nav vietas. Un, ja ir vieta, tas nozīmē, ka tai nav ātruma.
Kas attiecas uz mikropakalpojumiem Red Hat OpenShift platformā (un ar Kubernetes darbību), pateicoties atbilstošai atvērtā pirmkoda programmatūrai, tie var vienlaikus ziņot gan par veiktspēju, gan par stāvokli. Tas, protams, neatspēko veco Heisenbergu, taču novērš nenoteiktību, strādājot ar mākoņa lietojumprogrammām. Istio ļauj viegli izsekot un pārraudzīt šīs lietojumprogrammas, lai viss būtu kontrolēts.
Lēmumu pieņemšana par terminoloģiju
Saskaņā ar izsekošana (Izsekošana) mēs saprotam sistēmas darbību reģistrēšanu. Tas izklausās diezgan vispārīgi, taču patiesībā viens no pamatnoteikumiem šeit ir izsekošanas datu ievietošana atbilstošajā krātuvē, neuztraucoties par to formatēšanu. Un viss datu meklēšanas un analīzes darbs gulstas uz patērētāju. Istio izmanto Jaeger izsekošanas sistēmu, kas ievieš OpenTracing datu modeli.
Uz takām (Pēdas, un vārds "traces" šeit tiek lietots "pēdas" nozīmē, piemēram, ballistiskajā pārbaudē) mēs sauksim datus, kas pilnībā apraksta pieprasījuma vai darba vienības gaitu, kā saka, "no un līdz." Piemēram, viss, kas notiek no brīža, kad lietotājs noklikšķina uz pogas tīmekļa lapā, līdz tiek atgriezti dati, ieskaitot visus iesaistītos mikropakalpojumus. Var teikt, ka viena pēda pilnībā apraksta (vai modelē) pieprasījuma ceļojumu turp un atpakaļ. Jaeger saskarnē pēdas tiek sadalītas komponentos gar laika asi, līdzīgi kā ķēdi var sadalīt atsevišķās saitēs. Tikai saišu vietā trase sastāv no tā sauktajiem laidumiem.
Sprīdis ir intervāls no darba vienības sākuma līdz tās pabeigšanai. Turpinot analoģiju, mēs varam teikt, ka katrs laidums apzīmē atsevišķu ķēdes posmu. Laipumam var būt (vai var nebūt) viens vai vairāki pakārtotie diapazoni. Rezultātā augstākajam laidumam (saknes laidumam) būs tāds pats kopējais ilgums kā pēdai, kurai tā pieder.
Uzraudzība - patiesībā tas ir jūsu sistēmas novērojums - ar acīm, izmantojot lietotāja interfeisu vai automatizācijas rīkus. Uzraudzība balstās uz izsekošanas datiem. Istio uzraudzība tiek īstenota, izmantojot Prometheus, un tai ir atbilstošs lietotāja interfeiss. Prometheus atbalsta automatizētu uzraudzību, izmantojot brīdinājumus un brīdinājumu pārvaldniekus.
Mēs atstājam zīmes
Lai izsekošana būtu iespējama, lietojumprogrammai ir jāizveido laidumu kolekcija. Pēc tam tie ir jāeksportē uz Jaeger, lai tas savukārt izveidotu pēdas vizuālu attēlojumu. Cita starpā šie diapazoni iezīmē darbības nosaukumu, kā arī tās sākuma un beigu laikspiedolu. Laipumu pārsūtīšana tiek veikta, pārsūtot Jaeger specifiskās HTTP pieprasījumu galvenes no ienākošajiem pieprasījumiem uz izejošajiem pieprasījumiem. Atkarībā no izmantotās programmēšanas valodas var būt nepieciešamas nelielas izmaiņas lietojumprogrammas pirmkodā. Tālāk ir sniegts Java koda paraugs (izmantojot Spring Boot sistēmu), kas pievieno B3 (Zipkin stila) galvenes jūsu pieprasījumam Spring konfigurācijas klasē:
Tiek izmantoti šādi galvenes iestatījumi:
Ja izmantojat Java, varat atstāt kodu vienu un vienkārši pievienot dažas rindiņas Maven POM failam un iestatīt vides mainīgos. Tālāk ir norādītas rindiņas, kas jāpievieno savam POM.XML failam, lai ieviestu Jaeger Tracer Resolver:
Un attiecīgie vides mainīgie ir iestatīti Dockerfile:
Tas ir viss, tagad viss ir konfigurēts, un mūsu mikropakalpojumi sāks ģenerēt izsekošanas datus.
Paskatīsimies vispārīgi
Istio ietver vienkāršu vadības paneli, kura pamatā ir Grafana. Kad viss ir konfigurēts un darbojas Red Hat OpenShift PaaS platformā (mūsu piemērā Red Hat OpenShift un Kubernetes ir izvietoti minishift), šis panelis tiek palaists ar šādu komandu:
open "$(minishift openshift service grafana -u)/d/1/istio-dashboard?refresh=5⩝Id=1"
Grafana panelis ļauj ātri novērtēt sistēmas veiktspēju. Šī paneļa fragments ir parādīts attēlā zemāk:
Šeit var redzēt, ka klienta mikropakalpojums izsauc preferenci v1 mikropakalpojumu, kas savukārt izsauc ieteikumu v1 un v2 mikropakalpojumi. Grafana panelī ir informācijas paneļa rindas bloks augsta līmeņa metrikai, piemēram, kopējam pieprasījumu skaitam (Global Request Volume), veiksmes rādītājiem, 4xx kļūdām. Turklāt ir servera tīkla skats ar grafikiem katram pakalpojumam un pakalpojumu rindas bloks, lai skatītu detalizētu informāciju par katru konteineru katram pakalpojumam.
Tagad raksimies dziļāk
Izmantojot pareizi konfigurētu izsekošanu, Istio, kā saka, jau no kastes ļauj jums iedziļināties sistēmas veiktspējas analīzē. Jaeger lietotāja saskarnē varat skatīt pēdas un redzēt, cik tālu un dziļi tās sniedzas, kā arī vizuāli lokalizēt veiktspējas vājās vietas. Izmantojot Red Hat OpenShift minishift platformā, palaidiet Jaeger UI ar šādu komandu:
minishift openshift service jaeger-query --in-browser
Ko jūs varat teikt par izsekošanu šajā ekrānā:
- Tas ir sadalīts 7 laidumos.
- Kopējais izpildes laiks ir 6.99 ms.
- Ieteikuma mikropakalpojums, kas ir pēdējais ķēdē, pavada 0.69 ms.
Šāda veida diagrammas ļauj ātri izprast situāciju, kad viena slikti funkcionējoša servisa dēļ cieš visas sistēmas veiktspēja.
Tagad sarežģīsim uzdevumu un palaidīsim divus ieteikuma gadījumus: v2 mikropakalpojums ar komandu oc skalu —replicas=2 deployment/recommendation-v2. Tālāk ir norādīti pāksti, kas mums būs pēc tam:
Ja tagad pārslēgsimies atpakaļ uz Jaeger un paplašināsim ieteikumu pakalpojuma diapazonu, mēs varēsim redzēt, uz kuru podziņu tiek novirzīti pieprasījumi. Tādējādi mēs varam viegli lokalizēt bremzes konkrētas podas līmenī. Šajā gadījumā jums ir jāaplūko lauks node_id:
Kur un kā viss notiek
Tagad mēs ejam uz Prometheus interfeisu un diezgan paredzami tur redzam, ka pieprasījumi starp otro un pirmo ieteikumu pakalpojuma versiju tiek sadalīti proporcijā 2: 1, stingri atbilstoši strādājošo podiņu skaitam. Turklāt šī diagramma dinamiski mainīsies, kad podi palielinās un samazinās, kas būs īpaši noderīgi Canary Deployment (šo izvietošanas shēmu mēs apskatīsim tuvāk nākamreiz).
Tas ir tikai sākums
Patiesībā šodien mēs, kā saka, esam tikai saskrāpējuši daudz noderīgas informācijas par Jēgeru, Grafānu un Prometeju. Kopumā tāds bija mūsu mērķis – norādīt jums pareizo virzienu un pavērt Istio izredzes.
Un atcerieties, ka tas viss jau ir iebūvēts Istio. Izmantojot noteiktas programmēšanas valodas (piemēram, Java) un ietvarus (piemēram, Spring Boot), to visu var īstenot, nepieskaroties pašam lietojumprogrammas kodam. Jā, kods būs nedaudz jāmaina, ja izmantojat citas valodas, kas galvenokārt nozīmē Nodejs vai C#. Bet, tā kā izsekojamība (lasīt: “izsekošana”) ir viens no priekšnosacījumiem uzticamu mākoņsistēmu izveidei, jums tik un tā būs jārediģē kods neatkarīgi no tā, vai jums ir Istio vai ne. Tātad, kāpēc gan neizmantot savus centienus labāk?
Vismaz, lai vienmēr atbildētu uz jautājumiem “kur?” un "cik ātri?" ar 100% pārliecību.
Haosa inženierija Istio: tā tas bija paredzēts
Spēja salauzt lietas palīdz novērst to saplūšanu.
Programmatūras testēšana ir ne tikai sarežģīta, bet arī svarīga. Tajā pašā laikā pareizības pārbaude (piemēram, vai funkcija atgriež pareizo rezultātu) ir viena lieta, bet testēšana neuzticamā tīklā ir pavisam cits uzdevums (bieži tiek pieņemts, ka tīkls vienmēr darbojas bez kļūmēm, un tas ir pirmais no astoņiem nepareiziem priekšstatiem par sadalītajiem aprēķiniem). Viena no grūtībām šīs problēmas risināšanā ir, kā simulēt atteices sistēmā vai ieviest tās apzināti, veicot tā saukto defektu injekciju. To var izdarīt, modificējot pašas lietojumprogrammas pirmkodu. Bet tad jūs vairs nepārbaudīsit savu sākotnējo kodu, bet gan tā versiju, kas īpaši simulē kļūmes. Rezultātā jūs riskējat iekrist kļūdu ievadīšanas nāvējošā apskāvienā un saskarties ar Heisenbugs — kļūmēm, kas pazūd, mēģinot tās atklāt.
Tagad mēs jums parādīsim, kā Istio palīdz jums tikt galā ar šīm sarežģītībām vienā gabalā.
Kā viss izskatās, kad viss ir lieliski?
Apsveriet šādu scenāriju: mūsu ieteikumu mikropakalpojumam ir divi podi, kurus mēs paņēmām no Istio apmācības. Viens aplikums ir apzīmēts ar v1, bet otrs ir apzīmēts ar v2. Kā redzat, līdz šim viss darbojas labi:
(Starp citu, labajā pusē esošais numurs ir tikai zvanu skaitītājs katram podam)
Bet tas nav tas, kas mums vajadzīgs, vai ne? Nu, mēģināsim visu izjaukt, nemaz nepieskaroties pirmkodam.
Kārtojam pārtraukumus mikropakalpojuma darbībā
Zemāk ir redzams Istio maršrutēšanas noteikuma yaml fails, kas pusē gadījumu neizdodas (rada kļūdu). serveris 503):
Lūdzu, ņemiet vērā, ka mēs skaidri norādām, ka pusē gadījumu ir jāatgriež kļūda 503.
Lūk, kā izskatīsies ekrānuzņēmums, kurā redzama cirtināšanas komanda, kas darbojas cilpā, kad mēs aktivizēsim šo noteikumu, lai simulētu kļūdas. Kā redzat, puse no pieprasījumiem atgriež kļūdu 503 neatkarīgi no tā, uz kuru aplikāciju — v1 vai v2 — tie tiek nosūtīti:
Lai atjaunotu normālu darbību, pietiek ar šī noteikuma dzēšanu, mūsu gadījumā ar apmācības komandu istioctl delete routerule ieteikumu-503 -n. Šeit apmācība ir Red Hat OpenShift projekta nosaukums, kas vada mūsu Istio apmācību.
Mākslīgās kavēšanās ieviešana
Viltus 503 kļūdas palīdz pārbaudīt sistēmas noturību pret kļūmēm, taču spējai paredzēt un apstrādāt aizkaves vajadzētu jūs iespaidot vēl vairāk. Un kavēšanās reālajā dzīvē notiek biežāk nekā neveiksmes. Lēns mikropakalpojums ir inde, kas ietekmē visu sistēmu. Izmantojot Istio, varat pārbaudīt ar aizkavi saistīto kodu, to nekādā veidā nemainot. Pirmkārt, mēs parādīsim, kā to izdarīt mākslīgi ieviestas tīkla aizkaves gadījumā.
Lūdzu, ņemiet vērā, ka pēc šādas pārbaudes jums var būt nepieciešams (vai vēlaties) pielāgot savu kodu. Labā ziņa ir tāda, ka šajā gadījumā jūs būsiet proaktīvs, nevis reaģējošs. Tieši tā ir jāstrukturē izstrādes cikls: kodēšana-testēšana-atgriezeniskā saite-kodēšana-testēšana...
Šādi izskatās noteikums... Lai gan zini ko? Istio ir tik vienkāršs, un šis yaml fails ir tik skaidrs, ka viss šajā piemērā runā pats par sevi, vienkārši apskatiet:
Pusi no laika mēs piedzīvosim 7 sekunžu kavēšanos. Un tas nepavisam nav tas pats, kas avota kodā ievietotu miega komandu, jo Istio faktiski aizkavē pieprasījumu par 7 sekundēm. Tā kā Istio atbalsta Jaeger izsekošanu, šī aizkave ir pamanāma Jaeger lietotāja saskarnē, kā parādīts tālāk esošajā ekrānuzņēmumā. Pievērsiet uzmanību garajam pieprasījumam diagrammas augšējā labajā stūrī - tā ilgums ir 7.02 sekundes:
Šis skripts ļauj pārbaudīt kodu tīkla latentuma apstākļos. Un ir skaidrs, ka, atceļot šo noteikumu, mēs noņemsim mākslīgo kavēšanos. Mēs atkārtojam, bet atkal mēs to visu izdarījām, nekādā veidā nepieskaroties avota kodam.
Neatkāpies un nepadodies
Vēl viena noderīga Istio funkcija haosa inženierijai ir atkārtoti zvani uz pakalpojumu noteiktu skaitu reižu. Šeit galvenais ir turpināt mēģināt, kad pirmais pieprasījums beidzas ar kļūdu 503 — un tad varbūt N vienpadsmito reizi mums veiksies. Varbūt viena vai otra iemesla dēļ pakalpojums uz laiku pazuda. Jā, šis iemesls ir jāizrok un jānovērš. Bet tas notiks vēlāk, bet pagaidām mēs centīsimies pārliecināties, ka sistēma turpina darboties.
Tātad, mēs vēlamies, lai pakalpojums laiku pa laikam uzdotu kļūdu 503, un tad Istio mēģinās ar to sazināties vēlreiz. Un šeit mums noteikti ir nepieciešams veids, kā ģenerēt 503 kļūdu, nepieskaroties pašam kodam...
Beidz, pagaidi! Mēs tikko to izdarījām.
Šis fails nodrošinās to, ka pakalpojums Rekomendācijas v2 pusi no laika izdos kļūdu 503:
Acīmredzot daži pieprasījumi neizdosies:
Tagad izmantosim funkciju Istio Retry:
Šis maršrutēšanas noteikums atkārtojas trīs reizes ar divu sekunžu intervālu, un tam vajadzētu samazināt (un ideālā gadījumā noņemt no radara) 503 kļūdas:
Rezumējot: mēs izdarījām tā, lai Istio, pirmkārt, ģenerētu 503 kļūdu pusei pieprasījumu. Un, otrkārt, tas pats Istio veic trīs mēģinājumus atkārtoti sazināties ar servisu, kad rodas kļūda 503. Rezultātā viss darbojas lieliski. Tādējādi, izmantojot funkciju Retry, esam izpildījuši savu solījumu nepadoties un nepadoties.
Un jā, mēs to izdarījām vēlreiz, nemaz nepieskaroties kodam. Viss, kas mums bija vajadzīgs, bija divi Istio maršrutēšanas noteikumi:
Kā nepievilt lietotāju vai septiņi to negaida
Tagad pārvērtīsim situāciju un apsvērsim scenāriju, kurā vienīgais, kas jums jādara, ir neatkāpties vai nepadoties uz noteiktu laiku. Un tad jums vienkārši jāpārtrauc mēģināt apstrādāt pieprasījumu, lai nepiespiestu visus gaidīt vienu lēnu pakalpojumu. Proti, mēs neaizstāvēsim zaudēto pozīciju, bet atkāpsimies uz rezerves līniju, lai nepieviltu vietnes lietotāju un nepiespiestu nīkuļot neziņā.
Programmā Istio varat iestatīt vaicājuma izpildes taimautu. Ja pakalpojums pārsniedz šo taimautu, tiek atgriezta kļūda 504 (Vārtejas taimauts) — tas atkal tiek darīts, izmantojot Istio konfigurāciju. Bet pakalpojuma avota kodam būs jāpievieno miega komanda (un pēc tam, protams, jāveic pārbūve un pārizvietošana), lai simulētu pakalpojuma lēno darbību. Diemžēl citādi tas nedarbosies.
Tātad, mēs ievietojām trīs sekunžu miega režīmu ieteikuma v2 pakalpojuma kodā, pārbūvējām atbilstošo attēlu un atkārtoti izvietojām konteineru, un tagad mēs pievienosim taimautu, izmantojot šo Istio maršrutēšanas noteikumu:
Augšējā ekrānuzņēmumā redzams, ka mēs atsakāmies no mēģinājuma sazināties ar ieteikumu pakalpojumu, ja nesaņemam atbildi vienas sekundes laikā, tas ir, pirms kļūdas 504. Pēc šī maršrutēšanas noteikuma piemērošanas (un trīs sekunžu miega režīma pievienošanas) uz ieteikuma pakalpojuma kodu :v2), mēs iegūstam šo:
Mēs atkārtojam vēlreiz, taču taimautu var iestatīt, nekādā veidā nepieskaroties avota kodam. Un papildu bonuss šeit ir tāds, ka tagad varat modificēt savu kodu, lai reaģētu uz taimautu, un viegli pārbaudīt šīs modifikācijas, izmantojot Istio.
Un tagad tas viss ir kopā
Neliela haosa ieviešana ar Istio ir lielisks veids, kā pārbaudīt savu kodu un visas sistēmas uzticamību. Atkāpšanās, starpsienu un automātisko slēdžu shēmas, mākslīgu atteices un aizkaves radīšanas mehānismi, kā arī atkārtota mēģinājuma izsaukumi un taimauts būs ļoti noderīgi, veidojot defektu izturīgas mākoņsistēmas. Apvienojumā ar Kubernetes un Red Hat OpenShift šie rīki palīdzēs jums ar pārliecību stāties pretī nākotnei.
Avots: www.habr.com
