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

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

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

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

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

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

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

Мониторинг – всъщност, това е самото наблюдение на вашата система – чрез интерфейса или средства за автоматизация. Основата на мониторинга се състои от трасировъчни данни. В Istio мониторингът е реализиран с помощта на Prometheus и има съответстващ интерфейс. 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 помага да се справите с тези трудности за нула време.

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

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

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

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

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

По-долу е 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, това закъснение може да бъде ясно наблюдавано в UI на 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), за да симулираме бавната работа на услугата. Уви, без това не можем.

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

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

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

А сега всичко заедно

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

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