Heisenberg qeyri-müəyyənlik prinsipi bir cismin mövqeyini və sürətini eyni anda ölçə bilməyəcəyinizi bildirir. Əgər obyekt hərəkət edirsə, onun yeri yoxdur. Və əgər bir yer varsa, sürəti yoxdur.
Red Hat OpenShift platformasındakı (və Kubernetes ilə işləyən) mikroservislərə gəlincə, müvafiq açıq mənbə proqram təminatı sayəsində onlar eyni vaxtda həm performansları, həm də sağlamlıqları barədə məlumat verə bilərlər. Bu, əlbəttə ki, köhnə Heisenberg-i təkzib etmir, lakin bulud proqramları ilə işləyərkən qeyri-müəyyənliyi aradan qaldırır. İstio hər şeyi nəzarət altında saxlamaq üçün bu tətbiqləri izləməyi və izləməyi asanlaşdırır.
Terminologiyaya qərar vermək
Altında izləmə (İzləmə) biz sistem fəaliyyətinin qeydini başa düşürük. Bu olduqca ümumi səslənir, amma əslində burada əsas qaydalardan biri iz məlumatlarını formatlaşdırmaqdan narahat olmadan müvafiq yaddaşa atmaqdır. Məlumatların axtarışı və təhlili ilə bağlı bütün işlər istehlakçının üzərinə düşür. Istio, OpenTracing məlumat modelini tətbiq edən Jaeger izləmə sistemindən istifadə edir.
Yollarda (İzlər və "izlər" sözü burada "izlər" mənasında istifadə olunur, məsələn, ballistik müayinədə) biz bir sorğunun və ya bir iş vahidinin keçidini tamamilə təsvir edən məlumatları adlandıracağıq, necə deyərlər, "dan və." Məsələn, istifadəçinin veb səhifədəki düyməni kliklədiyi andan məlumatların qaytarılmasına qədər baş verən hər şey, o cümlədən bütün mikroservislər. Deyə bilərik ki, bir iz sorğunun gediş-gəlişini tamamilə təsvir edir (və ya modelləri). Jaeger interfeysində izlər zəncirin fərdi halqalara necə parçalana biləcəyi kimi, zaman oxu boyunca komponentlərə parçalanır. Yalnız keçidlər əvəzinə marşrut sözdə aralıqlardan ibarətdir.
Span iş vahidinin başlanmasından onun tamamlanmasına qədər olan intervaldır. Bənzətməyə davam edərək deyə bilərik ki, hər bir aralıq zəncirin ayrıca bir halqasını təmsil edir. Aralığın bir və ya daha çox uşaq aralığı ola bilər (və ya olmaya bilər). Nəticə olaraq, ən üst span (kök aralığı) aid olduğu izlə eyni ümumi müddətə malik olacaq.
Monitorinq - bu, əslində, sisteminizin müşahidəsidir - gözlərinizlə, UI və ya avtomatlaşdırma alətləri vasitəsilə. Monitorinq iz məlumatlarına əsaslanır. Istio-da monitorinq Prometheus istifadə edərək həyata keçirilir və müvafiq UI-yə malikdir. Prometheus Alerts və Alert Managers istifadə edərək avtomatlaşdırılmış monitorinqi dəstəkləyir.
Biz izlər buraxırıq
İzləmənin mümkün olması üçün proqram aralıqlar toplusu yaratmalıdır. Sonra onları Jaeger-ə ixrac etmək lazımdır ki, o da öz növbəsində izin vizual təsvirini yaratsın. Digər şeylər arasında, bu spanlar əməliyyatın adını, həmçinin başlanğıc və bitmə vaxtlarını qeyd edir. Aralıqların ötürülməsi Jaeger-ə xas HTTP sorğu başlıqlarını daxil olan sorğulardan gedən sorğulara yönləndirməklə həyata keçirilir. İstifadə olunan proqramlaşdırma dilindən asılı olaraq, bu, tətbiqin mənbə kodunda kiçik dəyişikliklər tələb edə bilər. Aşağıda, Spring konfiqurasiya sinfində sorğunuza B3 (Zipkin-stil) başlıqları əlavə edən Java-da (Spring Boot çərçivəsindən istifadə etməklə) nümunə kodu verilmişdir:
Aşağıdakı başlıq parametrləri istifadə olunur:
Əgər siz Java-dan istifadə edirsinizsə, kodu tək buraxıb Maven POM faylına bir neçə sətir əlavə edib mühit dəyişənlərini təyin edə bilərsiniz. Jaeger Tracer Resolver proqramını tətbiq etmək üçün POM.XML faylınıza əlavə etməli olduğunuz sətirlər bunlardır:
Və müvafiq mühit dəyişənləri Dockerfile-də təyin olunur:
Budur, indi hər şey konfiqurasiya edilib və mikroservislərimiz iz məlumatlarını yaratmağa başlayacaq.
Ümumi mənada baxaq
Istio Grafana əsasında sadə idarəetmə panelini ehtiva edir. Hər şey Red Hat OpenShift PaaS platformasında konfiqurasiya edildikdən və işə salındıqdan sonra (bizim nümunəmizdə Red Hat OpenShift və Kubernetes minishift-də yerləşdirilir), bu panel aşağıdakı əmrlə işə salınır:
open "$(minishift openshift service grafana -u)/d/1/istio-dashboard?refresh=5⩝Id=1"
Grafana paneli sistemin işini tez qiymətləndirməyə imkan verir. Bu panelin bir hissəsi aşağıdakı şəkildə göstərilmişdir:
Burada görə bilərsiniz ki, müştəri mikroservisi üstünlük v1 mikroservisini çağırır, o da öz növbəsində tövsiyə v1 və v2 mikroservislərini çağırır. Grafana panelində sorğuların ümumi sayı (Qlobal Sorğu Həcmi), müvəffəqiyyət dərəcələri, 4xx səhvləri kimi yüksək səviyyəli göstəricilər üçün Dashboard Row bloku var. Bundan əlavə, hər bir xidmət üçün qrafikləri olan Server Mesh görünüşü və hər bir xidmət üçün hər konteyner haqqında ətraflı məlumatı görmək üçün Xidmətlər Sırası bloku mövcuddur.
İndi daha dərin qazaq
Düzgün konfiqurasiya edilmiş izləmə ilə, Istio, necə deyərlər, qutudan dərhal sonra sistem performansının təhlilini daha dərindən öyrənməyə imkan verir. Jaeger-in UI-də siz izlərə baxa və onların nə qədər uzaq və dərin getdiyini görə bilərsiniz, həmçinin performans darboğazlarını vizual olaraq lokallaşdıra bilərsiniz. Minishift platformasında Red Hat OpenShift istifadə edərkən, aşağıdakı əmrlə Jaeger UI-ni işə salın:
minishift openshift service jaeger-query --in-browser
Bu ekranda izləmə haqqında nə deyə bilərsiniz:
- 7 aralığa bölünür.
- Ümumi icra müddəti 6.99 ms-dir.
- Zəncirdə sonuncu olan tövsiyə mikroservisi 0.69 ms sərf edir.
Bu tip diaqramlar, pis işləyən bir xidmətə görə bütün sistemin işinin pisləşdiyi vəziyyəti tez başa düşməyə imkan verir.
İndi tapşırığı çətinləşdirək və tövsiyənin iki nümunəsini işə salaq: oc miqyaslı əmrlə v2 mikroservisi — replikalar = 2 yerləşdirmə/tövsiyə-v2. Bundan sonra alacağımız qablar bunlardır:
İndi yenidən Jaeger-ə keçsək və tövsiyə xidmətinin əhatə dairəsini genişləndirsək, sorğuların hansı poda yönəldildiyini görə bilərik. Beləliklə, əyləcləri xüsusi bir pod səviyyəsində asanlıqla lokallaşdıra bilərik. Bu halda, node_id sahəsinə baxmaq lazımdır:
Hər şey hara və necə gedir
İndi biz Prometheus interfeysinə gedirik və çox güman ki, orada tövsiyə xidmətinin ikinci və birinci versiyaları arasında sorğuların ciddi şəkildə işləyən podların sayına görə 2:1 nisbətində bölündüyünü görürük. Üstəlik, podlar böyüdükcə və aşağı düşdükcə bu qrafik dinamik şəkildə dəyişəcək, bu xüsusilə Canary Deployment üçün faydalı olacaq (biz növbəti dəfə bu yerləşdirmə sxemini daha yaxından nəzərdən keçirəcəyik).
Yalnız başlayır
Əslində, bu gün biz, necə deyərlər, Jaeger, Grafana və Prometey haqqında faydalı məlumatların sərvətinin yalnız səthini cızmışıq. Ümumiyyətlə, bizim məqsədimiz bu idi - sizi düzgün istiqamətə yönəltmək və İstio üçün perspektivlər açmaq.
Və unutmayın ki, bütün bunlar artıq Istio-da qurulub. Müəyyən proqramlaşdırma dillərindən (məsələn, Java) və çərçivələrdən (məsələn, Spring Boot) istifadə edərkən bütün bunlar tətbiq kodunun özünə toxunmadan həyata keçirilə bilər. Bəli, əgər siz başqa dillərdən istifadə edirsinizsə, ilk növbədə Nodejs və ya C# mənasını verən kod bir qədər dəyişdirilməlidir. İzləmə qabiliyyəti (oxu: “izləmə”) etibarlı bulud sistemlərinin yaradılması üçün ilkin şərtlərdən biri olduğundan, Istio-nuz olub-olmamasından asılı olmayaraq hər halda kodu redaktə etməli olacaqsınız. Bəs niyə səylərinizi daha yaxşı istifadə etməyə sərf etmirsiniz?
Ən azından “harada?” suallarına həmişə cavab vermək üçün. və "nə qədər sürətli?" 100% əminliklə.
Istio-da xaos mühəndisliyi: belə olmalı idi
Əşyaları sındırmaq qabiliyyəti onların qırılmasının qarşısını almağa kömək edir.
Proqram təminatının sınaqdan keçirilməsi təkcə çətin deyil, həm də vacibdir. Eyni zamanda, düzgünlüyün yoxlanılması (məsələn, funksiyanın düzgün nəticəni qaytarması) bir şeydir, lakin etibarsız şəbəkədə sınaqdan keçirmək tamamilə fərqli bir vəzifədir (çox vaxt şəbəkənin həmişə nasazlıq olmadan işlədiyi güman edilir və bu paylanmış hesablamalar haqqında səkkiz yanlış təsəvvürdən birincisidir). Bu problemi həll etməkdə çətinliklərdən biri sistemdəki nasazlıqları necə simulyasiya etmək və ya onları qəsdən təqdim etmək, sözdə səhv inyeksiya etməkdir. Bu, proqramın özünün mənbə kodunu dəyişdirməklə edilə bilər. Lakin sonra siz artıq orijinal kodunuzu yox, onun uğursuzluqları təqlid edən versiyasını yoxlayacaqsınız. Nəticədə, siz səhv inyeksiyanın ölümcül qucağına düşmək və Heisenbugs - onları aşkar etməyə çalışdığınız zaman yox olan uğursuzluqlarla qarşılaşma riskiniz var.
İndi biz sizə Istio-nun bu mürəkkəbliklərin öhdəsindən necə kömək etdiyini göstərəcəyik.
Hər şey əla olanda hər şey necə görünür?
Aşağıdakı ssenarini nəzərdən keçirin: Istio dərsliyindən götürdüyümüz tövsiyə mikroservisimiz üçün iki bölməmiz var. Bir pod v1, digəri isə v2 etiketlidir. Gördüyünüz kimi, indiyə qədər hər şey qaydasındadır:
(Yeri gəlmişkən, sağdakı nömrə hər bir pod üçün sadəcə zəng sayğacıdır)
Amma bu bizə lazım deyil, elə deyilmi? Yaxşı, mənbə koduna toxunmadan hər şeyi pozmağa çalışaq.
Mikroservis işində fasilələr təşkil edirik
Aşağıda yarım dəfə uğursuz (səhv) olan İstio marşrutlaşdırma qaydası üçün yaml faylı verilmişdir. server 503):
Nəzərə alın ki, biz açıq şəkildə bildiririk ki, halların yarısında 503 xətası qaytarılmalıdır.
Uğursuzluqları simulyasiya etmək üçün bu qaydanı aktivləşdirdikdən sonra dövrədə işləyən curl əmrinin skrinşotunun necə görünəcəyi budur. Gördüyünüz kimi, sorğuların yarısı 503 xətasını qaytarır, hansı pod – v1 və ya v2 – bunlara gedir:
Normal işləməyi bərpa etmək üçün bu qaydanı silmək kifayətdir, bizim vəziyyətimizdə istioctl delete routerule recommendation-503 -n tutorial əmri ilə. Burada Tutorial, Istio dərsliyimizi idarə edən Red Hat OpenShift layihəsinin adıdır.
Süni gecikmələrin tətbiqi
Saxta 503 səhvləri sistemin uğursuzluğa davamlılığını sınamağa kömək edir, lakin gecikmələri proqnozlaşdırmaq və idarə etmək bacarığı sizi daha da təsirləndirməlidir. Və real həyatda gecikmələr uğursuzluqlardan daha tez-tez baş verir. Yavaş mikroservis bütün sistemə təsir edən zəhərdir. Istio ilə gecikmə ilə əlaqəli kodu heç bir şəkildə dəyişdirmədən test edə bilərsiniz. Birincisi, süni şəkildə tətbiq olunan şəbəkə gecikmələri halında bunu necə edəcəyimizi göstərəcəyik.
Nəzərə alın ki, bu şəkildə sınaqdan keçirdikdən sonra kodunuzu dəyişdirməyə ehtiyacınız ola bilər (və ya istəyə bilərsiniz). Yaxşı xəbər budur ki, bu vəziyyətdə reaktiv deyil, fəal olacaqsınız. İnkişaf dövrü məhz belə qurulmalıdır: kodlaşdırma-test-geri əlaqə-kodlaşdırma-sınaq...
Qayda belə görünür... Baxmayaraq ki, bilirsinizmi? Istio o qədər sadədir və bu yaml faylı o qədər aydındır ki, bu nümunədəki hər şey özü üçün danışır, sadəcə bir nəzər salın:
Vaxtın yarısında 7 saniyə gecikmə yaşayacağıq. Və bu, mənbə koduna yuxu əmri daxil etdiyimizlə eyni deyil, çünki Istio həqiqətən sorğunu 7 saniyə gecikdirir. Istio Jaeger izləməni dəstəklədiyi üçün bu gecikmə aşağıdakı ekran görüntüsündə göstərildiyi kimi Jaeger UI-də nəzərə çarpır. Diaqramın yuxarı sağ küncündəki uzun sorğuya diqqət yetirin - onun müddəti 7.02 saniyədir:
Bu skript şəbəkə gecikmə şərtləri altında kodunuzu sınamağa imkan verir. Və aydındır ki, bu qaydanı aradan qaldırmaqla biz süni gecikməni aradan qaldıracağıq. Təkrar edirik, amma yenə də bütün bunları mənbə koduna heç bir şəkildə toxunmadan etdik.
Geri çəkilməyin və təslim olmayın
Xaos mühəndisliyi üçün Istio-nun başqa bir faydalı xüsusiyyəti, xidmətə müəyyən sayda təkrar zənglərdir. Buradakı məqam, ilk sorğu 503 xətası ilə başa çatdıqda cəhd etməyə davam etməkdir - və sonra bəlkə N-on birinci dəfə bəxtimiz gətirəcək. Ola bilsin ki, bu və ya digər səbəbdən xidmət bir müddət işdən çıxıb. Bəli, bu səbəb qazılıb aradan qaldırılmalıdır. Ancaq bu daha sonra olacaq, lakin hələlik sistemin işləməyə davam etdiyinə əmin olmağa çalışacağıq.
Beləliklə, xidmətin vaxtaşırı 503 səhvi atmasını istəyirik və sonra Istio yenidən onunla əlaqə saxlamağa çalışacaq. Və burada aydın şəkildə kodun özünə toxunmadan 503 xətası yaratmaq üçün bir yola ehtiyacımız var...
Dayan, gözlə! Biz sadəcə bunu etdik.
Bu fayl onu elə edəcək ki, tövsiyə-v2 xidməti yarım dəfə 503 xətası versin:
Aydındır ki, bəzi sorğular uğursuz olacaq:
İndi İstio Retry funksiyasından istifadə edək:
Bu marşrutlaşdırma qaydası iki saniyəlik fasilələrlə üç dəfə təkrarlanır və 503 səhvini azaltmalıdır (və ideal olaraq radardan çıxarmalıdır):
Xülasə etmək üçün: biz bunu elə etdik ki, Istio, ilk növbədə, sorğuların yarısı üçün 503 səhv yaradır. İkincisi, eyni Istio 503 xətası baş verdikdə xidmətlə yenidən əlaqə saxlamaq üçün üç cəhd edir.Nəticədə hər şey qaydasında işləyir. Beləliklə, "Yenidən cəhd" funksiyasından istifadə edərək, biz təslim olmamaq və təslim olmamaq vədimizi yerinə yetirmiş olduq.
Bəli, biz koda toxunmadan bunu təkrar etdik. Bizə lazım olan yalnız iki İstio marşrutu qaydaları idi:
Istifadəçi aşağı və ya yeddi imkan deyil necə bir gözləmək deyil
İndi vəziyyəti tərsinə çevirək və bir ssenarini nəzərdən keçirək ki, burada etməli olduğunuz yeganə şey geri çəkilməmək və ya müəyyən müddət ərzində təslim olmaq deyil. Və sonra hər kəsi bir yavaş xidmət gözləməyə məcbur etməmək üçün sorğunu emal etməyə çalışmağı dayandırmalısınız. Yəni itirdiyimiz mövqeni müdafiə etməyəcəyik, əksinə, ehtiyat cərgəyə çəkiləcəyik ki, sayt istifadəçisini aşağı salmayaq, onu cəhalətdən ləngiməyə məcbur etməyək.
Istio-da siz sorğunun icra müddətini təyin edə bilərsiniz. Xidmət bu fasiləni keçərsə, 504 xətası (Gateway Timeout) qaytarılır - yenə də bütün bunlar Istio konfiqurasiyası vasitəsilə edilir. Ancaq xidmətin yavaş işləməsini simulyasiya etmək üçün xidmətin mənbə koduna yuxu əmri əlavə etməli olacağıq (və sonra, əlbəttə ki, yenidən qurma və yenidən yerləşdirmə). Təəssüf ki, başqa cür işləməyəcək.
Beləliklə, biz tövsiyə v2 xidmət koduna üç saniyəlik yuxu əlavə etdik, müvafiq təsviri yenidən qurduq və konteyneri yenidən yerləşdirdik və indi aşağıdakı Istio marşrutlaşdırma qaydasından istifadə edərək vaxt aşımı əlavə edəcəyik:
Yuxarıdakı ekran görüntüsündə görə bilərsiniz ki, bir saniyə ərzində cavab almasaq, yəni 504 xətası baş verməzsə, tövsiyə xidməti ilə əlaqə saxlamaqdan imtina edirik. Bu marşrutlaşdırma qaydasını tətbiq etdikdən sonra (və üç saniyəlik yuxu əlavə etdikdən sonra) tövsiyə xidmət koduna :v2), biz bunu alırıq:
Yenidən təkrar edirik, lakin vaxt aşımı heç bir şəkildə mənbə koduna toxunmadan təyin edilə bilər. Və burada əlavə bonus odur ki, siz indi kodunuzu fasiləyə cavab vermək üçün dəyişdirə və Istio-dan istifadə edərək bu dəyişiklikləri asanlıqla sınaqdan keçirə bilərsiniz.
İndi hamısı bir yerdədir
Istio ilə bir az xaos yeritmək kodunuzu və bütövlükdə sisteminizin etibarlılığını sınamaq üçün əla yoldur. Xətaya dözümlü bulud sistemləri yaradan zaman geri qayıtma, arakəsmə və elektrik açarı nümunələri, süni nasazlıqlar və gecikmələr yaratmaq mexanizmləri, həmçinin təkrar zənglər və fasilələr çox faydalı olacaq. Kubernetes və Red Hat OpenShift ilə birlikdə bu alətlər gələcəyə inamla baxmağa kömək edəcək.
Mənbə: www.habr.com
