Трасировка и мониторинг в Istio: микросервизи и принцип на неопределеност

Принцип на неопределеността на Хайзенберг гласи, че не може да се измерят едновременно положението на обект и неговата скорост. Ако обектът се движи, той няма определено местоположение. А ако местоположението е известно – значи няма скорост.

Що се отнася до микросервисите на платформата Red Hat OpenShift (и управлявани от Kubernetes), благодарение на подходящия софтуер с отворен код, те могат едновременно да докладват за своята производителност и за работоспособността си. Това, разбира се, не опровергава стареца на Хайзенберг, но елиминира неопределеността при работа с облачни приложения. Istio позволява лесно организиране на проследяване и мониторинг на такива приложения, за да държи всичко под контрол.

Определяме терминологията

Под проследяване (Tracing) разбираме логването на системната активност. Звучи доста общо, но всъщност едно от основните правила тук е да се сбрасыват данните за проследяване в съответното хранилище, без да се грижи за форматирането им. А цялата работа по търсене и анализ на данните е в отговорност на потребителя им. В Istio се използва системата за проследяване Jaeger, реализираща модела на данните OpenTracing.

Проследяванията (Traces, а думата "проследявания" тук се използва в значението на "следи", както например в балистичната експертиза) ще наричаме данните, които напълно описват преминаването на заявка или единица работа, казано по друг начин, "от и до". Например, всичко, което се случва от момента, в който потребителят натиска бутон на уеб страницата, до момента на връщане на данни, включително всички микросервизи, участващи в този процес. Може да се каже, че едно проследяване напълно описва (или моделира) преминаването на заявка напред и назад. В интерфейса на Jaeger проследяванията се разлагат на съставки по времевата ос, подобно на разлагането на верига на отделни звена. Само че вместо звена, проследяването се състои от т.нар. span’ове.

Span – е интервалът между началото на изпълнението на единица работа и нейното завършване. Продължавайки аналогията, може да се каже, че всеки span представлява отделно звено на веригата. Span може да има (или да няма) един или няколко дъщерни span’ове. В резултат на това, span от най-горно ниво (root span) ще има същата обща продължителност, както проследяването, на което принадлежи.

Мониторинг – това всъщност е наблюдението на вашата система – през очите, чрез UI или автоматизации. В основата на мониторинга лежат данни за трасировката. В Istio мониторингът е реализиран чрез Prometheus и има съответния UI. Prometheus поддържа автоматичен мониторинг с използване на известия Alerts и Alert Managers.

Оставяме отметки

За да стане възможна трасировката, приложението трябва да създаде колекция от span'ове. След това те трябва да бъдат експортирани в Jaeger, за да може той от своя страна да създаде визуално представяне на трасировката. Между другото, тези span'ове означават името на операцията, както и времевите марки за започването и завършването ѝ. Предаването на span'овете се извършва чрез пренасочване на заглавките на HTTP заявките, предназначени за Jaeger, от входящи заявки към изходящи заявки. В зависимост от използвания език за програмиране, за това може да е необходимо малко модифициране на изходния код на приложенията. По-долу е даден пример за код на Java (при използване на фреймворка Spring Boot), който добавя заглавки B3 (в стил Zipkin) към вашата заявка в конфигурационния клас на Spring:

При това се използват следните настройки на заглавките:

Ако използвате Java, кодът не трябва да се променя, а просто трябва да добавите няколко реда в POM файла на Maven и да зададете променливи за средата. Ето какви редове трябва да добавите в POM.XML файла, за да внедрите Jaeger Tracer Resolver:

А съответните променливи за средата се задават в Dockerfile:

Всичко, сега всичко е настроено и нашите микроуслуги ще започнат да генерират данни за трасировка.

Наблюдаваме в общи черти

В състава на Istio влиза простичък контролен панел, основан на Grafana. Когато всичко е настроено и работи на платформата Red Hat OpenShift PaaS (в нашия пример Red Hat OpenShift и Kubernetes са разширени на minishift), този панел се стартира с следната команда:

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

Панелът Grafana позволява бързо оценяване на работата на системата. Фрагмент от този панел е показан на изображението по-долу:

Тук може да се види, че микросервизът customer извиква микросервиза preference v1, а той от своя страна извиква микросервисите recommendation v1 и v2. На панела Grafana има блок Dashboard Row за високо ниво метрики, като общо количество заявки (Global Request Volume), дял на успешни заявки (success rates), грешки 4xx. Освен това, там има представяне Server Mesh с графики за всеки сервиз и блок Services Row за преглед на подробности за всеки контейнер за всеки сервиз.

Сега да задълбочим анализа

При правилно настроена трасировка Istio, тя излиза направо от кутията и позволява да се задълбочи в анализа на производителността на системата. В интерфейса на Jaeger можете да разглеждате трасировките и да видите колко дълбоко и надалеч те стигат, както и визуално да локализирате тесните места в производителността. При използване на Red Hat OpenShift на платформата minishift, стартирането на Jaeger UI се извършва с следната команда:

minishift openshift service jaeger-query --in-browser

Какво можем да кажем за трасировката на този екран:

• Тя се разделя на 7 span-а.
• Общото време за изпълнение е 6.99 ms.
• На микросервиза recommendation, който е последният в поредицата, се отделят 0.69 ms.

Този тип диаграми позволяват бързо да се разбере ситуацията, когато заради някой неработещ сервиз страда производителността на цялата система.

А сега усложняваме задачата и стартираме две инстанции на микросервиза recommendation:v2 с командата oc scale —replicas=2 deployment/recommendation-v2. Ето какви pod-ове ще имаме след това:

Ако сега се върнем обратно в Jaeger и разширим span за сервиза recommendation, ще видим на кой pod се маршрутизират запросите. Така можем лесно да локализираме забавянията на нивото на конкретен pod. Трябва да се гледа на полето node_id:

Къде и как всичко протича

Сега преминаваме в интерфейса на Prometheus и напълно очаквано виждаме, че запросите между втората и първата версия на сервиза recommendation се разпределят в отношение 2:1, строго на базата на броя на активните pod-ове. Освен това, този график ще се променя динамично при мащабиране на pod-овете нагоре-надолу, което ще бъде особено полезно при Canary Deployment (по-подробно ще разгледаме тази схема на разгръщане следващия път).

Всичко тепърва започва

Всъщност днес ние, така да се каже, само леко засягаме кладенеца с полезна информация за Jaeger, Grafana и Prometheus. Всъщност това беше нашата цел – да ви насочим в правилната посока и да открием перспективите на Istio.

И запомнете, всичко това вече е вградено в Istio. При използване на определени езици за програмиране (например Java) и фреймворкове (например Spring Boot) всичко това може да бъде реализирано, без да се засяга самият код на приложенията. Да, кодът ще трябва леко да се модифицира, ако използвате други езици, първо сред които са Nodejs или C#. Но тъй като проследимостта (чети: 'трасировка') е едно от основните условия за изграждане на надеждни облачни системи, вие във всеки случай ще трябва да промените кода, независимо дали имате Istio или не. Защо да не вложите усилията си по-ефективно?

Поне за да можете винаги да отговаряте на въпросите „къде?“ и „колко бързо?“ с 100% сигурност.

Хаос инженерство в Istio: така е било замислено

Умението да счупвате неща помага да направите така, че те да не се счупят.

Тестовете на софтуера не само че са сложни, но и важни. В същото време тестовете за точност (например, връща ли функцията правилен резултат) са едно, а тестовете в условия на ненадеждна мрежа – съвсем друга задача (често се предполага, че мрежата винаги работи без прекъсвания и това е първото от осемте заблуди относно разпределените изчисления). Една от трудностите при решаването на тази задача е как да симулирате сривове в системата или да ги внесете нарочно, извършвайки т.н. fault injection. Това може да се направи чрез модификация на изходния код на приложението. Но тогава ще тествате не оригиналния си код, а версията му, която специално симулира сривове. В резултат на това рискувате да попаднете в смъртоносните обятия на fault injection и да се сблъскате с гейзенбагове – сривове, които изчезват при опит за откритие.

А сега ще покажем как Istio помага да се справите с тези трудности с лекота.

Как изглежда всичко, когато всичко работи отлично

Нека разгледаме следния сценарий: имаме два пода за нашия микросервис recommendation, който взехме от учебника по Istio. Един под е маркиран като v1, а другият – като v2. Както виждате, към момента всичко работи отлично:

(Между другото, числото отдясно просто е брояч на извикванията за всеки под.)

Но това не е точно това, от което се нуждаем, нали? Добре, нека опитаме да счупим всичко, без да засягаме изходния код.

Създаваме прекъсвания на работата на микросервиса

По-долу е yaml-файл за правилото за маршрутизиране на Istio, което в половината случаи ще подава грешка. сървър 503):

Обърнете внимание, изрично посочваме, че в половината случаи трябва да се връща грешка 503.

Ето как изглежда екранна снимка на стартирана в цикъл команда curl след активиране на това правило, за да се имитират неуспехи. Както виждате, половината от заявките връщат грешка 503, независимо на кой pod – v1 или v2 – се изпращат:

За да възстановите нормалната работа, е достатъчно да изтриете това правило, в нашия случай с командата istioctl delete routerule recommendation-503 -n tutorial. Тук Tutorial е името на проекта Red Hat OpenShift, в който работи нашият учебник по Istio.

Въвеждаме изкуствени забавяния

Изкуствените грешки 503 помагат за тестване на системата за устойчивост на повреди, но способността да предскаже и обработи забавянията трябва да ви впечатли още повече. Всъщност забавянията в реалния живот се случват по-често от самите повреди. Бавно работещият микросервис е ядро, от което страда цялата система. С помощта на Istio можете да тествате кода, свързан с обработката на забавяния, без да го променяте. За начало ще покажем как да го направим в случай на изкуствено въведени мрежови забавяния.

Обърнете внимание, че след такова тестване, вероятно ще се наложи (или ще искате) да доразработите кода си. Добрата новина е, че в такъв случай ще действате проактивно, а не реактивно. Именно така трябва да изглежда цикълът на разработка: кодиране-тестиране-обратна връзка-кодиране-тестиране…

Ето как изглежда правилото, което… Но знаете ли какво? Istio е толкова просто, а този yaml-файл е толкова разбираем, че всичко в този пример говори само за себе си, просто погледнете:

В половината от случаите ще имаме 7-секундна закъснение. И това не е същото като да сме добавили команда sleep в изходния код, тъй като Istio действително задържа заявката за 7 секунди. Тъй като Istio поддържа трасировка Jaeger, това закъснение е очевидно наблюдаемо в интерфейса на Jaeger, както е показано на екрана по-долу. Обърнете внимание на дългата заявка в горния десен ъгъл на диаграмата – нейното продължителност е 7.02 секунди:

Този сценарий позволява да тестваме кода в условия на мрежови закъснения. И е ясно, че, премахвайки това правило, ще премахнем и изкуственото закъснение. Повтаряме, но отново направихме всичко това, без да променяме изходния код.

Не се отказвай и не се предавай

Друга полезна функция за хаос инжинеринг в Istio е повторното извикване на услугата определен брой пъти. Идеята е да не спираме опитите, когато първата заявка завърши с грешка 503 – и в N-ия опит може би ще имаме късмет. Може би услугата просто е имала кратка пауза по някаква причина. Да, тази причина трябва да се изясни и премахне. Но това ще стане по-късно, а засега да опитаме да накараме системата да продължи да работи.

Така че искаме услугата понякога да връща грешка 503, а Istio след това да се опитва отново да се свърже с нея. И определено се нуждаем от начин да генерираме грешка 503, без да пипаме самия код...

Стойте, изчакайте! Ние току-що го правихме.

Този файл ще направи така, че услугата recommendation-v2 да връща грешка 503 в половината от случаите:

Очевидно е, че част от заявките ще завършат неуспешно:

А сега ще активираме функцията за повторение на Istio:

Това правило за маршрутизиране прави три повторения с двусекундни интервали и трябва да намали (а в идеалния случай напълно да елиминира) грешките 503:

В заключение: направихме така, че Istio, от една страна, генерира грешка 503 за половината от заявките. А от друга страна, същият Istio прави три опити да се свърже отново с услугата при възникване на грешка 503. В резултат на това всичко работи удивително добре. По този начин, чрез функцията за повторение, изпълнихме обещанието си да не се отказваме и да не се предаваме.

И да, отново го направихме, без да пипаме кода. Всичко, от което имахме нужда, бяха две правила за маршрутизиране на Istio:

Как да не подведем потребителя или седем души не чакат

Сега ще променим обстановката и ще разгледаме сценарий, при който не е удачно да се отказваме и да се предаваме само в определен период от време. А след това просто трябва да прекратим опитите да обработим заявка, за да не задържаме всички в очакване на един единствен забавящ сървис. С други думи, няма да защитаваме загубена позиция, а ще отстъпим на резервна линия, за да не подведем потребителя на сайта и да не го принуждаваме да тъне в неведение.

В Istio можете да зададете таймаут за изпълнението на заявка. Ако сървисът надвиши този таймаут, се връща грешка 504 (Gateway Timeout) – отново всичко това се настройва чрез конфигурацията на Istio. Но ще трябва да добавим в изходния код на сървиса командата sleep (а след това, разбира се, да извършим rebuild и redeploy), за да симулираме бавната работа на сървиса. За съжаление, иначе не става.

И така, поставихме трисекунденен sleep в кода на сървиса recommendation v2, пресглобихме съответния образ и направихме redeploy на контейнера, а сега ще добавим таймаут с помощта на следното правило за маршрутиране на Istio:

На изображението по-горе се вижда, че спираме опитите да се свържем със сървиса recommendation, ако не получим отговор в рамките на една секунда, тоест още преди да възникне грешка 504. След прилагането на това правило за маршрутиране (и добавянето на трисекунденен sleep в кода на сървиса recommendation:v2), ще получим следното:

Отново повтаряме, но таймаутът може да се зададе, без да се пипа изходният код. А допълнителният бонус тук е, че сега можете да модифицирате кода си така, че да реагира на таймаута и лесно да тествате тези подобрения с помощта на Istio.

А сега всичко накуп

Внасянето на малко хаос с помощта на Istio е отличен начин да тествате кода си и надеждността на вашата система като цяло. Шаблоните fallback, bulkhead и circuit breaker, механизмите за създаване на изкуствени откази и забавяния, както и повторните повиквания и таймаутите ще бъдат много полезни при създаването на устойчиви на отказ облачни системи. В съчетание с Kubernetes и Red Hat OpenShift тези инструменти ще помогнат да посрещнете бъдещето с увереност.

Източник: habr.com