Забелешка. превод.: Авторот на овој материјал е Синди Сридхаран, инженер во imgix која е специјализирана за развој на API и особено за тестирање на микросервис. Во овој материјал, таа ја споделува својата детална визија за актуелните проблеми во областа на дистрибуираното следење, каде што, според неа, недостигаат вистински ефективни алатки за решавање на итни проблеми.
[Илустрацијата е преземена од за дистрибуираното следење.]
Се верува дека тешко да се имплементира, и враќањето на тоа . Постојат многу причини зошто следењето е проблематично, честопати наведувајќи го трудот вклучен во конфигурирањето на секоја компонента на системот за пренос на соодветните заглавија со секое барање. Иако овој проблем постои, тој во никој случај не е несовладлив. Патем, тоа не објаснува зошто на програмерите навистина не им се допаѓа следењето (дури и кога веќе функционира).
Главниот предизвик со дистрибуираното следење не е собирање податоци, стандардизирање на формати за дистрибуирање и прикажување резултати или одредување кога, каде и како да се зема примерокот. Не се обидувам да замислам тривијални овие „проблеми со разбирливост“ се, всушност, доста значајни технички и (ако размислуваме за вистински отворен код) ) политички предизвици кои треба да се надминат за да се сметаат за решени овие проблеми.
Меѓутоа, ако замислиме дека сите овие проблеми се решени, постои голема веројатност дека ништо нема значително да се промени во однос на искуство на крајниот корисник. Следењето можеби сè уште не е од практична употреба во најчестите сценарија за дебагирање - дури и откако ќе биде распоредено.
Толку поинаква трага
Дистрибуираното следење вклучува неколку различни компоненти:
- опремување на апликации и среден софтвер со контролни алатки;
- дистрибуиран контекст на трансфер;
- собирање на траги;
- складирање на траги;
- нивно извлекување и визуелизација.
Многу разговори за дистрибуираното трагање имаат тенденција да го третираат како еден вид унирна операција чија единствена цел е да помогне во целосно дијагностицирање на системот. Ова во голема мера се должи на тоа како историски се формирале идеите за дистрибуираното следење. ВО , направена кога се отворија изворите на Zipkin, беше споменато дека тоа [Zipkin] го прави Твитер побрз. Беа промовирани и првите комерцијални понуди за следење како .
Забелешка. превод.: За понатамошниот текст да биде полесно разбирлив, да дефинираме два основни поими според :
- Век — основниот елемент на дистрибуираното трасирање. Тоа е опис на одреден работен тек (на пример, барање за базата на податоци) со име, време на почеток и крај, ознаки, дневници и контекст.
- Распоните обично содржат врски до други распони, овозможувајќи повеќекратни распони да се комбинираат во Рута — визуелизација на животот на барањето додека се движи низ дистрибуиран систем.
Трагите содржат неверојатно вредни податоци кои можат да помогнат при задачи како што се тестирање на производството, тестирање за враќање при катастрофи, тестирање за вбризгување на грешки итн. Всушност, некои компании веќе користат следење за слични цели. Да почнеме со има и други намени освен едноставното преместување на распони до системот за складирање:
- На пример, Uber следење на резултатите за да се направи разлика помеѓу тест сообраќај и производствен сообраќај.
- Facebook податоци за трага за анализа на критичните патеки и за префрлување на сообраќајот за време на редовните тестови за враќање при катастрофи.
- Исто така социјална мрежа Jupyter тетратки кои им овозможуваат на програмерите да извршуваат произволни прашања за резултатите од трага.
- Следбеници (Вбризгување со неуспех со помош на линија) дистрибуирани траги за тестирање со вбризгување на грешка.
Ниту една од опциите наведени погоре не се однесува целосно на сценариото дебагирање, при што инженерот се обидува да го реши проблемот со гледање на трагата.
Кога доаѓа уште стигнува до скриптата за дебагирање, примарниот интерфејс останува дијаграмот приказ на трага (иако некои го нарекуваат и „Гант шема“ или „дијаграм на водопад“). Под приказ на трага я сите распони и придружни метаподатоци кои заедно ја сочинуваат трагата. Секој систем за следење со отворен код, како и секое комерцијално решение за следење, нуди a приказ на трага кориснички интерфејс за визуелизација, детализирање и филтрирање на траги.
Проблемот со сите системи за следење што ги видов досега е тоа што резултира визуелизација (поглед на трага) речиси целосно ги одразува карактеристиките на процесот на генерирање траги. Дури и кога се предлагаат алтернативни визуелизации: топлински мапи, сервисни топологии, хистограми на латентност, тие сепак на крајот се сведуваат на приказ на трага.
Во минатото јас се чини дека повеќето „иновации“ во следењето на UI/UX се ограничени на дополнителни метаподатоци во трага, инвестирајќи во нив информации со висока кардиналност (висока кардиналност) или обезбедување на можност за продлабочување на одредени распони или извршување на прашања интер- и интра-трага... При што приказ на трага останува примарна алатка за визуелизација. Сè додека оваа состојба продолжува, дистрибуираното следење (во најдобар случај) ќе го заземе четвртото место како алатка за дебагирање, по метриката, логовите и трагите на стек, а во најлош случај ќе испадне губење пари и време.
Проблем со приказ на трага
Цел приказ на трага — да обезбеди целосна слика за движењето на едно барање низ сите компоненти на дистрибуираниот систем со кој е поврзано. Некои понапредни системи за следење ви дозволуваат да продлабочите во поединечни распони и да гледате дефект со текот на времето внатре еден процес (кога распоните имаат функционални граници).
Основната премиса на микросервисната архитектура е идејата дека организациската структура расте со потребите на компанијата. Застапниците на микросервисите тврдат дека дистрибуирањето на различни деловни задачи во поединечни услуги им овозможува на малите, автономни развојни тимови да го контролираат целиот животен циклус на таквите услуги, давајќи им можност самостојно да ги градат, тестираат и распоредуваат тие услуги. Сепак, недостаток на оваа дистрибуција е губењето на информации за тоа како секоја услуга комуницира со другите. Во такви услови, дистрибуираното следење тврди дека е неопходна алатка за дебагирање сложени интеракции помеѓу услугите.
Ако навистина , тогаш ниту еден човек не може да го задржи во главата заврши слика. Всушност, развивањето алатка заснована на претпоставката дека тоа е дури и можно е нешто како анти-шаблон (неефикасен и непродуктивен пристап). Идеално, дебагирањето бара алатка која помага стеснете ја вашата област за пребарување, така што инженерите можат да се фокусираат на подмножество димензии (услуги/корисници/домаќини итн.) релевантни за сценариото на проблемот што се разгледува. При утврдување на причината за дефект, од инженерите не се бара да разберат што се случило за време на сите услуги одеднаш, бидејќи таквото барање би било во спротивност со самата идеја за архитектура на микросервис.
Сепак, traceview е имено Ова. Да, некои системи за следење нудат компресирани прегледи на трага кога бројот на распони во трагата е толку голем што тие не можат да се прикажат во една визуелизација. Сепак, поради големата количина на информации содржани дури и во таквата соголена визуелизација, инженерите сè уште принудени „просеј“ го, рачно стеснувајќи го изборот на збир на услуги кои се извори на проблеми. За жал, на ова поле, машините се многу побрзи од луѓето, помалку склони кон грешки, а нивните резултати се повеќе повторливи.
Друга причина зошто мислам дека traceview е погрешен е затоа што не е добар за дебагирање управувано од хипотези. Во неговото јадро, дебагирањето е итеративен процес кој започнува со хипотеза, проследен со верификација на различни опсервации и факти добиени од системот по различни вектори, заклучоци/генерализација и понатамошна проценка на вистинитоста на хипотезата.
Можност брзо и евтино тестирање на хипотези и подобрување на менталниот модел соодветно е камен-темелник дебагирање Секоја алатка за дебагирање треба да биде интерактивни и стеснете го просторот за пребарување или, во случај на лажно водство, дозволете му на корисникот да се врати назад и да се фокусира на друга област од системот. Совршената алатка ќе го направи ова проактивно, веднаш привлекувајќи го вниманието на корисникот на потенцијалните проблематични области.
За жал, приказ на трага не може да се нарече алатка со интерактивен интерфејс. Најдоброто на што можете да се надевате кога го користите е да пронајдете некој извор на зголемена латентност и да ги погледнете сите можни ознаки и дневници поврзани со него. Ова не му помага на инженерот да се идентификува обрасци во сообраќајот, како што се спецификите на дистрибуцијата на доцнење, или откривање на корелации помеѓу различни мерења. може да помогне да се заобиколат некои од овие проблеми. Навистина, успешна анализа со користење на машинско учење за да се идентификуваат аномалните распони и да се идентификува подмножество ознаки кои може да се поврзат со аномално однесување. Сепак, допрва треба да видам привлечни визуелизации на наодите за машинско учење или за ископување податоци применети на распони кои се значително различни од прегледот на трага или DAG (насочен ацикличен график).
Распоните се премногу ниски
Основниот проблем со traceview е тоа се протега се примитиви на премногу ниско ниво и за анализа на латентност и за анализа на основната причина. Тоа е како парсирање на поединечни команди на процесорот за да се обиде да реши исклучок, знаејќи дека има алатки на многу повисоко ниво како backtrace со кои се многу попогодни за работа.
Освен тоа, ќе си земам слобода да го тврдам следново: идеално, не ни треба целосна слика се случи за време на животниот циклус на барањето, што е претставено со современи алатки за следење. Наместо тоа, потребна е некаква форма на апстракција на повисоко ниво која содржи информации за што тргна наопаку (слично на backtrace), заедно со одреден контекст. Наместо да ја гледам целата трага, претпочитам да ја видам часть, каде што се случува нешто интересно или необично. Во моментов, пребарувањето се врши рачно: инженерот ја прима трагата и самостојно ги анализира распоните во потрага по нешто интересно. Пристапот на луѓе кои зјапаат во распони во поединечни траги со надеж дека ќе откријат сомнителна активност воопшто не се зголемува (особено кога треба да ги разберат сите метаподатоци кодирани во различни распони, како што се ID на распон, име на методот RPC, времетраење на распонот 'a, дневници, ознаки, итн.).
Алтернативи за преглед на трага
Резултатите од трага се најкорисни кога може да се визуелизираат на начин кој обезбедува нетривијален увид во она што се случува во меѓусебно поврзаните делови на системот. Додека тоа не се случи, процесот на дебагирање во голема мера останува инертен и зависи од способноста на корисникот да ги забележи правилните корелации, да ги провери вистинските делови од системот или да ги спои деловите од сложувалката - наспроти алатка, помагајќи му на корисникот да ги формулира овие хипотези.
Јас не сум визуелен дизајнер или специјалист за UX, но во следниот дел сакам да споделам неколку идеи за тоа како би можеле да изгледаат овие визуелизации.
Фокусирајте се на конкретни услуги
Во време кога индустријата се консолидира околу идеите , се чини разумно поединечните тимови да дадат приоритет на обезбедувањето нивните услуги да се усогласат со овие цели. Го следи тоа сервисно ориентиран визуелизацијата најдобро одговара за такви тимови.
Трагите, особено без земање примероци, се ризница на информации за секоја компонента на дистрибуираниот систем. Оваа информација може да се внесе до лукав процесор кој ќе ги снабдува корисниците сервисно ориентиран наоди Тие можат да се идентификуваат однапред - дури и пред корисникот да ги погледне трагите:
- Дијаграми за дистрибуција на латентност само за многу истакнати барања (надворешни барања);
- Дијаграми на доцнење дистрибуција за случаи кога не се постигнати целите на услугата SLO;
- Најчести, „интересни“ и „чудни“ ознаки во прашањата кои најчесто се повторуваат;
- Расчленување на латентност за случаи кога зависности услугите не ги постигнуваат своите цели за SLO;
- Распределба на латентност за различни услуги надолу.
Некои од овие прашања едноставно не се одговорени со вградени метрики, што ги принудува корисниците внимателно да ги проверат распоните. Како резултат на тоа, имаме механизам екстремно непријателски настроен кон корисниците.
Ова го покренува прашањето: што е со сложените интеракции помеѓу различни услуги контролирани од различни тимови? нели приказ на трага не се смета за најсоодветна алатка за истакнување на таква ситуација?
Мобилни програмери, сопственици на услуги без државјанство, сопственици на управувани државни услуги (како бази на податоци) и сопственици на платформи може да бидат заинтересирани за нешто друго презентација дистрибуиран систем; приказ на трага е премногу генеричко решение за овие фундаментално различни потреби. Дури и во многу сложена микросервисна архитектура, на сопствениците на услуги не им е потребно длабоко познавање на повеќе од две или три услуги нагоре и надолу. Во суштина, во повеќето сценарија, корисниците треба само да одговорат на прашања во врска со ограничен сет на услуги.
Тоа е како да гледате мала подгрупа на услуги преку лупа за да ја прегледате. Ова ќе му овозможи на корисникот да поставува поитни прашања во врска со сложените интеракции помеѓу овие услуги и нивните непосредни зависности. Ова е слично на назад во светот на услугите, каде што инженерот знае дека погрешно, а исто така има одредено разбирање за тоа што се случува во околните услуги за да разбере зошто.
Пристапот што го промовирам е сосема спротивен од пристапот од врвот надолу, базиран на преглед на трага, каде што анализата започнува со целата трага, а потоа постепено се сведува на поединечни распони. Спротивно на тоа, пристапот одоздола нагоре започнува со анализа на мала област блиску до потенцијалната причина за инцидентот, а потоа го проширува просторот за пребарување по потреба (со потенцијал да се доведат други тимови за да анализираат поширок опсег на услуги). Вториот пристап е подобро прилагоден за брзо тестирање на почетните хипотези. Откако ќе се добијат конкретни резултати, ќе може да се премине на подетална и насочена анализа.
Изградба на топологија
Погледите специфични за услугата можат да бидат неверојатно корисни ако корисникот знае што услуга или група на услуги е одговорна за зголемување на латентноста или предизвикување грешки. Меѓутоа, во сложен систем, идентификувањето на услугата која навредува може да биде нетривијална задача за време на дефект, особено ако не биле пријавени пораки за грешка од услугите.
Изградбата на сервисна топологија може да биде голема помош за да се открие која услуга доживува скок во стапките на грешки или зголемување на латентноста што предизвикува значително деградирање на услугата. Кога зборувам за градење топологија, не мислам карта на услуги, прикажувајќи ја секоја услуга достапна во системот и позната по својата . Овој приказ не е подобар од приказ на трага врз основа на насочен ацикличен график. Наместо тоа, би сакал да видам динамички генерирана сервисна топологија, врз основа на одредени атрибути како стапка на грешка, време на одговор или кој било параметар дефиниран од корисникот кој помага да се разјасни ситуацијата со специфични сомнителни услуги.
Да земеме пример. Ајде да замислиме хипотетички сајт за вести. Услуга на почетната страница (Насловна страна) разменува податоци со Редис, со услуга за препораки, со услуга за рекламирање и видео услуга. Видео сервисот презема видеа од S3 и метаподатоци од DynamoDB. Услугата за препораки прима метаподатоци од DynamoDB, вчитува податоци од Redis и MySQL и пишува пораки до Кафка. Рекламната услуга добива податоци од MySQL и му пишува пораки на Кафка.
Подолу е шематски приказ на оваа топологија (многу комерцијални програми за рутирање ја градат топологијата). Може да биде корисно ако треба да ги разберете зависностите на услугите. Меѓутоа, за време на дебагирање, кога одредена услуга (да речеме, видео услуга) покажува зголемено време на одговор, таквата топологија не е многу корисна.
Сервисен дијаграм на хипотетички сајт за вести
Дијаграмот подолу ќе биде подобро прилагоден. Има проблем со услугата (Видео) прикажан токму во центарот. Корисникот веднаш го забележува. Од оваа визуелизација, станува јасно дека видео услугата работи ненормално поради зголемување на времето на одговор на S3, што влијае на брзината на вчитување на дел од главната страница.
Динамичка топологија прикажува само „интересни“ услуги
Динамички генерираните топологии можат да бидат поефикасни од статичните сервисни мапи, особено во еластични инфраструктури со автоматско скалирање. Способноста за споредба и контраст на сервисните топологии му овозможува на корисникот да поставува порелевантни прашања. Попрецизните прашања за системот имаат поголема веројатност да доведат до подобро разбирање за тоа како функционира системот.
Компаративен приказ
Друга корисна визуелизација ќе биде компаративен приказ. Во моментов, трагите не се многу погодни за споредби рамо до рамо, така што споредбите обично се се протега. И главната идеја на овој напис е токму тоа што распоните се премногу ниски за да се извлечат највредните информации од резултатите од трагите.
Споредувањето на две траги не бара фундаментално нови визуелизации. Всушност, доволно е нешто како хистограм што ги претставува истите информации како преглед на трага. Изненадувачки, дури и овој едноставен метод може да донесе многу повеќе плодови отколку едноставно проучување на две траги одделно. Уште помоќна би била можноста визуелизира споредба на траги Во целост. Би било исклучително корисно да се види како неодамна распоредената промена на конфигурацијата на базата на податоци за да се овозможи GC (собирање ѓубре) влијае на времето на одговор на услугата низводно на размер од неколку часа. Ако ова што го опишувам овде звучи како A/B анализа на влијанието на промените во инфраструктурата во многу услуги користејќи ги резултатите од трагата, тогаш не сте премногу далеку од вистината.
Заклучок
Не ја доведувам во прашање корисноста на самото трасирање. Искрено верувам дека не постои друг метод за собирање податоци толку богат, причински и контекстуален како оној содржан во трага. Сепак, јас исто така верувам дека сите решенија за следење ги користат овие податоци крајно неефикасно. Сè додека алатките за следење остануваат заглавени на претставата за следење, тие ќе бидат ограничени во нивната способност да ги искористат максимум вредните информации што можат да се извлечат од податоците содржани во трагите. Покрај тоа, постои ризик од понатамошен развој на целосно непријателски и неинтуитивен визуелен интерфејс кој сериозно ќе ја ограничи способноста на корисникот да ги решава грешките во апликацијата.
Дебагирањето на сложените системи, дури и со најновите алатки, е неверојатно тешко. Алатките треба да му помогнат на развивачот да формулира и тестира хипотеза, активно обезбедувајќи релевантни информации, идентификување на оддалечените и забележувајќи карактеристики во распределбата на доцнењата. За следењето да стане алатка на избор за програмерите кога се решаваат проблеми во производството или се решаваат проблеми кои опфаќаат повеќе услуги, потребни се оригинални кориснички интерфејси и визуелизации кои се поконзистентни со менталниот модел на програмерите кои ги создаваат и управуваат со тие услуги.
Ќе биде потребен значителен ментален напор за да се дизајнира систем кој ќе ги претставува различните сигнали достапни во резултатите од трагата на начин што е оптимизиран за леснотија на анализа и заклучување. Треба да размислите како да ја апстрахирате системската топологија при дебагирање на начин што ќе му помогне на корисникот да ги надмине слепите точки без да гледа поединечни траги или распони.
Ни требаат добри способности за апстракција и слоевитост (особено во UI). Оние кои добро би се вклопиле во процес на дебагирање управуван од хипотези каде што можете повторливо да поставувате прашања и да тестирате хипотези. Тие нема автоматски да ги решат сите проблеми со набљудувањето, но ќе им помогнат на корисниците да ја изостри својата интуиција и да формулираат попаметни прашања. Повикувам на попромислен и иновативен пристап кон визуелизацијата. Овде постои реална перспектива за проширување на хоризонтите.
PS од преведувач
Прочитајте и на нашиот блог:
- «";
- «";
- «".
Извор: www.habr.com