Прим. прев.: Автор на този материал е Cindy Sridharan, инженер от компанията imgix, която се занимава с разработка на API и по-специално с тестване на микросервизи. В този материал тя споделя своето обширно виждане за актуалните проблеми в областта на разпределеното проследяване, където, според нея, съществува недостиг на наистина ефективни инструменти за справяне с належащите задачи.
[Илюстрация, заимствана от за разпределеното проследяване.]
Счита се, че е трудно за внедряване, а ползите от него . „Проблемността“ на проследяването се обяснява с множество причини, като често се налага трудността при настройката на всеки компонент на системата за предаване на съответните заглавия с всяко запитване. Въпреки че този проблем наистина съществува, той не може да се нарече непреодолим. Като че ли не обяснява защо разработчиците не обичат особено проследяването (дори когато то вече функционира).
Основната трудност с разпределеното проследяване не е събирането на данни, не е стандартизацията на форматите за разпространение и представяне на резултатите и не е определянето на това кога, къде и как да се прави выбора. Не се опитвам да представя тривиални тези „проблеми с усвояемостта“ — всъщност, съществуват доста значими технически и (ако разгледаме наистина Open Source стандарти и протоколи) политически предизвикателства, които трябва да бъдат преодолени, за да може тези проблеми да се считат за решени. опита на крайния потребител
. Проследяването все още може да не носи практическа полза в най-разпространените сценарии за отладка — дори след като е внедрено. Тази непохватна проследяванеРазпределеното проследяване включва няколко разпокъсани компонента:
оснащаване на приложения и middleware с контролни средства;
предаване на разпределен контекст;
- събиране на проследявания;
- съхраняване на проследявания;
- тяхното извличане и визуализация.
- основната трудност
- преди всичко е свързана с икономическата полза
Множество разговори за разпределеното проследяване се свеждат до разглеждането му като някаква унарна операция, чиято единствена цел е помощта при цялостната диагностика на системата. В много отношения това е свързано с начина, по който исторически са се формирали представите за разпределеното проследяване. , направена, когато бяха отворени изходните кодове на Zipkin, се споменава, че той [Zipkin] прави Twitter по-бърз. Първоначалните търговски предложения за проследяване също се представяха като .
Прим. прев.: За да бъде последващият текст по-добре възприеман, нека определим два основни термина според :
- Span — основният елемент на разпределеното проследяване. Представлява описание на някакъв работен процес (например, заявка към база данни) с име, време на започване и завършване, тагове, логове и контекст.
- Span-овете обикновено съдържат връзки към други span-ове, което позволява обединяването на множество span-ове в Trace — визуализация на живота на заявката по време на нейното движение в разпределената система.
Trace-овете съдържат изключително ценни данни, които могат да помогнат в такива задачи, като: тестване в производствени условия, провеждане на тестове за аварийно възстановяване, тестване с внедряване на грешки и т.н. Всъщност, някои компании вече използват проследяването за подобни цели. Нека започнем с това, че има и други приложения освен простото пренасяне на span-ове в системата за съхранение:
- Например, Uber резултатите от проследяването за разграничаване на тестовия трафик от производствения трафик.
- Facebook данни от trace-овете за анализ на критичния път и за пренасочване на трафика по време на редовни тестове за аварийно възстановяване.
- Също така социалната мрежа блокноти Jupyter, които позволяват на разработчиците да изпълняват произволни заявки върху резултатите от проследяването.
- Привържениците на (Внедряване на грешки посредством наследяване) разпределени trace-ове за тестване с внедряване на грешки.
Нито един от изброените по-горе варианти не се отнася изцяло до сценария за отстраняване на грешки, в който инженерът се опитва да реши проблема, разглеждайки trace-а.
Когато става все пак въпрос за сценария на отстраняване на грешки, основният интерфейс остава диаграмата traceview (въпреки че някои я наричат «диаграма Ганта» или «каскадна диаграма»). Под traceview аз всички span’ове и свързаните с тях метаданни, които заедно образуват trace. Всяка система за трасировка с отворен код, както и всяко търговско решение за трасировка, предлага основан на traceview потребителски интерфейс за визуализация, детайлизиране и филтриране на trace’ове.
Проблемът с всички системи за трасировка, с които съм се сблъскал до момента, е, че окончателната визуализация (traceview) практически напълно отразява особеностите на процеса на генериране на trace. Дори когато се предлагат алтернативни визуализации: карти на интензивността (heatmap), топологии на услугите, хистограми на закъснениия (latency), в крайна сметка те все пак водят до traceview.
В миналото аз за това, че повечето "иновации" в областта на трасировката относно UI/UX, изглежда, са ограничени до на допълнителни метаданни в trace, вграждането в тях на информация с висока кардиналност (high-cardinality) или предоставянето на възможност да се детайлизират конкретни span’ове или да се извършват заявки между и вътре в trace. В същото време traceview остава основното средство за визуализация. Докато подобно положение остава, разпределената трасировка ще заема (в най-добрия случай) четвърто място като инструмент за отстраняване на грешки, следващи метриките, логовете и stack trace’ите, а в най-лошия случай — ще се окаже просто загуба на пари и време.
Проблемът с traceview
Целта traceview е да предостави цялостна картина на движението на отделно запитване през всички компоненти на разпределената система, с които то е свързано. Някои по-напреднали системи за трасировка позволяват детайлизиране на отделни span’ове и преглед на разпределението по време вътре на един процес (когато span’овете имат функционални граници).
Основна предпоставка на архитектурата на микросервизите е идеята, че организационната структура расте заедно с нуждите на компанията. Привържениците на микросервизите твърдят, че разпределението на различни бизнес задачи между отделни услуги позволява на малки, автономни екипи от разработчици да контролират целия житейски цикъл на тези услуги, давайки им възможност независимо да създават, тестват и разгръщат тези услуги. Въпреки това недостатък на подобно разпределение е загубата на информация за това как всяка услуга взаимодействие с другите. При тези обстоятелства разпределеното проследяване претендира за роля на незаменим инструмент за за отстраняване на грешки сложни взаимодействия между услугите.
Ако наистина , то няма човек, който да може да задържи в ума си пълната картина. Всъщност, разработването на инструмент въз основа на предположението, че това изобщо е възможно, е нещо като антипатерн (неефективен и непродуктивен подход). В идеалния случай за отстраняването на проблеми е нужен инструмент, който помага да се стесни зоната на търсене, за да могат инженерите да се фокусират върху подмножество от измервания (услуги/потребители/хостове и т.н.), свързани със разглеждания сценарий на проблема. При установяване на причината за срив инженерите не трябва да се опитват да разберат какво се е случвало в всички услуги наведнъж, тъй като това изискване би противоречало на самата идея на микросервизната архитектура.
Въпреки това, traceview представлява точно това. Да, някои системи за проследяване предлагат компресирани traceview, когато броят на span-овете в trace е толкова голям, че не може да се визуализира в рамките на една визуализация. Въпреки това, заради голямото количество информация, съдържаща се дори в такава съкратена визуализация, инженерите пак са принудени "да пресеиват" нея, ръчно стеснявайки избора до набор от услуги-източници на проблемите. Уви, на това поприще машините значително превъзхождат човека, по-малко податливи на грешки, а резултатите им са по-повторяеми.
Още една причина, поради която смятам, че методът traceview е неправилен, е, че той слабо подхожда за отстраняване на проблеми в основата на хипотези. В същността си отстраняването на проблеми е итеративен процес, който започва с хипотеза, последвана от проверка на различни наблюдения и факти, получени от системата по различни направления, изводи/обобщения и последваща оценка на истинността на хипотезата.
Възможност за бързо и евтино тестуването на хипотези и съответното подобряване на менталния модел е основополагающ камък при отстраняването на проблеми. Всеки отстранителен инструмент трябва да бъде интерактивен и да стеснява пространството за търсене или, в случай на фалшив сигнал, да позволява на потребителя да се върне назад и да се фокусира върху друга област на системата. Идеалният инструмент ще прави това с предвидливост, веднага привличайки вниманието на потребителя към потенциално проблемни области.
За съжаление, traceview не може да се нарече инструмент с интерактивен интерфейс. Най-доброто, на което може да се надява при неговото използване, е да открие определен източник на повишени забавяния и да прегледа всевъзможни тагове и лога, свързани с него. Това не помага на инженера да идентифицира закономерности в трафика, като например специфика на разпределението на забавянията или да открие корелации между различни измервания. може да помогне да се преодолеят някои от тези проблеми. Всъщност, за успешен анализ с използване на машинно обучение за установяване на аномални span-и и идентификация на подмножество тагове, които могат да бъдат свързани с аномално поведение. Въпреки това, досега не съм срещал убедителни визуализации на находки, направени с помощта на машинно обучение или анализ на данни, приложени на span-ове, които да се отклоняват значително от traceview или DAG (насочен ацикличен граф).
Span-овете са твърде ниско ниво
Основният проблем с traceview е, че span-овете са твърде ниско ниво примитиви както за анализ на забавяния (latency), така и за анализ на основните причини. Това е същото като да се анализират отделни команди на процесора в опит да се отстрани изключение, знаейки, че съществуват много по-високо ниво инструменти, като backtrace, с които работата е значително по-удобна.
Освен това, ще си позволя да твърдя следното: в идеалния случай не ни е нужна пълна картина възникнал по време на жизнения цикъл на заявката, представен от съвременните инструменти за проследяване. Вместо това е необходима форма на абстракция на по-високо ниво, която предоставя информация за това, какво не е наред (по аналогия с backtrace), заедно с известен контекст. Вместо да наблюдавам целия след, предпочитам да виждам неговата част, където се случва нещо интересно или необичайно. В момента търсенето се извършва ръчно: инженерът получава следа и самостоятелно анализира span-овете в търсене на нещо интересно. Подходът, при който хората вглеждат в span-ове в отделни следи в надежда да открият подозрителна активност, абсолютно не е скалируем (особено когато им се налага да осмислят всичките метаданни, кодирани в различни span-ове, като span ID, име на RPC метод, продължителност на span-а, логове, тагове и т.н.).
Алтернативи на traceview
Резултатите от проследяването са най-полезни, когато могат да бъдат визуализирани по начин, който да предостави нетривиално представление за това, което се случва в взаимосвързаните части на системата. Докато това не е постигнато, процесът на отстраняване на грешки остава до голяма степен инертен и зависи от способността на потребителя да забелязва правилните корелации, да проверява верните части на системата или да събира парчетата от мозайката заедно — за разлика от инструмента, който помага на потребителя да формулира тези хипотези.
Не съм визуален дизайнер и не съм специалист по UX, но в следващия раздел искам да споделя няколко идеи за това как могат да изглеждат подобни визуализации.
Фокус върху конкретни услуги
В условия, при които индустрията се консолидира около идеите на , изглежда разумно, че отделните екипи трябва първо да следят спазването на техните услуги на тези цели. Оттук следва, че ориентирана към услуги визуализация е най-подходяща за такива екипи.
Следите, особено без извадка, са кладез на информация за всеки компонент на разпределена система. Тази информация може да бъде обработена от хитър обработващ модул, който ще предоставя на потребителите ориентирани към услуги находки. Те могат да бъдат открити предварително — още преди потребителят да се запознае със следите:
- Диаграми на разпределение на забавяния само за силно изразителни заявки (извънредни заявки);
- Диаграми на разпределение на забавяния за случаи, когато целите на SLO на услугата не се изпълняват;
- Най-„обичайни“, „интересни“ и „странни“ тагове в заявки, които най-често се повтарят;
- Разпределение на забавянията за случаи, когато зависимостите на услугата не достигат поставените цели на SLO;
- Разпределение на забавянията по различни нисши (downstream) услуги.
На някои от тези въпроси вградените метрики просто не могат да отговорят, принуждавайки потребителите да проучват внимателно span-овете. В края на краищата имаме изключително враждебен към потребителя механизъм.
В тази връзка възниква въпросът: какво ще стане с комплексните взаимодействия между различните услуги, контролирани от различни екипи? Не е ли traceview най-подходящият инструмент за осветление на подобна ситуация?
Мобилни разработчици, собственици на stateless услуги, собственици на управлявани stateful услуги (като бази данни) и собственици на платформи може да имат интерес към друга представяне на разпределената система; traceview — това е прекалено универсално решение за тези принципно различни нужди. Дори в много сложна микросервисна архитектура на собствениците на услуги не им трябват дълбоки познания за повече от две-три upstream и downstream услуги. Всъщност, в повечето сценарии на потребителите им е достатъчно да отговарят на въпроси, свързани с ограничен набор от услуги.
Това е подобно на разглеждането на малко подмножество от услуги през лупа с цел детайлно проучване. Това ще позволи на потребителя да задава по-належащи въпроси, свързани с комплексното взаимодействие между тези услуги и техните непосредствени зависимости. Това е аналогично на backtrace в света на услугите, където инженерът знае, какво не само как, а и има представа какво става в околните услуги, за да разбере, защо.
Предлаганият от мен подход е пълната противоположност на подхода „отгоре-надолу“, основан на traceview, където анализът започва с целия trace и след това постепенно се спуска до отделните span-ове. Напротив, подходът „отдолу-нагоре“ започва с анализа на малък участък, близък до потенциалната причина за инцидента, а след това пространството за търсене се разширява при необходимост (с възможно включване на други екипи за анализ на по-широк спектър от услуги). Вторият подход е по-добре пригоден за бърза проверка на начален хипотези. След получаване на конкретни резултати, ние можем да преминем към по-целенасочен и подробен анализ.
Изграждане на топология
Привързаните к конкретна услуга изгледи могат да бъдат невероятно полезни, ако потребителят знае, коя услуга или група услуги е отговорна за увеличените забавяния или е източник на грешки. Въпреки това, в сложна система, определянето на нарушаващата услуга може да се окаже нетривиална задача по време на повреда, особено ако съобщенията за грешки от услугите не са постъпвали.
Изграждането на топология на услугите може значително да помогне при определянето на коя услуга проявява скок в честотата на грешките или увеличение на забавянето, довеждащо до забележимо влошаване на работата на услугата. Когато говоря за изграждане на топология, нямам предвид карта на услугите, която показва всяка налична в системата услуга и е известна със своите . Такова представяне не е нищо повече от traceview, основано на насочен ацикличен граф. Вместо това бих искал да видя динамично генерирана топология на услугите, основана на определени атрибути, като честота на грешките, време за отговор или на какъвто и да е зададен от потребителя параметър, който помага да се изясни ситуацията с конкретни подозрителни услуги.
Нека да се обърнем към примера. Да си представим хипотетичен новинарски сайт. Услугата на главната страница (front page) обменя данни с Redis, с услугата за препоръки, с рекламната услуга и видеослужбата. Видеослужбата взема видеоклипове от S3, а метаданните — от DynamoDB. Услугата за препоръки получава метаданни от DynamoDB, зарежда данни от Redis и MySQL, пише съобщения в Kafka. Рекламната услуга получава данни от MySQL и пише съобщения в Kafka.
По-долу е показана схема на тази топология (много търговски програми за трасировка изграждат топологии). Тя може да е полезна, ако трябва да се разберат зависимостите между услугите. Въпреки това, по време на за отстраняване на грешки, когато определена услуга (да кажем, видеослужбата) демонстрира увеличено време за отговор, подобна топология не е особено полезна.
Схема на услугите на хипотетичен новинарски сайт
По-подходяща би била диаграмата, представена по-долу. На нея проблемната услуга (video) е показана точно в центъра. Потребителят веднага я забелязва. От тази визуализация става ясно, че видеослужбата работи аномално поради увеличеното време за отговор от S3, което влияе на скоростта на зареждане на част от главната страница.
Динамична топология, показваща само 'интересните' услуги
Динамично генерираните топологични схеми може да се окажат по-ефективни от статичните карти на услугите, особено в еластични, автоматично мащабируеми инфраструктури. Възможността за сравняване и противопоставяне на топологиите на услугите позволява на потребителя да задава по-актуални въпроси. По-точните въпроси за системата с по-голяма вероятност водят до по-добро разбиране на начина, по който работи системата.
Сравнително визуализиране
Още една полезна визуализация би била сравнителното визуализиране. В момента trace-овете не са много подходящи за сравнение един до друг, затова обикновено се сравняват span-овете. Основната идея на тази статия е, че span-овете са твърде нискоуровневи, за да извлекат най-ценната информация от резултатите от трасировката.
Сравнението на два trace-а не изисква принципно нови визуализации. Всъщност е достатъчно нещо като хистограма, представляваща същата информация, която и traceview. Удивително е, но дори и този прост метод може да донесе много повече ползи, отколкото просто да се изучават два trace-а поотделно. Още по-мощно би било възможността визуализирам сравнение на trace-ове в обобщение. Беше изключително полезно да видим как неотдавна внедрена промяна в конфигурацията на базата данни с включване на GC (събиране на боклука) влияе на времето за отговор на downstream услугата в течение на няколко часа. Ако това, което описвам тук, изглежда подобно на A/B анализ на влиянието на инфраструктурните промени в множество услуги чрез резултатите от трасировките, не сте твърде далеч от истината.
Заключение
Не поставям под съмнение полезността на самите трасировки. Напълно вярвам, че няма друг метод за събиране на толкова богати, казуални и контекстуални данни, както тези, съдържащи се в trace. Въпреки това, смятам, че всичките решения за трасировка използват тези данни изключително неефективно. Дотогава, докато инструментите за трасировка ще бъдат фокусирани върху представянето на traceview, те ще бъдат ограничени в способността си да максимално оползотворят ценната информация, която може да бъде извлечена от данните, съдържащи се в trace-овете. Освен това, съществува риск от по-нататъшно развитие на напълно недружелюбен и неинтуитивен визуален интерфейс, който значително ще ограничи способността на потребителя да отстранява грешки в приложението.
Отстраняването на сложни системи, дори с използването на най-новите инструменти, е невероятно трудно. Инструментите трябва да помагат на разработчика да формулира и тества хипотеза, активно предоставяйки релевантна информация, идентифицирайки изкривявания и отбелязвайки особености в разпределението на закъсненията. За да стане трасировката предпочитан инструмент за разработчиците при отстраняване на неизправности в производствена среда или решаване на проблеми, обхващащи различни услуги, са необходими оригинални потребителски интерфейси и визуализации, които по-добре отговарят на менталната модел на разработчиците, които създават и експлоатират тези услуги.
Ще са необходими сериозни умствени усилия, за да се проектира система, която ще представя различни сигнали, налични в резултатите от трасировката, по начин, оптимизиран за улесняване на анализа и умозаключенията. Необходимо е да се обмисли как да се абстрахира топологията на системата по време на отстраняване на грешки, така че да помага на потребителя да преодолява слепите зони, без да се налага да разглежда отделни trace’ове или span’ове.
Нуждаем се от добри възможности за абстрахиране и разделение на нива (особено в UI). Такива, които ще се впишат добре в процеса на отстраняване на грешки на базата на хипотези, където може итеративно да се задават въпроси и да се проверяват хипотези. Те няма да решат автоматично всички проблеми с наблюдаемостта, но ще помогнат на потребителите да усъвършенстват интуицията си и да формулират по-внимателни въпроси. Призовавам за по-обмислен и иновативен подход в областта на визуализацията. Има реална перспектива да се разширят хоризонтите.
P.S. от преводача
Прочетете също в нашия блог:
- «»;
- «»;
- «».
Източник: habr.com
