Heisenberg óvissureglan segir að ekki sé hægt að mæla stöðu hlutar og hraða hans á sama tíma. Ef hlutur er á hreyfingu, þá hefur hann enga staðsetningu. Og ef það er staðsetning þýðir það að það hefur engan hraða.
Hvað varðar örþjónustur á Red Hat OpenShift pallinum (og keyrir Kubernetes), þökk sé viðeigandi opnum hugbúnaði, geta þær samtímis tilkynnt bæði frammistöðu sína og heilsu. Þetta hrekur auðvitað ekki gamla Heisenberg, en það eyðir óvissunni þegar unnið er með skýjaforrit. Istio gerir það auðvelt að fylgjast með og fylgjast með þessum forritum til að halda öllu í skefjum.
Ákvörðun um hugtök
undir rekja (Rekja) við skiljum skráningu á kerfisvirkni. Þetta hljómar frekar almennt, en í raun er ein af grunnreglunum hér að henda rekjagögnunum í viðeigandi geymslu án þess að hafa áhyggjur af því að forsníða þau. Og öll vinna við leit og greiningu gagna hvílir á neytandanum. Istio notar Jaeger rakningarkerfið, sem útfærir OpenTracing gagnalíkanið.
Á slóðum (Traces, og orðið „traces“ er notað hér í merkingunni „traces“, eins og t.d. í ballískri athugun) munum við kalla gögn sem lýsa algjörlega yfirferð beiðni eða verkeiningu, eins og sagt er, "frá og til." Til dæmis allt sem gerist frá því að notandi smellir á hnapp á vefsíðu og þar til gögnunum er skilað, þar með talið allar örþjónustur sem taka þátt. Við getum sagt að ein ummerki lýsi (eða líkan) algjörlega hringferð beiðninnar. Í Jaeger viðmótinu eru ummerki brotin niður í íhluti meðfram tímaásnum, svipað og hvernig hægt er að sundra keðju í einstaka hlekki. Aðeins í stað krækju samanstendur brautin af svokölluðum spannum.
Span er bilið frá upphafi verkeininga þar til henni lýkur. Áfram líkingunni getum við sagt að hvert span tákni sérstakan hlekk í keðjunni. Span getur (eða ekki) haft eitt eða fleiri barnasvið. Þar af leiðandi mun efsta span (rótarsvið) hafa sömu heildarlengd og ummerki sem það tilheyrir.
Eftirlit - þetta er í raun sjálf athugun á kerfinu þínu - með augum þínum, í gegnum notendaviðmótið eða sjálfvirkniverkfæri. Vöktun byggist á ummerkjagögnum. Í Istio er eftirlit útfært með Prometheus og hefur viðeigandi notendaviðmót. Prometheus styður sjálfvirkt eftirlit með því að nota Alerts og Alert Managers.
Við skiljum eftir merki
Til þess að rekja sé möguleg þarf forritið að búa til safn spanna. Síðan þarf að flytja þau út til Jaeger, þannig að það aftur skapi sjónræna framsetningu á ummerkinu. Þessar spannir merkja meðal annars heiti starfseminnar, auk upphafs- og lokatímastimpla. Sending spanna er framkvæmd með því að framsenda Jaeger-sértæka HTTP beiðnihausa frá komandi beiðnum yfir í sendar beiðnir. Það fer eftir forritunarmálinu sem notað er, þetta gæti þurft smávægilegar breytingar á frumkóða forritsins. Hér að neðan er sýnishorn af kóða í Java (með Spring Boot ramma) sem bætir B3 (Zipkin-stíl) hausum við beiðni þína í Spring stillingarflokknum:
Eftirfarandi hausstillingar eru notaðar:
Ef þú ert að nota Java, þá geturðu látið kóðann í friði og bara bæta nokkrum línum við Maven POM skrána og stilla umhverfisbreyturnar. Hér eru línurnar sem þú þarft að bæta við POM.XML skrána þína til að innleiða Jaeger Tracer Resolver:
Og samsvarandi umhverfisbreytur eru stilltar í Dockerfile:
Það er það, nú er allt stillt og örþjónustur okkar munu byrja að búa til rakningargögn.
Við skulum skoða almennt
Istio inniheldur einfalt stjórnborð byggt á Grafana. Þegar allt hefur verið stillt og keyrt á Red Hat OpenShift PaaS pallinum (í dæminu okkar eru Red Hat OpenShift og Kubernetes sett á minishift), er þetta spjald ræst með eftirfarandi skipun:
open "$(minishift openshift service grafana -u)/d/1/istio-dashboard?refresh=5⩝Id=1"
Grafana spjaldið gerir þér kleift að meta árangur kerfisins fljótt. Brot af þessu spjaldi er sýnt á myndinni hér að neðan:
Hér má sjá að örþjónusta viðskiptavina kallar valinn v1 örþjónustu, sem aftur kallar meðmælin v1 og v2 örþjónustur. Grafana spjaldið er með Mashboard Row blokk fyrir mælikvarða á háu stigi, svo sem heildarfjölda beiðna (Global Request Volume), árangurshlutfall, 4xx villur. Að auki er Server Mesh útsýni með línuritum fyrir hverja þjónustu og Services Row blokk til að skoða nákvæmar upplýsingar um hvern gám fyrir hverja þjónustu.
Nú skulum við kafa dýpra
Með rétt stilltri rakningu gerir Istio, eins og þeir segja, beint úr kassanum þér kleift að kafa dýpra í greiningu á afköstum kerfisins. Í Jaeger's UI geturðu skoðað ummerki og séð hversu langt og djúpt þau ná, auk þess að staðsetja frammistöðu flöskuhálsa sjónrænt. Þegar Red Hat OpenShift er notað á minishift pallinum skaltu ræsa Jaeger UI með eftirfarandi skipun:
minishift openshift service jaeger-query --in-browser
Hvað geturðu sagt um rakninguna á þessum skjá:
- Það skiptist í 7 span.
- Heildar framkvæmdartími er 6.99 ms.
- Örþjónustan, sem er sú síðasta í keðjunni, eyðir 0.69 ms.
Skýringarmyndir af þessu tagi gera þér kleift að skilja fljótt ástandið þegar afköst alls kerfisins verða fyrir þjáningum vegna einnar illa starfandi þjónustu.
Nú skulum við flækja verkefnið og ræsa tvö tilvik af tilmælunum: v2 örþjónustu með skipuninni oc scale — replicas=2 deployment/recommendation-v2. Hér eru hólf sem við munum hafa eftir þetta:
Ef við skiptum aftur yfir í Jaeger og stækkum umfangið fyrir meðmælaþjónustuna getum við séð til hvaða pod beiðnirnar eru sendar. Þannig getum við auðveldlega staðfært bremsurnar á stigi tiltekins belgs. Í þessu tilfelli þarftu að skoða reitinn node_id:
Hvar og hvernig allt fer
Nú förum við í Prometheus viðmótið og við sjáum þar að vænta að beiðnum á milli annarrar og fyrstu útgáfu af meðmælaþjónustunni er skipt í 2:1 hlutfalli, stranglega í samræmi við fjölda vinnubelgja. Þar að auki mun þetta graf breytast á kraftmikinn hátt eftir því sem belgirnir stækka upp og niður, sem mun vera sérstaklega gagnlegt fyrir Canary Deployment (við munum skoða þetta dreifingarkerfi nánar næst).
Það er aðeins að byrja
Reyndar höfum við í dag, eins og sagt er, aðeins klórað yfirborðið af auðnum gagnlegra upplýsinga um Jaeger, Grafana og Prometheus. Almennt séð var þetta markmið okkar - að benda þér í rétta átt og opna horfur fyrir Istio.
Og mundu, allt þetta er þegar innbyggt í Istio. Þegar þú notar ákveðin forritunarmál (til dæmis Java) og ramma (til dæmis Spring Boot) er hægt að útfæra allt þetta án þess að snerta forritskóðann sjálfan. Já, kóðann verður að breyta aðeins ef þú notar önnur tungumál, sem þýðir fyrst og fremst Nodejs eða C#. En þar sem rekjanleiki (lesið: „rekja“) er ein af forsendum þess að búa til áreiðanleg skýjakerfi, þá verður þú samt að breyta kóðanum, hvort sem þú ert með Istio eða ekki. Svo hvers vegna ekki að nýta krafta þína betur?
Að minnsta kosti til að svara alltaf spurningunum „hvar? og "hversu hratt?" með 100% vissu.
Kaosverkfræði í Istio: þannig var það ætlað
Hæfni til að brjóta hluti hjálpar til við að koma í veg fyrir að þeir brotni.
Hugbúnaðarprófanir eru ekki aðeins erfiðar heldur einnig mikilvægar. Á sama tíma er réttmætisprófun (t.d. hvort fall skilar réttri niðurstöðu) eitt, en prófun í óáreiðanlegu neti er allt annað verkefni (oft er gert ráð fyrir að netið virki alltaf bilanalaust og þetta er fyrsta ranghugmyndin af átta um dreifða útreikninga). Einn af erfiðleikunum við að leysa þetta vandamál er hvernig á að líkja eftir bilunum í kerfinu eða kynna þær viljandi, framkvæma svokallaða bilanasprautu. Þetta er hægt að gera með því að breyta frumkóða forritsins sjálfs. En þá muntu ekki lengur prófa upprunalega kóðann þinn, heldur útgáfu af honum sem líkir sérstaklega eftir bilunum. Fyrir vikið er hætta á að þú lendir í banvænum faðmi bilunarsprautunar og lendir í Heisenbugs - bilunum sem hverfa þegar þú reynir að greina þær.
Nú sýnum við þér hvernig Istio hjálpar þér að takast á við þessi margbreytileika í einu lagi.
Hvernig lítur allt út þegar allt er frábært?
Íhugaðu eftirfarandi atburðarás: við erum með tvo belg fyrir meðmælisörþjónustu okkar, sem við tókum úr Istio kennslunni. Annar belgurinn er merktur v1 og hinn er merktur v2. Eins og þú sérð hefur allt gengið vel hingað til:
(Við the vegur, númerið til hægri er bara símtalateljarinn fyrir hvern belg)
En það er ekki það sem við þurfum, er það? Jæja, við skulum reyna að brjóta allt án þess að snerta frumkóðann yfirleitt.
Við skipuleggjum truflanir í rekstri örþjónustunnar
Hér að neðan er yaml skráin fyrir Istio leiðarreglu sem mun mistakast (villa) í helmingi tilvika. miðlara 503):
Vinsamlegast athugaðu að við tökum sérstaklega fram að 503 villu ætti að skila í helmingi tilvika.
Og hér er hvernig skjáskot af krulluskipun sem keyrir í lykkju mun líta út eftir að við virkjum þessa reglu til að líkja eftir mistökum. Eins og þú sérð, þá skilar helmingur beiðnanna villu 503, óháð því hvaða pod - v1 eða v2 - þær fara á:
Til að endurheimta eðlilega virkni er nóg að eyða þessari reglu, í okkar tilviki með istioctl delete routerule recommendation-503 -n kennsluskipuninni. Hér, Tutorial er nafn Red Hat OpenShift verkefnisins sem keyrir Istio kennsluna okkar.
Kynna tilbúnar tafir
Falsar 503 villur hjálpa til við að prófa seiglu kerfis við bilun, en hæfileikinn til að spá fyrir um og meðhöndla tafir ætti að heilla þig enn meira. Og tafir í raunveruleikanum gerast oftar en mistök. Hæg örþjónusta er eitur sem hefur áhrif á allt kerfið. Með Istio geturðu prófað kóðann sem tengist seinkun án þess að breyta honum á nokkurn hátt. Í fyrsta lagi munum við sýna hvernig á að gera þetta ef um er að ræða tilbúnar nettafir.
Vinsamlegast athugaðu að eftir að hafa prófað á þennan hátt gætir þú þurft (eða vilja) að fínstilla kóðann þinn. Góðu fréttirnar hér eru þær að í þessu tilfelli muntu vera fyrirbyggjandi frekar en viðbragðsgóður. Þetta er nákvæmlega hvernig þróunarferlið ætti að vera byggt upp: kóða-prófun-tilbaka-kóðun-prófun...
Svona lítur reglan út... Þó þú veist hvað? Istio er svo einfalt og þessi yaml skrá er svo skýr að allt í þessu dæmi talar sínu máli, kíktu bara:
Helmingi tímans munum við upplifa 7 sekúndna seinkun. Og þetta er alls ekki það sama og ef við settum svefnskipun inn í frumkóðann, þar sem Istio seinkar beiðninni um 7 sekúndur. Þar sem Istio styður Jaeger rekja er þessi seinkun áberandi í Jaeger UI, eins og sýnt er á skjámyndinni hér að neðan. Gefðu gaum að löngu beiðninni í efra hægra horninu á skýringarmyndinni - lengd hennar er 7.02 sekúndur:
Þetta handrit gerir þér kleift að prófa kóðann þinn við netleynd. Og það er ljóst að með því að fjarlægja þessa reglu munum við fjarlægja gervi töfina. Við skulum endurtaka okkur, en við gerðum þetta allt aftur án þess að snerta frumkóðann á nokkurn hátt.
Ekki hörfa og ekki gefast upp
Annar gagnlegur eiginleiki Istio fyrir glundroðaverkfræði er endurtekin símtöl í þjónustuna tiltekinn fjölda skipta. Málið hér er að halda áfram að reyna þegar fyrsta beiðnin endar með 503 villu - og þá kannski í N-ellefta skiptið sem við verðum heppnir. Kannski fór þjónustan bara niður um tíma af einni eða annarri ástæðu. Já, þessa ástæðu ætti að grafa upp og útrýma. En það kemur seinna, en í bili munum við reyna að tryggja að kerfið haldi áfram að virka.
Þannig að við viljum að þjónustan hendi 503 villu af og til og þá mun Istio reyna að hafa samband við hana aftur. Og hér þurfum við greinilega leið til að búa til 503 villu án þess að snerta kóðann sjálfan...
Hættu, bíddu! Við gerðum það bara.
Þessi skrá mun gera það þannig að meðmæli-v2 þjónustan mun gefa út 503 villu helminginn af tímanum:
Augljóslega munu sumar beiðnir mistakast:
Nú skulum við nota Istio Retry aðgerðina:
Þessi leiðarregla endurtekur sig þrisvar sinnum með tveggja sekúndna millibili og ætti að draga úr (og helst fjarlægja af ratsjánni) 503 villur:
Til að draga saman: við gerðum það þannig að Istio, í fyrsta lagi, býr til 503 villu fyrir helming beiðnanna. Og í öðru lagi gerir sami Istio þrjár tilraunir til að hafa aftur samband við þjónustuna þegar villa kemur upp 503. Þar af leiðandi virkar allt bara vel. Þannig höfum við efnt loforð okkar um að gefast ekki upp og ekki gefast upp með því að nota eiginleikann Reyna aftur.
Og já, við gerðum það aftur án þess að snerta kóðann yfirleitt. Allt sem við þurftum voru tvær Istio leiðarreglur:
Hvernig ekki að láta notandann niður eða sjö ekki búast við einum
Nú skulum við snúa ástandinu út og íhuga atburðarás þar sem það eina sem þú þarft að gera er ekki að hörfa eða gefast upp í ákveðinn tíma. Og þá þarftu bara að hætta að reyna að vinna úr beiðninni, til að neyða ekki alla til að bíða eftir einni hægri þjónustu. Með öðrum orðum, við munum ekki verja tapaða stöðu, heldur hörfa í varalínu til að láta notanda síðunnar ekki falla og ekki neyða hann til að deyja í fáfræði.
Í Istio geturðu stillt tímamörk fyrir framkvæmd fyrirspurnar. Ef þjónustan fer yfir þennan tímaskil er 504 villa (Gateway Timeout) skilað - aftur, þetta er allt gert í gegnum Istio stillinguna. En við verðum að bæta svefnskipun við frumkóðann fyrir þjónustuna (og síðan, að sjálfsögðu, endurbyggja og endurskipuleggja) til að líkja eftir hægum rekstri þjónustunnar. Því miður, það mun ekki virka öðruvísi.
Þannig að við settum þriggja sekúndna svefn inn í meðmæli v2 þjónustukóðann, endurbyggðum samsvarandi mynd og enduruppfærðum ílátið og nú munum við bæta við tímamörkum með því að nota eftirfarandi Istio leiðarreglu:
Á skjáskotinu hér að ofan má sjá að við gefumst upp á að reyna að hafa samband við meðmælaþjónustuna ef við fáum ekki svar innan einni sekúndu, það er áður en 504 villan kemur upp. Eftir að hafa beitt þessari leiðarreglu (og bætt við þriggja sekúndna svefni) í meðmælaþjónustukóðann:v2), fáum við þetta:
Við endurtökum aftur, en hægt er að stilla tímamörk án þess að snerta frumkóðann á nokkurn hátt. Og bónusinn hér er að þú getur nú breytt kóðanum þínum til að bregðast við tímamörkum og auðveldlega prófað þessar breytingar með Istio.
Og nú er þetta allt saman
Að sprauta smá ringulreið með Istio er frábær leið til að prófa kóðann þinn og áreiðanleika kerfisins í heild sinni. Fallback-, þil- og aflrofarmynstur, aðferðir til að búa til gervibilanir og tafir, svo og endurtekin símtöl og tímamörk munu vera mjög gagnleg þegar búið er til bilunarþolin skýjakerfi. Ásamt Kubernetes og Red Hat OpenShift munu þessi verkfæri hjálpa þér að takast á við framtíðina með sjálfstrausti.
Heimild: www.habr.com
