Забележка. превод: Авторът на този материал е Синди Шридхаран, инженер в imgix, който специализира в разработването на API и по-специално в тестването на микросервизи. В този материал тя споделя своята подробна визия за текущи проблеми в областта на разпределеното проследяване, където според нея липсват наистина ефективни инструменти за решаване на належащи проблеми.
[Илюстрация взета от относно разпределеното проследяване.]
Смята се, че труден за изпълнение и възвръщаемостта от него . Има много причини, поради които проследяването е проблематично, като често се цитира трудът, свързан с конфигурирането на всеки системен компонент, за да предава подходящите заглавки с всяка заявка. Въпреки че този проблем съществува, той в никакъв случай не е непреодолим. Между другото, това не обяснява защо разработчиците наистина не харесват проследяването (дори когато то вече функционира).
Основното предизвикателство при разпределеното проследяване не е събирането на данни, стандартизирането на формати за разпространение и представяне на резултатите или определянето кога, къде и как да се взема проба. Не се опитвам да си представям тривиален тези „проблеми с разбираемостта“ всъщност са доста значителни технически и (ако обмисляме наистина отворен код) ) политически предизвикателства, които трябва да бъдат преодолени, за да се считат тези проблеми за разрешени.
Въпреки това, ако си представим, че всички тези проблеми са решени, има голяма вероятност нищо да не се промени значително по отношение на опит на крайния потребител. Проследяването все още може да не е от практическа полза в най-често срещаните сценарии за отстраняване на грешки - дори след като е било внедрено.
Такава различна следа
Разпределеното проследяване включва няколко различни компонента:
- оборудване на приложения и мидълуер с контролни инструменти;
- пренос на разпределен контекст;
- събиране на следи;
- съхранение на следи;
- тяхното извличане и визуализиране.
Много разговори за разпределеното проследяване са склонни да го третират като един вид унарна операция, чиято единствена цел е да помогне за пълната диагностика на системата. Това до голяма степен се дължи на начина, по който идеите за разпределено проследяване са се формирали исторически. IN , направени по време на отварянето на Zipkin, беше споменато, че това [Zipkin] прави Twitter по-бърз. Първите търговски предложения за проследяване също бяха рекламирани като .
Забележка. превод: За да направим по-нататъшния текст по-лесен за разбиране, нека дефинираме два основни термина според :
- педя — основният елемент на разпределеното проследяване. Това е описание на определен работен процес (например заявка към база данни) с име, начален и краен час, тагове, регистрационни файлове и контекст.
- Участъците обикновено съдържат връзки към други участъци, което позволява комбинирането на множество участъци Следа — визуализация на живота на заявка, докато се движи през разпределена система.
Следите съдържат невероятно ценни данни, които могат да помогнат при задачи като производствено тестване, тестване за възстановяване след бедствие, тестване за инжектиране на грешки и др. Всъщност някои компании вече използват проследяване за подобни цели. Да започнем с има други приложения освен простото преместване на участъци към системата за съхранение:
- Например Uber проследяване на резултатите за разграничаване на тестов трафик от производствен трафик.
- Facebook данни за проследяване за анализ на критичен път и за превключване на трафик по време на редовни тестове за възстановяване след бедствие.
- Също така социална мрежа Преносими компютри Jupyter, които позволяват на разработчиците да изпълняват произволни заявки за резултати от проследяване.
- Последователи (Lineage Driven Failure Injection) разпределени следи за тестване с инжектиране на грешки.
Нито една от изброените по-горе опции не се отнася изцяло за сценария отстраняване на грешки, по време на който инженерът се опитва да реши проблема, като гледа следата.
Когато дойде още достига до скрипта за отстраняване на грешки, основният интерфейс остава диаграмата traceview (въпреки че някои също го наричат "Диаграма на Гант" или "диаграма на водопад"). Под traceview я всички участъци и придружаващите метаданни, които заедно съставляват трасирането. Всяка система за проследяване с отворен код, както и всяко търговско решение за проследяване, предлага a traceview потребителски интерфейс за визуализиране, детайлизиране и филтриране на следи.
Проблемът с всички системи за проследяване, които съм виждал досега, е, че резултатът визуализация (traceview) почти напълно отразява характеристиките на процеса на генериране на следи. Дори когато се предлагат алтернативни визуализации: топлинни карти, топологии на услуги, хистограми на латентност, те все още в крайна сметка се свеждат до traceview.
В миналото аз че повечето „иновации“ в UI/UX проследяването изглежда са ограничени до допълнителни метаданни в трасирането, инвестирайки в тях информация с висока кардиналност (висока кардиналност) или предоставяне на възможност за разбивка в конкретни участъци или изпълнение на заявки интер- и интра-следа... При това traceview остава основният инструмент за визуализация. Докато продължава това състояние на нещата, разпределеното проследяване (в най-добрия случай) ще заеме 4-то място като инструмент за отстраняване на грешки след метрики, регистрационни файлове и проследяване на стекове, а в най-лошия ще се окаже загуба на пари и време.
Проблем с traceview
съдба traceview — предоставя пълна картина на движението на една заявка през всички компоненти на разпределената система, към която е свързана. Някои по-усъвършенствани системи за проследяване ви позволяват да се задълбочите в отделни участъци и да видите разбивка във времето в един процес (когато участъците имат функционални граници).
Основната предпоставка на архитектурата на микроуслугите е идеята, че организационната структура расте с нуждите на компанията. Поддръжниците на микроуслугите твърдят, че разпределянето на различни бизнес задачи в отделни услуги позволява на малки, автономни екипи за разработка да контролират целия жизнен цикъл на такива услуги, като им дава възможност да изграждат, тестват и внедряват независимо тези услуги. Недостатъкът на това разпределение обаче е загубата на информация за това как всяка услуга взаимодейства с другите. В такива условия разпределеното проследяване се твърди, че е незаменим инструмент за отстраняване на грешки сложни взаимодействия между услугите.
Ако наистина , тогава нито един човек не е в състояние да го запази в главата си завършен снимка. Всъщност разработването на инструмент въз основа на предположението, че дори е възможно, е нещо като анти-модел (неефективен и непродуктивен подход). В идеалния случай отстраняването на грешки изисква инструмент, който помага стеснете областта на търсене, така че инженерите да могат да се съсредоточат върху подмножество от измерения (услуги/потребители/хостове и т.н.), свързани с разглеждания проблемен сценарий. Когато определят причината за повреда, от инженерите не се изисква да разбират какво се е случило по време на всички услуги наведнъж, тъй като подобно изискване би противоречало на самата идея за архитектура на микросервизи.
Traceview обаче е а именно Това. Да, някои системи за проследяване предлагат компресирани изгледи на проследяване, когато броят на обхватите в проследяването е толкова голям, че не могат да бъдат показани в една визуализация. Въпреки това, поради голямото количество информация, съдържаща се дори в такава съкратена визуализация, инженерите все още принуден „отсейте“ го, като стесните ръчно избора до набор от услуги, които са източници на проблеми. За съжаление в тази област машините са много по-бързи от хората, по-малко податливи на грешки и техните резултати са по-повтаряеми.
Друга причина, поради която смятам, че traceview е грешен, е, че не е добър за отстраняване на грешки, управлявано от хипотези. В основата си отстраняването на грешки е итеративен процес, започващ с хипотеза, последван от проверка на различни наблюдения и факти, получени от системата по различни вектори, заключения/обобщения и по-нататъшна оценка на истинността на хипотезата.
Възможност бързо и евтино тестване на хипотези и съответно подобряване на умствения модел е крайъгълен камък отстраняване на грешки Всеки инструмент за отстраняване на грешки трябва да бъде интерактивен и стеснете пространството за търсене или, в случай на фалшива следа, позволете на потребителя да се върне назад и да се съсредоточи върху друга област от системата. Перфектният инструмент ще направи това проактивно, незабавно привличайки вниманието на потребителя към потенциални проблемни области.
уви, traceview не може да се нарече инструмент с интерактивен интерфейс. Най-доброто, на което можете да се надявате, когато го използвате, е да намерите някакъв източник на повишена латентност и да разгледате всички възможни етикети и регистрационни файлове, свързани с него. Това не помага на инженера да идентифицира модели в трафика, като например спецификата на разпределението на закъснението, или откриване на корелации между различни измервания. може да помогне за преодоляване на някои от тези проблеми. Наистина ли, успешен анализ с помощта на машинно обучение за идентифициране на аномални участъци и идентифициране на подгрупа от тагове, които могат да бъдат свързани с аномално поведение. Все още обаче не съм виждал завладяващи визуализации на констатациите за машинно обучение или извличане на данни, приложени към участъци, които са значително различни от traceview или DAG (насочена ациклична графика).
Разстоянията са твърде ниско ниво
Основният проблем с traceview е, че обхваща са примитиви на твърде ниско ниво както за анализ на латентността, така и за анализ на първопричината. Това е като да анализирате индивидуални команди на процесора, за да се опитате да разрешите изключение, знаейки, че има инструменти от много по-високо ниво като обратно проследяване, с които е много по-удобно да се работи.
Освен това ще си позволя да твърдя следното: в идеалния случай нямаме нужда пълна картина възникнали по време на жизнения цикъл на заявката, който е представен от модерни инструменти за проследяване. Вместо това е необходима някаква форма на абстракция от по-високо ниво, която съдържа информация за какво се обърка (подобно на backtrace), заедно с някакъв контекст. Вместо да гледам цялата следа, предпочитам да я видя часть, където се случва нещо интересно или необичайно. В момента търсенето се извършва ръчно: инженерът получава следата и независимо анализира участъците в търсене на нещо интересно. Подходът на хората, които се взират в участъци в отделни следи с надеждата да открият подозрителна дейност, изобщо не се мащабира (особено когато трябва да осмислят всички метаданни, кодирани в различни участъци, като идентификатор на участък, име на RPC метод, продължителност на участъка 'a, регистрационни файлове, тагове и т.н.).
Алтернативи на traceview
Резултатите от проследяването са най-полезни, когато могат да бъдат визуализирани по начин, който предоставя нетривиална представа за това, което се случва във взаимосвързаните части на системата. Докато това се случи, процесът на отстраняване на грешки до голяма степен остава инертен и зависи от способността на потребителя да забележи правилните корелации, да провери правилните части на системата или да сглоби парчетата от пъзела - за разлика от инструмент, помагайки на потребителя да формулира тези хипотези.
Не съм визуален дизайнер или UX специалист, но в следващия раздел искам да споделя няколко идеи как могат да изглеждат тези визуализации.
Съсредоточете се върху конкретни услуги
Във време, когато индустрията се консолидира около идеи , изглежда разумно отделните екипи да дадат приоритет на гарантирането, че техните услуги са съобразени с тези цели. Следва, че ориентирани към услугите визуализацията е най-подходяща за такива екипи.
Следите, особено без вземане на проби, са съкровищница от информация за всеки компонент на разпределена система. Тази информация може да бъде подадена на хитър процесор, който ще доставя на потребителите ориентирани към услугите Те могат да бъдат идентифицирани предварително - дори преди потребителят да погледне следите:
- Диаграми на разпределение на латентността само за силно изявени заявки (извънредни заявки);
- Диаграми на разпределение на закъснението за случаите, когато целите на услугата SLO не са постигнати;
- Най-често срещаните, „интересни“ и „странни“ тагове в заявките, които най-често се повтарят;
- Разбивка на латентността за случаите, когато в зависимост от услугите не постигат своите SLO цели;
- Разбивка на латентността за различни услуги надолу по веригата.
Някои от тези въпроси просто не намират отговор от вградените показатели, което принуждава потребителите да преглеждат внимателно диапазоните. В резултат на това имаме изключително враждебен за потребителите механизъм.
Това повдига въпроса: какво ще кажете за сложните взаимодействия между различни услуги, контролирани от различни екипи? не е ли traceview не се счита за най-подходящия инструмент за подчертаване на такава ситуация?
Мобилните разработчици, собствениците на услуги без състояние, собствениците на управлявани услуги със състояние (като бази данни) и собствениците на платформи може да се интересуват от нещо друго представяне разпределена система; traceview е твърде общо решение за тези фундаментално различни нужди. Дори в много сложна микросервизна архитектура собствениците на услуги не се нуждаят от задълбочени познания за повече от две или три услуги нагоре и надолу по веригата. По същество в повечето сценарии потребителите трябва само да отговарят на въпроси относно ограничен набор от услуги.
Това е като да гледате малка част от услуги през лупа, за да ги разгледате внимателно. Това ще позволи на потребителя да задава по-належащи въпроси относно сложните взаимодействия между тези услуги и техните непосредствени зависимости. Това е подобно на обратното проследяване в света на услугите, където инженерът знае че погрешно и също така има известна представа какво се случва в околните услуги, за да разбере защо.
Подходът, който насърчавам, е точно обратното на подхода отгоре надолу, базиран на traceview, при който анализът започва с цялата трасировка и след това постепенно преминава към отделни участъци. За разлика от това, подходът отдолу нагоре започва с анализиране на малка област близо до потенциалната причина за инцидента и след това разширява пространството за търсене, ако е необходимо (с потенциала за привличане на други екипи за анализ на по-широка гама от услуги). Вторият подход е по-подходящ за бързо тестване на първоначални хипотези. След като бъдат получени конкретни резултати, ще може да се премине към по-целенасочен и подробен анализ.
Изграждане на топология
Изгледите, специфични за услугата, могат да бъдат изключително полезни, ако потребителят знае който услуга или група от услуги е отговорна за увеличаване на латентността или причиняване на грешки. Въпреки това, в сложна система, идентифицирането на нарушаващата услуга може да бъде нетривиална задача по време на повреда, особено ако не са докладвани съобщения за грешка от услугите.
Изграждането на топология на услугата може да бъде голяма помощ при установяването на коя услуга се наблюдава скок в процента на грешки или увеличаване на латентността, което причинява забележимо влошаване на услугата. Когато говоря за изграждане на топология, нямам предвид карта на услугите, показващ всяка услуга, налична в системата и известна със своите . Този изглед не е по-добър от traceview, базиран на насочена ациклична графика. Вместо това бих искал да видя динамично генерирана топология на услугата, въз основа на определени атрибути като честота на грешки, време за реакция или всеки дефиниран от потребителя параметър, който помага да се изясни ситуацията с конкретни подозрителни услуги.
Да вземем пример. Нека си представим хипотетичен новинарски сайт. Услуга за начална страница (първа страница) обменя данни с Redis, с услуга за препоръки, с рекламна услуга и видео услуга. Видео услугата взема видеоклипове от S3 и метаданни от DynamoDB. Услугата за препоръки получава метаданни от DynamoDB, зарежда данни от Redis и MySQL и пише съобщения до Kafka. Рекламната услуга получава данни от MySQL и пише съобщения до Kafka.
По-долу е схематично представяне на тази топология (много търговски програми за маршрутизиране изграждат топологията). Може да бъде полезно, ако трябва да разберете зависимостите на услугата. Въпреки това по време на отстраняване на грешки, когато определена услуга (да речем видео услуга) показва увеличено време за реакция, такава топология не е много полезна.
Сервизна схема на хипотетичен новинарски сайт
Диаграмата по-долу би била по-подходяща. Има проблем с услугата (видео) изобразен точно в центъра. Потребителят го забелязва веднага. От тази визуализация става ясно, че видео услугата работи необичайно поради увеличаване на времето за реакция на S3, което се отразява на скоростта на зареждане на част от главната страница.
Динамична топология, показваща само „интересни“ услуги
Динамично генерираните топологии могат да бъдат по-ефективни от картите на статичните услуги, особено в еластични инфраструктури с автоматично мащабиране. Възможността за сравняване и контрастиране на топологии на услуги позволява на потребителя да задава по-подходящи въпроси. По-точните въпроси за системата е по-вероятно да доведат до по-добро разбиране на това как работи системата.
Сравнителен дисплей
Друга полезна визуализация би била сравнителен дисплей. Понастоящем следите не са много подходящи за паралелни сравнения, така че сравненията обикновено са обхваща. И основната идея на тази статия е именно, че обхватите са твърде ниско ниво, за да извлекат най-ценната информация от резултатите от проследяването.
Сравняването на две следи не изисква принципно нови визуализации. Всъщност е достатъчно нещо като хистограма, представяща същата информация като traceview. Изненадващо, дори този прост метод може да донесе много повече плодове от простото изучаване на две следи поотделно. Още по-мощна би била възможността визуализирайте сравнение на следи Общо. Би било изключително полезно да се види как наскоро внедрена промяна в конфигурацията на базата данни, за да се активира GC (събиране на боклук), влияе върху времето за реакция на услуга надолу по веригата в мащаб от няколко часа. Ако това, което описвам тук, звучи като A/B анализ на въздействието на промените в инфраструктурата в много услуги като използвате резултатите от проследяването, тогава не сте твърде далеч от истината.
Заключение
Не поставям под съмнение полезността на самото проследяване. Искрено вярвам, че няма друг метод за събиране на данни, толкова богати, причинно-следствени и контекстуални, колкото тези, съдържащи се в следа. Въпреки това вярвам също, че всички решения за проследяване използват тези данни изключително неефективно. Докато инструментите за проследяване остават блокирани в представянето на traceview, те ще бъдат ограничени в способността си да се възползват максимално от ценната информация, която може да бъде извлечена от данните, съдържащи се в проследяванията. Освен това съществува риск от по-нататъшно развитие на напълно недружелюбен и неинтуитивен визуален интерфейс, който силно ще ограничи способността на потребителя да отстранява грешки в приложението.
Отстраняването на грешки в сложни системи, дори с най-новите инструменти, е невероятно трудно. Инструментите трябва да помогнат на разработчика да формулира и тества хипотеза, активно предоставяне подходяща информация, идентифициране на отклонения и отбелязване на характеристики в разпределението на закъсненията. За да се превърне проследяването в инструмент на избор за разработчиците при отстраняване на неизправности в производството или решаване на проблеми, които обхващат множество услуги, са необходими оригинални потребителски интерфейси и визуализации, които са по-съвместими с умствения модел на разработчиците, които създават и управляват тези услуги.
Ще са необходими значителни умствени усилия за проектиране на система, която ще представя различните сигнали, налични в резултатите от проследяването, по начин, който е оптимизиран за улесняване на анализа и извода. Трябва да помислите как да абстрахирате топологията на системата по време на отстраняване на грешки по начин, който помага на потребителя да преодолее слепите петна, без да гледа отделни следи или участъци.
Имаме нужда от добри възможности за абстракция и наслояване (особено в потребителския интерфейс). Такива, които биха се вписали добре в процес на отстраняване на грешки, управляван от хипотези, където можете итеративно да задавате въпроси и да тествате хипотези. Те няма да решат автоматично всички проблеми с видимостта, но ще помогнат на потребителите да изострят интуицията си и да формулират по-умни въпроси. Призовавам за по-обмислен и иновативен подход към визуализацията. Тук има реална перспектива за разширяване на хоризонтите.
PS от преводача
Прочетете също в нашия блог:
- «»;
- «»;
- «".
Източник: www.habr.com