Дистрибуирано праћење: све смо урадили погрешно

Белешка. трансл.: Аутор овог материјала је Цинди Сридхаран, инжењер у имгик-у који је специјализован за развој АПИ-ја и, посебно, тестирање микросервиса. У овом материјалу она износи своју детаљну визију актуелних проблема у области дистрибуираног праћења, где, по њеном мишљењу, недостају истински ефикасни алати за решавање хитних проблема.

[Илустрација преузета са други материјал о дистрибуираном праћењу.]

Верује се да је дистрибуирано праћење тешка за имплементацију и поврат на то у најбољем случају сумњиво. Постоји много разлога зашто је праћење проблематично, често се наводе напори укључени у конфигурисање сваке компоненте система за пренос одговарајућих заглавља са сваким захтевом. Иако овај проблем постоји, он никако није непремостив. Успут, то не објашњава зашто програмери баш не воле праћење (чак и када већ функционише).

Главни изазов са дистрибуираним праћењем није прикупљање података, стандардизовање формата за дистрибуцију и представљање резултата, или одређивање када, где и како узорковати. Не покушавам да замислим тривијалан ови "проблеми са разумљивошћу" су, у ствари, прилично значајни технички и (ако разматрамо заиста Опен Соурце) стандарде и протоколе) политички изазови које је потребно превазићи да би се ови проблеми сматрали решеним.

Међутим, ако замислимо да су сви ови проблеми решени, постоји велика вероватноћа да се ништа битно неће променити у смислу искуство крајњег корисника. Праћење можда и даље неће бити од практичне користи у најчешћим сценаријима отклањања грешака — чак и након што се примени.

Тако другачији траг

Дистрибуирано праћење укључује неколико различитих компоненти:

• опремање апликација и међувера са контролним алатима;
• дистрибуирани пренос контекста;
• прикупљање трагова;
• складиштење трагова;
• њихово издвајање и визуелизација.

Много прича о дистрибуираном праћењу има тенденцију да га третира као неку врсту унарне операције чија је једина сврха да помогне у потпуној дијагностици система. Ово је углавном због тога како су се идеје о дистрибуираном праћењу историјски формирале. ИН блог ентриес, направљеног приликом отварања Жипкинових извора, поменуто је да то [Зипкин] чини Твиттер бржим. Прве комерцијалне понуде за праћење такође су промовисане као АПМ алати.

Белешка. трансл.: Да бисмо даљи текст лакше разумели, дефинишемо два основна појма према ОпенТрацинг пројектна документација:

• Распон — основни елемент дистрибуираног праћења. То је опис одређеног тока посла (на пример, упит базе података) са именом, временом почетка и завршетка, ознакама, евиденцијама и контекстом.
• Распони обично садрже везе ка другим распонима, што омогућава комбиновање више распона Траце — визуелизација живота захтева док се креће кроз дистрибуирани систем.

Трагови садрже невероватно вредне податке који могу помоћи у задацима као што су тестирање производње, тестирање опоравка од катастрофе, тестирање убризгавања грешке итд. У ствари, неке компаније већ користе праћење у сличне сврхе. Почнимо са универзални пренос контекста има и друге намене осим једноставног премештања распона у систем за складиштење:

• На пример, Убер користи праћење резултата да се направи разлика између тестног саобраћаја и производног саобраћаја.
• фацебоок користи подаци праћења за анализу критичне путање и за пребацивање саобраћаја током редовних тестова опоравка од катастрофе.
• Такође друштвена мрежа примењује Јупитер бележнице које омогућавају програмерима да покрећу произвољне упите о резултатима праћења.
• Присталице ЛДФИ (Убризгавање грешака вођено линијом) употреба дистрибуирани трагови за тестирање са убацивањем грешке.

Ниједна од горе наведених опција не примењује се у потпуности на сценарио отклањање грешака, током којег инжењер покушава да реши проблем гледањем у траг.

Када дође још стигне до скрипте за отклањање грешака, примарни интерфејс остаје дијаграм трацевиев (иако га неки називају и "Гантограм" или "дијаграм водопада"). Испод трацевиев я мислим сви распони и пратећи метаподаци који заједно чине траг. Сваки систем праћења отвореног кода, као и свако комерцијално решење за праћење, нуди а трацевиев кориснички интерфејс за визуелизацију, детаљисање и филтрирање трагова.

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

У прошлости И жалио се на које се чини да је већина „иновација“ у праћењу УИ/УКС-а ограничена укључивање додатни метаподаци у траговима, улажући у њих информације високе кардиналности (високе кардиналности) или пружање могућности да се детаљно анализирају одређени распони или да се покрећу упити интер- и интра-траце... У чему трацевиев остаје примарни алат за визуелизацију. Све док се овакво стање настави, дистрибуирано праћење ће (у најбољем случају) заузети 4. место као алат за отклањање грешака, после метрике, евиденције и праћења стекова, ау најгорем случају ће се показати као губитак новца и времена.

Проблем са приказом праћења

Сврха трацевиев — обезбеди потпуну слику кретања једног захтева кроз све компоненте дистрибуираног система на који се односи. Неки напреднији системи праћења вам омогућавају да се удубите у појединачне распоне и видите квар током времена унутар један процес (када распони имају функционалне границе).

Основна премиса микросервисне архитектуре је идеја да организациона структура расте са потребама компаније. Заговорници микросервиса тврде да дистрибуција различитих пословних задатака у појединачне услуге омогућава малим, аутономним развојним тимовима да контролишу цео животни циклус таквих услуга, дајући им могућност да самостално граде, тестирају и примењују те услуге. Међутим, недостатак ове дистрибуције је губитак информација о томе како свака услуга комуницира са другима. У таквим условима, дистрибуирано праћење тврди да је незаменљив алат за отклањање грешака сложене интеракције између услуга.

Ако заиста запањујуће сложен дистрибуирани систем, онда ни један човек није у стању да то држи у глави комплетан слика. У ствари, развијање алата заснованог на претпоставци да је то уопште могуће је нешто као анти-образац (неефикасан и непродуктиван приступ). У идеалном случају, за отклањање грешака је потребан алат који помаже сузите подручје претраге, тако да се инжењери могу фокусирати на подскуп димензија (услуге/корисници/хостови, итд.) релевантних за сценарио проблема који се разматра. Приликом утврђивања узрока квара, инжењери нису обавезни да разумеју шта се догодило током све услуге одједном, пошто би такав захтев био у супротности са самом идејом микросервисне архитектуре.

Међутим, трацевиев је наиме Ово. Да, неки системи праћења нуде компримоване приказе праћења када је број распона у праћењу толико велики да се не могу приказати у једној визуелизацији. Међутим, због велике количине информација садржаних чак и у тако смањеној визуелизацији, инжењери и даље изнуђен „просејати“ га, ручно сужавајући избор на скуп услуга које су извори проблема. Нажалост, у овој области машине су много брже од људи, мање су склоне грешкама, а њихови резултати су поновљивији.

Други разлог због којег мислим да је трацевиев погрешан је зато што није добар за отклањање грешака засновано на хипотезама. У суштини, отклањање грешака је итеративно процес који почиње хипотезом, након чега следи провера различитих запажања и чињеница добијених из система дуж различитих вектора, закључака/генерализација и даља процена истинитости хипотезе.

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

авај, трацевиев не може се назвати алатом са интерактивним интерфејсом. Најбоље чему се можете надати када га користите је да пронађете неки извор повећане латенције и погледате све могуће ознаке и евиденције повезане са њим. Ово не помаже инжењеру да идентификује узорци у саобраћају, као што су специфичности дистрибуције кашњења, или открити корелације између различитих мерења. Генерализована анализа трагова може помоћи да се заобиђу неки од ових проблема. стварно, има примера успешна анализа коришћењем машинског учења за идентификацију аномалних распона и идентификацију подскупа ознака које могу бити повезане са аномалним понашањем. Међутим, тек треба да видим убедљиве визуелизације налаза машинског учења или рударења података примењених на распоне који се значајно разликују од приказа праћења или ДАГ-а (усмерени ациклични граф).

Распони су прениски

Основни проблем са праћењем је то распони су примитиви сувише ниског нивоа за анализу кашњења и анализу основног узрока. То је као рашчлањивање појединачних команди процесора да бисте покушали да решите изузетак, знајући да постоје алати много вишег нивоа као што је бацктраце са којима је много погодније радити.

Штавише, узећу себи слободу да тврдим следеће: у идеалном случају, не треба нам пуна слика догодио током животног циклуса захтева, што је представљено савременим алатима за праћење. Уместо тога, потребан је неки облик апстракције вишег нивоа који садржи информације о томе шта пошло наопако (слично трагању уназад), заједно са неким контекстом. Уместо да гледам цео траг, више волим да га видим часть, где се дешава нешто занимљиво или необично. Тренутно се претрага врши ручно: инжењер прима траг и самостално анализира распоне у потрази за нечим занимљивим. Приступ људи који буље у распоне у појединачним траговима у нади да ће открити сумњиву активност уопште се не повећава (посебно када морају да разумеју све метаподатке кодиране у различитим распонима, као што су ИД распона, назив РПЦ методе, трајање распона 'а, евиденције, ознаке итд.).

Алтернативе за трацевиев

Резултати праћења су најкориснији када се могу визуелизовати на начин који пружа нетривијалан увид у оно што се дешава у међусобно повезаним деловима система. Док се то не догоди, процес отклањања грешака углавном остаје инертан и зависи од способности корисника да уочи праве корелације, провери праве делове система или састави делове слагалице – за разлику од тоол, помажући кориснику да формулише ове хипотезе.

Нисам визуелни дизајнер или стручњак за УКС, али у следећем одељку желим да поделим неколико идеја о томе како би ове визуелизације могле да изгледају.

Фокусирајте се на одређене услуге

У време када се индустрија консолидује око идеја СЛО (циљеви нивоа услуге) и СЛИ (индикатори нивоа услуге), чини се разумним да појединачни тимови дају приоритет осигуравању да су њихове услуге усклађене са овим циљевима. Следи да услужно оријентисан визуелизација је најприкладнија за такве тимове.

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

1. Дијаграми дистрибуције кашњења само за веома истакнуте захтеве (изузетни захтеви);
2. Дијаграми дистрибуције кашњења за случајеве када циљеви услуге СЛО нису постигнути;
3. Најчешћи „уобичајени“, „занимљиви“ и „чудни“ тагови у упитима који најчешће се понављају;
4. Распад кашњења за случајеве када зависности службе не остварују своје СЛО циљеве;
5. Распоређивање кашњења за различите низводне услуге.

На нека од ових питања једноставно не одговара уграђена метрика, што приморава кориснике да пажљиво прегледају распоне. Као резултат тога, имамо механизам који је изузетно непријатељски расположен према корисницима.

Ово поставља питање: шта је са сложеним интеракцијама између различитих услуга које контролишу различити тимови? зар не трацевиев не сматра се најприкладнијим средством за истицање такве ситуације?

Програмери мобилних уређаја, власници услуга без држављанства, власници услуга којима се управља стањем (као што су базе података) и власници платформи могу бити заинтересовани за нешто друго презентација дистрибуирани систем; трацевиев је превише опште решење за ове суштински различите потребе. Чак иу веома сложеној микросервисној архитектури, власницима услуга није потребно дубоко познавање више од две или три упстреам и довнстреам услуге. У суштини, у већини сценарија, корисници треба да одговоре само на питања у вези ограничен скуп услуга.

То је као да гледате мали подскуп услуга кроз лупу ради прегледа. Ово ће омогућити кориснику да постави хитнија питања у вези са сложеним интеракцијама између ових услуга и њихових непосредних зависности. Ово је слично трагању уназад у свету услуга, где инжењер зна да погрешно, а такође има извесно разумевање шта се дешава у околним службама да разуме зашто.

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

Изградња топологије

Погледи специфични за услугу могу бити невероватно корисни ако корисник зна шта услуга или група услуга је одговорна за повећање кашњења или изазивање грешака. Међутим, у сложеном систему, идентификовање сервиса који је прекршио може бити нетривијалан задатак током квара, посебно ако од услуга нису пријављене поруке о грешци.

Изградња топологије услуге може бити од велике помоћи у откривању која услуга доживљава пораст у стопама грешака или повећање кашњења које узрокује приметну деградацију услуге. Када говорим о изградњи топологије, не мислим мапа услуга, приказујући све услуге доступне у систему и познате по томе мапе архитектуре у облику звезде смрти. Овај приказ није ништа бољи од приказа праћења заснованог на усмереном ацикличном графу. Уместо тога, волео бих да видим динамички генерисана топологија услуге, на основу одређених атрибута као што су стопа грешке, време одговора или било који кориснички дефинисани параметар који помаже да се разјасни ситуација са одређеним сумњивим услугама.

Узмимо пример. Хајде да замислимо хипотетички сајт са вестима. Услуга почетне странице (Насловна страна) размењује податке са Редис-ом, са сервисом препорука, са сервисом оглашавања и видео сервисом. Видео сервис преузима видео записе са С3 и метаподатке из ДинамоДБ-а. Услуга препоруке прима метаподатке од ДинамоДБ-а, учитава податке из Редис-а и МиСКЛ-а и пише поруке Кафки. Услуга оглашавања прима податке од МиСКЛ-а и пише поруке Кафки.

Испод је шематски приказ ове топологије (многи комерцијални програми за рутирање граде топологију). Може бити корисно ако треба да разумете зависности од услуга. Међутим, током отклањање грешака, када одређена услуга (рецимо, видео услуга) показује повећано време одзива, таква топологија није од велике користи.

Дијаграм услуге хипотетичког сајта са вестима

Доњи дијаграм би боље одговарао. Постоји проблем са услугом (видео) приказан тачно у центру. Корисник то одмах примети. Из ове визуелизације постаје јасно да видео сервис ради ненормално због повећања времена одзива С3, што утиче на брзину учитавања дела главне странице.

Динамичка топологија која приказује само „занимљиве“ услуге

Динамички генерисане топологије могу бити ефикасније од статичких мапа услуга, посебно у еластичним инфраструктурама са аутоматским скалирањем. Могућност поређења и контраста топологија услуга омогућава кориснику да поставља релевантнија питања. Прецизнија питања о систему ће вероватно довести до бољег разумевања како систем функционише.

Упоредни приказ

Још једна корисна визуализација би био упоредни приказ. Трагови тренутно нису погодни за упоредна поређења, па су поређења обично распони. А главна идеја овог чланка је управо да су распони сувише ниског нивоа да би се из резултата праћења извукле највредније информације.

Поређење два трага не захтева суштински нове визуелизације. У ствари, довољно је нешто попут хистограма који представља исте информације као и приказ праћења. Изненађујуће, чак и ова једноставна метода може донети много више плода него једноставно проучавање два трага одвојено. Још моћнија би била могућност визуелизовати поређење трагова Укупно. Било би изузетно корисно видети како недавно примењена промена конфигурације базе података ради омогућавања ГЦ-а (сакупљање смећа) утиче на време одговора низводне услуге у размери од неколико сати. Ако ово што овде описујем звучи као А/Б анализа утицаја инфраструктурних промена у многим службама користећи резултате трагова, онда нисте превише далеко од истине.

Закључак

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

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

Биће потребан значајан ментални напор да се дизајнира систем који ће представљати различите сигнале доступне у резултатима праћења на начин који је оптимизован за лакшу анализу и закључивање. Морате да размислите о томе како да апстрахујете топологију система током отклањања грешака на начин који помаже кориснику да превазиђе слепе тачке без гледања појединачних трагова или распона.

Потребне су нам добре могућности апстракције и слојева (нарочито у корисничком интерфејсу). Оне које би се добро уклопиле у процес отклањања грешака вођен хипотезама где можете итеративно постављати питања и тестирати хипотезе. Они неће аутоматски решити све проблеме уочљивости, али ће помоћи корисницима да изоштре своју интуицију и формулишу паметнија питања. Позивам на промишљенији и иновативнији приступ визуелизацији. Овде постоји реална перспектива за проширење видика.

ПС од преводиоца

Прочитајте и на нашем блогу:

• «кубецтл-дебуг додатак за отклањање грешака у Кубернетес подовима";
• «Микроуслуге: Величина је важна, чак и ако имате Кубернетес";
• «Мониторинг и Кубернетес (преглед и видео извештај)'.

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