Назад на микроуслуге са Истиом. део 1

Белешка. трансл.: Сервисне мреже су дефинитивно постале релевантно решење у модерној инфраструктури за апликације које прате микросервисну архитектуру. Иако је Истио можда на уснама многих ДевОпс инжењера, то је прилично нов производ који, иако је свеобухватан у смислу могућности које пружа, може захтевати значајно време да се упозна са њим. Немачки инжењер Ринор Малоку, који је одговоран за рачунарство у облаку за велике клијенте у телекомуникационој компанији Оранге Нетворкс, написао је дивну серију материјала који вам омогућавају да брзо и дубоко зароните у Истио. Он почиње своју причу о томе шта Истио уопште може да уради и како то можете брзо да видите сопственим очима.

Истио — Пројекат отвореног кода развијен у сарадњи са тимовима из Гугла, ИБМ-а и Лифта. Он решава сложености које настају у апликацијама заснованим на микросервисима, као што су:

• Управљање саобраћајем: временска ограничења, поновни покушаји, балансирање оптерећења;
• безбедност: аутентификација и ауторизација крајњег корисника;
• Опсервабилити: праћење, праћење, евидентирање.

Све ово се може решити на нивоу апликације, али након тога ваше услуге више неће бити „микро“. Сав додатни напор за решавање ових проблема је губљење ресурса компаније који би се могли директно користити за пословну вредност. Погледајмо пример:

Менаџер пројекта: Колико времена је потребно да се дода функција повратних информација?
Програмер: Два спринта.

МП: Шта?.. Само ГРУБО!
Р: Извођење ЦРУД-а је лак део, али још увек морамо да аутентификујемо и ауторизујемо кориснике и услуге. Пошто је мрежа непоуздана, мораћете да примените поновљене захтеве, као и образац прекидача у клијентима. Такође, да бисте били сигурни да се цео систем не сруши, биће вам потребно временско ограничење и преграде (за више детаља о оба поменута обрасца, погледајте даље у чланку - прибл. прев.), а у циљу откривања проблема, праћење, праћење, […]

МП: Ох, онда хајде да само убацимо ову функцију у услугу производа.

Мислим да је идеја јасна: количина корака и напора потребних за додавање једне услуге је огромна. У овом чланку ћемо погледати како Истио уклања сву горе поменуту сложеност (која није пословна логика) из услуга.

Приметити: Овај чланак претпоставља да имате радно знање о Кубернетесу. Иначе, препоручујем читање мој увод у Кубернетес а тек након тога наставите са читањем овог материјала.

Истио идеа

У свету без Истио-а, једна услуга упућује директне захтеве другој, а у случају квара, услуга мора сама да се носи са тим: направи нови покушај, обезбеди тајм-аут, отвори прекидач итд.

Мрежни саобраћај у Кубернетесу

Истио нуди специјализовано решење, потпуно одвојено од услуга и функционисање ометањем мрежне комуникације. И тако имплементира:

• толеранција грешака: На основу статусног кода у одговору, разуме да ли захтев није успео и поново га извршава.
• Цанари роллоутс: преусмерава само фиксни проценат захтева на нову верзију услуге.
• Мониторинг и метрика: Колико је времена требало да услуга одговори?
• Праћење и уочљивост: Додаје посебна заглавља сваком захтеву и прати их кроз кластер.
• безбедност: Преузима ЈВТ токен, аутентификује и овлашћује кориснике.

Ово су само неке од могућности (заиста само неколико!) да вас заинтригирају. Хајде сада да заронимо у техничке детаље!

Истио архитектура

Истио пресреће сав мрежни саобраћај и на њега примењује скуп правила, убацујући паметни прокси у облику бочног контејнера у сваки под. Проксији који активирају све могућности формирају а Дата Плане, и могу се динамички конфигурисати помоћу Контролни авион.

Дата Плане

Проксији уметнути у подове омогућавају Истио-у да лако испуни захтеве који су нам потребни. На пример, хајде да проверимо функције поновног покушаја и прекидача.

Како се поновни покушаји и прекидање кола имплементирају у Енвои-у

Да сумирам:

1. изасланик (говоримо о проксију који се налази у контејнеру за приколицу, који се дистрибуира као посебан производ — прибл. превод) шаље захтев првој инстанци сервиса Б и не успева.
2. Изасланик Сидецар покушава поново (покушај поново). (1)
3. Захтев не успева и враћа се проксију који га је позвао.
4. Ово отвара прекидач и позива следећу услугу за следеће захтеве. (2)

То значи да не морате да користите другу библиотеку Ретри, не морате да правите сопствену имплементацију Цирцуит Бреакинг и Сервице Дисцовери у програмском језику Кс, И или З. Све ово и још много тога је доступно из кутије у Истио и не захтева не промене у коду.

Велики! Сада можда желите да идете на путовање са Истиом, али још увек имате недоумице, отворена питања. Ако је ово универзално решење за све прилике у животу, онда имате природну сумњу: на крају крајева, сва таква решења у стварности се испостављају као неприкладна за сваки случај.

И на крају питате: "Да ли је прилагодљив?"

Сада сте спремни за поморску пловидбу, хајде да се упознамо са Контролним авионом.

Контролни авион

Састоји се од три компоненте: Пилот, миксер и Цитадела, који раде заједно како би конфигурисали Изасланике да усмеравају саобраћај, примењују смернице и прикупљају податке телеметрије. Шематски све то изгледа овако:

Интеракција контролне равни и равни података

Изасланици (тј. раван података) се конфигуришу помоћу Кубернетес ЦРД (Прилагођене дефиниције ресурса) које је дефинисао Истио и посебно намењен за ову сврху. За вас ово значи да се чини да су само још један ресурс у Кубернетесу са познатом синтаксом. Једном креиран, овај ресурс ће покупити контролна раван и применити га на Изасланике.

Однос услуга према Истио

Описали смо Истио однос према услугама, али не и обрнуто: како се услуге односе на Истио?

Искрено говорећи, службе су свесне Истиовог присуства колико и рибе воде када се запитају: „Шта је уопште вода?“

Илустрација Викторија Димитракопулос: - Како ти се свиђа вода? - Шта је уопште вода?

Дакле, можете узети радни кластер и након постављања Истио компоненти, услуге које се налазе у њему ће наставити да раде, а након уклањања ових компоненти, све ће поново бити у реду. Јасно је да ћете у овом случају изгубити могућности које пружа Истио.

Доста теорије - хајде да ово знање применимо у пракси!

Истио у пракси

Истио захтева Кубернетес кластер са најмање 4 вЦПУ-а и 8 ГБ РАМ-а на располагању. Да бисте брзо поставили кластер и следили упутства из чланка, препоручујем да користите Гоогле Цлоуд Платформ, која нуди новим корисницима бесплатно 300 долара.

Након креирања кластера и конфигурисања приступа Кубернетес-у преко услужног програма конзоле, Истио можете инсталирати преко Хелм менаџера пакета.

Монтажа кормила

Инсталирајте Хелм клијент на свој рачунар, као што је описано у званична документација. Користићемо ово за генерисање шаблона за инсталирање Истио-а у следећем одељку.

Инсталирање Истио-а

Преузмите Истио ресурсе са Најновије издање (оригинални ауторов линк до верзије 1.0.5 је промењен у актуелну, тј. 1.0.6 – прибл. превод), извуците садржај у један директоријум, који ћу од сада звати [istio-resources].

Да бисте лако идентификовали Истио ресурсе, направите именски простор у кластеру К8с istio-system:

$ kubectl create namespace istio-system

Завршите инсталацију тако што ћете отићи у директоријум [istio-resources] и покретање команде:

$ helm template install/kubernetes/helm/istio 
  --set global.mtls.enabled=false 
  --set tracing.enabled=true 
  --set kiali.enabled=true 
  --set grafana.enabled=true 
  --namespace istio-system > istio.yaml

Ова команда ће извести кључне компоненте Истио-а у датотеку istio.yaml. Изменили смо стандардни шаблон како би нам одговарао, наводећи следеће параметре:

• global.mtls.enabled инсталиран у false (тј. мТЛС аутентификација је онемогућена – прибл.)да поједноставимо наш процес упознавања;
• tracing.enabled укључује праћење захтева користећи Јаегер;
• kiali.enabled инсталира Киали у кластер за визуелизацију услуга и саобраћаја;
• grafana.enabled инсталира Графану да визуализује прикупљене метрике.

Хајде да користимо генерисане ресурсе са командом:

$ kubectl apply -f istio.yaml

Инсталација Истио-а на кластер је завршена! Сачекајте док се сви подови не нађу у именском простору istio-system ће моћи да Running или Completedпокретањем наредбе испод:

$ kubectl get pods -n istio-system

Сада смо спремни да наставимо у следећем одељку, где ћемо покренути апликацију.

Архитектура апликације за анализу расположења

Користимо пример микросервисне апликације Сентимент Аналисис која се користи у већ поменутом Уводни чланак у Кубернетес. Довољно је сложен да покаже Истиове способности у пракси.

Апликација се састоји од четири микросервиса:

1. Сервис СА-Фронтенд, који служи фронтенду Реацтјс апликације;
2. Сервис СА-ВебАпп, који служи упитима анализе сентимента;
3. Сервис СА-Логиц, који се сам изводи анализа осећања;
4. Сервис СА-Феедбацк, који од корисника добија повратне информације о тачности анализе.

На овом дијаграму, поред сервиса, видимо и Ингресс Цонтроллер, који у Кубернетесу усмерава долазне захтеве одговарајућим сервисима. Истио користи сличан концепт у оквиру свог Ингресс Гатеваи-а, о чему ће више детаља следити.

Покретање апликације са проксијем из Истио-а

За даље операције поменуте у чланку, клонирајте своје спремиште истио-мајсторство. Садржи апликацију и манифесте за Кубернетес и Истио.

Убацивање приколица

Уметање се може извршити аутоматски или руком. Да бисте аутоматски уметнули контејнере за приколицу, мораћете да поставите ознаку на простор имена istio-injection=enabled, што се ради следећом командом:

$ kubectl label namespace default istio-injection=enabled
namespace/default labeled

Сада сваки под који ће бити распоређен у подразумеваном именском простору (default) ће добити свој контејнер за приколицу. Да бисмо ово проверили, хајде да применимо тест апликацију тако што ћемо отићи у основни директоријум спремишта [istio-mastery] и покренути следећу команду:

$ kubectl apply -f resource-manifests/kube
persistentvolumeclaim/sqlite-pvc created
deployment.extensions/sa-feedback created
service/sa-feedback created
deployment.extensions/sa-frontend created
service/sa-frontend created
deployment.extensions/sa-logic created
service/sa-logic created
deployment.extensions/sa-web-app created
service/sa-web-app created

Након што смо поставили услуге, проверимо да ли подови имају два контејнера (са самом услугом и њеном приколицом) тако што ћемо покренути команду kubectl get pods и пазећи да испод колоне READY наведена вредност 2/2, што симболизује да су оба контејнера покренута:

$ kubectl get pods
NAME                           READY     STATUS    RESTARTS   AGE
sa-feedback-55f5dc4d9c-c9wfv   2/2       Running   0          12m
sa-frontend-558f8986-hhkj9     2/2       Running   0          12m
sa-logic-568498cb4d-2sjwj      2/2       Running   0          12m
sa-logic-568498cb4d-p4f8c      2/2       Running   0          12m
sa-web-app-599cf47c7c-s7cvd    2/2       Running   0          12m

Визуелно то изгледа овако:

Прокси изасланик у једном од подова

Сада када је апликација покренута и ради, мораћемо да дозволимо да долазни саобраћај улази у апликацију.

Ингресс Гатеваи

Најбоља пракса да се ово постигне (дозволи саобраћај у кластеру) је кроз Ингресс Гатеваи у Истио-у, који се налази на „ивици“ кластера и омогућава вам да омогућите Истио функције као што су рутирање, балансирање оптерећења, безбедност и надгледање долазног саобраћаја.

Компонента Ингресс Гатеваи и услуга која је прослеђује екстерно инсталирани су у кластер током Истио инсталације. Да бисте сазнали спољну ИП адресу услуге, покрените:

$ kubectl get svc -n istio-system -l istio=ingressgateway
NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP
istio-ingressgateway   LoadBalancer   10.0.132.127   13.93.30.120

Наставићемо да приступамо апликацији користећи ову ИП адресу (назваћу је ЕКСТЕРНАЛНИ ИП), тако да ћемо због погодности уписати вредност у променљиву:

$ EXTERNAL_IP=$(kubectl get svc -n istio-system 
  -l app=istio-ingressgateway 
  -o jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}')

Ако сада покушате да приступите овој ИП адреси преко претраживача, добићете грешку Услуга недоступна, јер подразумевано Истио блокира сав долазни саобраћај, Гатеваи још није дефинисан.

Гатеваи ресурс

Гатеваи је ЦРД (прилагођена дефиниција ресурса) у Кубернетесу, дефинисан након инсталирања Истио-а у кластер и омогућава могућност да одредимо портове, протокол и хостове за које желимо да дозволимо долазни саобраћај.

У нашем случају желимо да дозволимо ХТТП саобраћај на порту 80 за све хостове. Задатак се реализује следећом дефиницијом (хттп-гатеваи.иамл):

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: http-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
- "*"

Овој конфигурацији није потребно објашњење осим селектора istio: ingressgateway. Са овим селектором можемо одредити на који улазни пролаз да применимо конфигурацију. У нашем случају, ово је Ингресс Гатеваи контролер, који је подразумевано инсталиран у Истио.

Конфигурација се примењује позивањем следеће команде:

$ kubectl apply -f resource-manifests/istio/http-gateway.yaml gateway.networking.istio.io/http-gateway created

Гејтвеј сада дозвољава приступ порту 80, али нема појма где да усмери захтеве. За ово ће вам требати Виртуелне услуге.

ВиртуалСервице ресурс

ВиртуалСервице говори Ингресс Гатеваи-у како да усмери захтеве који су дозвољени унутар кластера.

Захтеви за нашу апликацију који долазе преко хттп-гатеваи-а морају бити послати на са-фронтенд, са-веб-апп и са-феедбацк услуге:

Руте које треба конфигурисати са ВиртуалСервицес

Погледајмо захтеве које треба послати СА-Фронтенд-у:

• Тачно подударање успут / треба послати на СА-Фронтенд да добије индек.хтмл;
• Путања са префиксом /static/* морају бити послате у СА-Фронтенд да би примили статичке датотеке које се користе у фронтенду, као што су ЦСС и ЈаваСцрипт;
• Путања у складу са регуларним изразом '^.*.(ico|png|jpg)$', мора се послати СА-Фронтенд, јер Ово су слике приказане на страници.

Имплементација се постиже следећом конфигурацијом (са-виртуалсервице-ектернал.иамл):

kind: VirtualService
metadata:
  name: sa-external-services
spec:
  hosts:
  - "*"
  gateways:
  - http-gateway                      # 1
  http:
  - match:
    - uri:
        exact: /
    - uri:
        exact: /callback
    - uri:
        prefix: /static
    - uri:
        regex: '^.*.(ico|png|jpg)

Важные моменты:



 	
 Этот VirtualService относится к запросам, приходящим через http-gateway;


 	
 В destination определяется сервис, куда отправляются запросы.




Примечание: Конфигурация выше хранится в файле sa-virtualservice-external.yaml, который также содержит настройки для маршрутизации в SA-WebApp и SA-Feedback, но был сокращён здесь в статье для лаконичности.

Применим VirtualService вызовом:

$ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml
virtualservice.networking.istio.io/sa-external-services created
Примечание: Когда мы применяем ресурсы Istio, Kubernetes API Server создаёт событие, которое получает Istio Control Plane, и уже после этого новая конфигурация применяется к прокси-серверам Envoy каждого pod'а. А контроллер Ingress Gateway представляется очередным Envoy, сконфигурированным в Control Plane. Всё это на схеме выглядит так:


Конфигурация Istio-IngressGateway для маршрутизации запросов
Приложение Sentiment Analysis стало доступным по http://{EXTERNAL-IP}/. Не переживайте, если вы получаете статус Not Found: иногда требуется чуть больше времени для того, чтобы конфигурация вступила в силу и кэши Envoy обновились.
Перед тем, как продолжить, поработайте немного с приложением, чтобы сгенерировать трафик (его наличие необходимо для наглядности в последующих действиях — прим. перев.).
Kiali : наблюдаемость
Чтобы попасть в административный интерфейс Kiali, выполните следующую команду:
$ kubectl port-forward 
    $(kubectl get pod -n istio-system -l app=kiali 
    -o jsonpath='{.items[0].metadata.name}') 
    -n istio-system 20001
… и откройте http://localhost:20001/, залогинившись под admin/admin. Здесь вы найдете множество полезных возможностей, например, для проверки конфигурации компонентов Istio, визуализации сервисов по информации, собранной при перехвате сетевых запросов, получения ответов на вопросы «Кто к кому обращается?», «У какой версии сервиса возникают сбои?» и т.п. В общем, изучите возможности Kiali перед тем, как двигаться дальше — к визуализации метрик с Grafana.

Grafana: визуализация метрик
Собранные в Istio метрики попадают в Prometheus и визуализируются с Grafana. Чтобы попасть в административный интерфейс Grafana, выполните команду ниже, после чего откройте http://localhost:3000/:
$ kubectl -n istio-system port-forward 
    $(kubectl -n istio-system get pod -l app=grafana 
    -o jsonpath={.items[0].metadata.name}) 3000
Кликнув на меню Home слева сверху и выбрав Istio Service Dashboard в левом верхнем углу, начните с сервиса sa-web-app, чтобы посмотреть на собранные метрики:

Здесь нас ждёт пустое и совершенно скучное представление — руководство никогда такое не одобрит. Давайте же создадим небольшую нагрузку следующей командой:
$ while true; do 
    curl -i http://$EXTERNAL_IP/sentiment 
    -H "Content-type: application/json" 
    -d '{"sentence": "I love yogobella"}'; 
    sleep .8; done
Вот теперь у нас гораздо более симпатичные графики, а в дополнение к ним — замечательные инструменты Prometheus для мониторинга и Grafana для визуализации метрик, что позволят нам узнать о производительности, состоянии здоровья, улучшениях/деградации в работе сервисов на протяжении времени.
Наконец, посмотрим на трассировку запросов в сервисах.
Jaeger : трассировка
Трассировка нам потребуется, потому что чем больше у нас сервисов, тем сложнее добраться до причины сбоя. Посмотрим на простой случай из картинки ниже:


Типовой пример случайного неудачного запроса
Запрос приходит, падает — в чём же причина? Первый сервис? Или второй? Исключения есть в обоих — давайте посмотрим на логи каждого. Как часто вы ловили себя за таким занятием? Наша работа больше похожа на детективов программного обеспечения, а не разработчиков…
Это широко распространённая проблема в микросервисах и решается она распределёнными системами трассировки, в которых сервисы передают друг другу уникальный заголовок, после чего эта информация перенаправляется в систему трассировки, где она сопоставляется с данными запроса. Вот иллюстрация:


Для идентификации запроса используется TraceId
В Istio используется Jaeger Tracer, который реализует независимый от вендоров фреймворк OpenTracing API. Получить доступ к пользовательского интерфейсу Jaeger можно следующей командой:
$ kubectl port-forward -n istio-system 
    $(kubectl get pod -n istio-system -l app=jaeger 
    -o jsonpath='{.items[0].metadata.name}') 16686
Теперь зайдите на http://localhost:16686/ и выберите сервис sa-web-app. Если сервис не показан в выпадающем меню — проявите/сгенерируйте активность на странице и обновите интерфейс. После этого нажмите на кнопку Find Traces, которая покажет самые последние трейсы — выберите любой — покажется детализированная информация по всем трейсам:

Этот трейс показывает:

 Запрос приходит в istio-ingressgateway (это первое взаимодействие с одним из сервисов, и для запроса генерируется Trace ID), после чего шлюз направляет запрос в сервис sa-web-app.
 В сервисе sa-web-app запрос подхватывается Envoy sidecar'ом, создаётся «ребёнок» в span'е (поэтому мы видим его в трейсах) и перенаправляется в контейнер sa-web-app. (Span — логическая единица работы в Jaeger, имеющая название, время начало операции и её продолжительность. Span'ы могут быть вложенными и упорядоченными. Ориентированный ациклический граф из span'ов образует trace. — прим. перев.)
 Здесь запрос обрабатывается методом sentimentAnalysis. Эти трейсы уже сгенерированы приложением, т.е. для них потребовались изменения в коде.
 С этого момента инициируется POST-запрос в sa-logic. Trace ID должен быть проброшен из sa-web-app.
 …

Примечание: На 4 шаге приложение должно увидеть заголовки, сгенерированные Istio, и передать их в последующие запросы, как показано на изображении ниже:


(A) За проброс заголовков отвечает Istio; (B) За заголовки отвечают сервисы
Istio делает основную работу, т.к. генерирует заголовки для входящих запросов, создаёт новые span'ы в каждом sidecare'е и пробрасывает их. Однако без работы с заголовками внутри сервисов полный путь трассировки запроса будет утерян.
Необходимо учитывать (пробрасывать) следующие заголовки:
x-request-id
x-b3-traceid
x-b3-spanid
x-b3-parentspanid
x-b3-sampled
x-b3-flags
x-ot-span-context
Это несложная задача, однако для упрощения её реализации уже существует множество библиотек — например, в сервисе sa-web-app клиент RestTemplate пробрасывает эти заголовки, если просто добавить библиотеки Jaeger и OpenTracing в его зависимости.
Заметьте, что приложение Sentiment Analysis демонстрирует реализации на Flask, Spring и ASP.NET Core.
Теперь, когда стало ясно, что мы получаем из коробки (или почти «из коробки»), рассмотрим вопросы тонко настраиваемой маршрутизации, управления сетевым трафиком, безопасности и т.п.!
Прим. перев.: об этом читайте в следующей части материалов по Istio от Rinor Maloku, переводы которых последуют в нашем блоге в ближайшее время. UPDATE (14 марта): Вторая часть уже опубликована.
P.S. от переводчика
Читайте также в нашем блоге:

 «Назад к микросервисам вместе с Istio»: часть 2 (маршрутизация, управление трафиком), часть 3 (аутентификация и авторизация);
 «Conduit — легковесный service mesh для Kubernetes»;
 «Что такое service mesh и почему он мне нужен [для облачного приложения с микросервисами]?»;
 «Иллюстрированное руководство по устройству сети в Kubernetes. Части 1 и 2»;
 «Как этот sidecar-контейнер оказался здесь [в Kubernetes]?».

Источник: habr.com
route:

- destination:

host: sa-frontend             # 2

port:

number: 80

Важне тачке:

 Ова виртуелна услуга се односи на захтеве који долазе хттп-гатеваи;
 В destination Одређује се услуга којој се шаљу захтеви.

Приметити: Горња конфигурација се чува у датотеци sa-virtualservice-external.yaml, који такође садржи подешавања за рутирање у СА-ВебАпп-у и СА-Феедбацк-у, али је скраћено овде у чланку ради краткоће.
Хајде да применимо ВиртуалСервице позивом:

Приметити: Када потрошимо Истио ресурсе, Кубернетес АПИ сервер креира догађај који прима Истио Цонтрол Плане, а након тога се нова конфигурација примењује на проксије Енвои сваког под-а. А чини се да је контролер улазног пролаза још један изасланик конфигурисан у контролној равни. Све ово изгледа овако на дијаграму:


Истио-ИнгрессГатеваи конфигурација за рутирање захтева
Апликација Сентимент Аналисис је сада доступна на http://{EXTERNAL-IP}/. Не брините ако добијете статус Није пронађено: Понекад је потребно мало дуже да конфигурација ступи на снагу и да се Енвои кеш ажурира.
Пре него што наставите, играјте се мало са апликацијом да бисте генерисали саобраћај. (његово присуство је неопходно ради јасноће у наредним радњама - прибл. прев.).
Киали: уочљивост
Да бисте дошли до административног интерфејса Киали, покрените следећу команду:

... и отворен http://localhost:20001/, пријављујете се као админ/админ. Овде ћете пронаћи многе корисне функције, на пример, да проверите конфигурацију Истио компоненти, да визуелизујете услуге користећи информације прикупљене од пресретања мрежних захтева, да добијете одговоре на питања „Ко кога контактира?“, „Која верзија услуге се јавља неуспеси?" и тако даље. Уопштено говорећи, истражите могућности Киали-а пре него што пређете на визуелизацију метрике помоћу Графане.

Графана: визуелизација метрике
метрике прикупљене у Истио-у иду у Прометхеус и визуализују се помоћу Графане. Да бисте дошли до Графана административног интерфејса, покрените наредбу испод, а затим отворите http://localhost:3000/:

Кликом на мени Početna горе лево и бирање Истио сервисна контролна табла у горњем левом углу, почните са сервисом са-веб-аппда погледате прикупљене метрике:

Овде нас чека празна и потпуно досадна представа - управа то никада неће одобрити. Хајде да направимо мало оптерећење са следећом командом:

Сада имамо много лепше графиконе, а поред њих, дивне Прометхеус алате за праћење и Графана за визуелизацију метрика које ће нам омогућити да научимо о перформансама, здрављу, побољшањима/деградацији услуга током времена.
На крају, погледајмо захтеве за праћење у услугама.
Јегер: трасирање
Биће нам потребно праћење јер што више услуга имамо, теже је доћи до узрока квара. Погледајмо једноставан случај са слике испод:


Типичан пример случајног неуспелог захтева
Захтев долази, пада - шта је разлог? Први сервис? Или онај други? У оба постоје изузеци - погледајмо дневнике сваког. Колико често сте себе ухватили како ово радите? Наш рад више личи на детективе софтвера него на програмере...
Ово је уобичајен проблем у микросервисима и решава се дистрибуираним системима праћења, у којима сервиси међусобно прослеђују јединствено заглавље, након чега се ове информације прослеђују систему праћења, где се упоређују са подацима захтева. Ево илустрације:


ТрацеИд се користи за идентификацију захтева
Истио користи Јаегер Трацер, који имплементира ОпенТрацинг АПИ оквир независан од произвођача. Можете приступити корисничком интерфејсу Јаегер помоћу следеће команде:

Сада идите на http://localhost:16686/ и изаберите услугу са-веб-апп. Ако услуга није приказана у падајућем менију, прикажите/генеришите активност на страници и ажурирајте интерфејс. Након тога кликните на дугме Финд Трацес, који ће приказати најновије трагове - изаберите било које - појавиће се детаљне информације о свим траговима:

Овај траг показује:

 Захтев долази истио-ингрессгатеваи (ово је прва интеракција са једним од сервиса и за захтев се генерише Траце ИД), након чега мрежни пролаз шаље захтев сервису са-веб-апп.
 У служби са-веб-апп захтев преузима приколица Енвои, „дете“ се креира у распону (зато га видимо у траговима) и преусмерава се на контејнер са-веб-апп. (Распон - логична јединица рада у Јегеру, која има назив, време почетка операције и њено трајање. Распони се могу угнеждити и наручити. Усмерени ациклични граф распона формира траг. — прибл. превод)
 Овде се захтев обрађује методом сентиментАналисис. Ове трагове већ генерише апликација, тј. захтевали су промене кода.
 Од овог тренутка, ПОСТ захтев се покреће у са-логика. ИД трага мора бити прослеђен са са-веб-апп.
 ...

Приметити: У кораку 4, апликација би требало да види заглавља које генерише Истио и да их проследи на следеће захтеве као што је приказано на слици испод:


(А) Истио је одговоран за прослеђивање заглавља; (Б) Услуге су одговорне за заглавља
Истио ради већину посла јер... генерише заглавља за долазне захтеве, креира нове распоне у сваком сидецаре-у и прослеђује их. Међутим, без рада са заглављима унутар услуга, потпуна путања праћења захтева ће бити изгубљена.
Морају се узети у обзир следећа заглавља:

Ово није тежак задатак, али да се поједностави његова имплементација већ постоји многе библиотеке - на пример, у са-веб-апп сервису, РестТемплате клијент прослеђује ова заглавља ако једноставно додате библиотеке Јаегер и ОпенТрацинг у његове зависности.
Имајте на уму да апликација Сентимент Аналисис показује имплементације у Фласк, Спринг и АСП.НЕТ Цоре.
Сада када је јасно шта добијамо из кутије (или скоро из кутије), хајде да погледамо фино подешено рутирање, управљање мрежним саобраћајем, безбедност итд.!
Белешка. трансл.: О томе читајте у следећем делу материјала о Истију од Ринора Малокуа, чији ће преводи уследити на нашем блогу у блиској будућности. УПДАТЕ (14. март): Други део је већ објављено.
ПС од преводиоца
Прочитајте и на нашем блогу:

 „Назад на микроуслуге са Истио-ом“: део 2 (рутирање, контрола саобраћаја), део 3 (аутентификација и ауторизација);
 «Цондуит - лагана сервисна мрежа за Кубернетес";
 «Шта је сервисна мрежа и зашто ми је потребна [за апликацију у облаку са микросервисима]?";
 «Илустровани водич за умрежавање у Кубернетесу. 1. и 2. део";
 «Како је овај контејнер за приколицу завршио овде [у Кубернетесу]?'.

Извор: ввв.хабр.цом