Ескерту. аударма: Бұл материалдың авторы Синди Сридхаран, API әзірлеуге және, атап айтқанда, микросервисті тестілеуге маманданған imgix инженері. Бұл материалда ол, оның пікірінше, өзекті мәселелерді шешудің шын мәнінде тиімді құралдарының жетіспейтін таратылған трасса саласындағы өзекті мәселелер туралы егжей-тегжейлі көзқарасымен бөліседі.
[Иллюстрация бөлінген бақылау туралы.]
Деп саналады жүзеге асыру қиын және одан қайтарым . Әр сұраумен сәйкес тақырыптарды жіберу үшін әр жүйе құрамдас бөлігін конфигурациялауға жұмсалған еңбекті жиі келтіре отырып, қадағалаудың проблемалы болуының көптеген себептері бар. Бұл мәселе бар болғанымен, оны шешу мүмкін емес. Айтпақшы, бұл әзірлеушілерге трассаны неліктен ұнатпайтынын түсіндірмейді (тіпті ол қазірдің өзінде жұмыс істеп тұрса да).
Бөлінген бақылаудың негізгі мәселесі деректерді жинау, нәтижелерді тарату және ұсыну пішімдерін стандарттау немесе қашан, қайда және қалай іріктеу керектігін анықтау емес. Мен елестетуге тырыспаймын тривиальды бұл «түсініктілік мәселелері» шын мәнінде өте маңызды техникалық және (егер біз шын мәнінде Ашық бастапқы кодты қарастыратын болсақ) ) бұл проблемалар шешілген деп есептелуі үшін еңсеру қажет саяси қиындықтар.
Алайда, егер біз осы мәселелердің барлығы шешілді деп елестетсек, онда айтарлықтай ештеңе өзгермейтіні жоғары. соңғы пайдаланушы тәжірибесі. Бақылау ең көп тараған отладтау сценарийлерінде (тіпті ол қолданылғаннан кейін де) практикалық тұрғыдан қолданылмауы мүмкін.
Мұндай басқа із
Бөлінген бақылау бірнеше бөлек құрамдастарды қамтиды:
- қолданбалы және аралық құралдарды басқару құралдарымен жабдықтау;
- бөлінген контекстті тасымалдау;
- іздерді жинау;
- іздерді сақтау;
- оларды алу және визуализациялау.
Бөлінген бақылау туралы көп әңгіме оны жалғыз мақсаты жүйені толық диагностикалауға көмектесетін біртұтас операция түрі ретінде қарастырады. Бұл негізінен таратылған бақылау туралы идеялардың тарихи түрде қалай қалыптасқанына байланысты. IN , Зипкин көздері ашылғанда жасалған, бұл туралы айтылды ол [Zipkin] Twitter-ді жылдамырақ етеді. Бақылау үшін алғашқы коммерциялық ұсыныстар, сондай-ақ ретінде жылжытылды .
Ескерту. аударма: Одан әрі мәтінді түсінуді жеңілдету үшін екі негізгі терминге сәйкес анықтама берейік :
- Span — үлестірілген кальканың негізгі элементі. Бұл аты, басталу және аяқталу уақыты, тегтері, журналдары және мәтінмәні бар белгілі бір жұмыс процесінің сипаттамасы (мысалы, дерекқор сұрауы).
- Аралықтар әдетте басқа аралықтарға сілтемелерді қамтиды, бұл бірнеше аралықты біріктіруге мүмкіндік береді Іздеңіз — таратылған жүйе арқылы қозғалатын сұраныстың өмір сүруін визуализациялау.
Тізімде өндіріс сынағы, апатты қалпына келтіру сынағы, қателерді енгізу сынағы және т.б. сияқты тапсырмаларды орындауға көмектесетін керемет құнды деректер бар. Шындығында, кейбір компаниялар қазірдің өзінде ұқсас мақсаттарда бақылауды пайдаланады. бастайық аралықтарды сақтау жүйесіне жылжытудан басқа басқа да мақсаттары бар:
- Мысалы, Uber сынақ трафигі мен өндірістік трафикті ажырату үшін нәтижелерді қадағалау.
- Facebook апатты қалпына келтіру сынақтары кезінде сыни жолды талдау және трафикті ауыстыру үшін деректерді қадағалау.
- Сондай-ақ әлеуметтік желі Әзірлеушілерге бақылау нәтижелері бойынша ерікті сұрауларды орындауға мүмкіндік беретін Jupyter жазу кітапшалары.
- Адистер (Lineage Driven Failure Injection) қате инъекциямен тестілеуге арналған іздер таратылды.
Жоғарыда аталған опциялардың ешқайсысы сценарийге толығымен қолданылмайды жөндеу, оның барысында инженер ізге қарап мәселені шешуге тырысады.
Ол келгенде әзірге жөндеу сценарийіне жетеді, бастапқы интерфейс диаграмма болып қалады traceview (бірақ кейбіреулер оны да атайды «Гант диаграммасы» немесе «сарқырама диаграммасы»). астында traceview я бірге ізді құрайтын барлық аралықтар мен ілеспе метадеректер. Әрбір ашық бастапқы бақылау жүйесі, сондай-ақ әрбір коммерциялық бақылау шешімі a ұсынады traceview визуализацияға, егжей-тегжейлі көрсетуге және жолдарды сүзуге арналған пайдаланушы интерфейсі.
Мен осы уақытқа дейін көрген барлық бақылау жүйелеріндегі мәселе - нәтиже визуализация (traceview) із генерациялау процесінің ерекшеліктерін толығымен дерлік көрсетеді. Баламалы визуализациялар ұсынылса да: жылу карталары, қызмет топологиялары, кідіріс гистограммалары, олар бәрібір сайып келгенде traceview.
Өткенде И UI/UX бақылауындағы көптеген «инновациялар» шектелген сияқты қосымша метадеректерді қадағалап, оларға ақпаратты жоғары дәрежеде инвестициялау (жоғары кардиналдық) немесе белгілі бір аралықтарға жылжыту немесе сұрауларды орындау мүмкіндігін қамтамасыз етеді аралық және ішкі із. Бола тұра traceview негізгі визуализация құралы болып қала береді. Бұл жағдай жалғаса беретін болса, үлестірілген бақылау (ең жақсы жағдайда) метрикадан, журналдардан және стек іздерінен кейін жөндеу құралы ретінде 4-ші орынды алады, ал ең нашар жағдайда бұл ақша мен уақытты босқа кетіреді.
Traceview ақаулығы
Мақсаты traceview — бір сұраныстың ол қатысы бар таратылған жүйенің барлық құрамдас бөліктері бойынша қозғалысының толық бейнесін қамтамасыз ету. Кейбір жетілдірілген бақылау жүйелері жеке аралықтарды тереңдетуге және уақыт бойынша бұзылуды көруге мүмкіндік береді ішінде бір процесс (аралықтардың функционалдық шекаралары болған кезде).
Микросервис архитектурасының негізгі алғышарттары ұйымдық құрылым компанияның қажеттіліктеріне байланысты өседі деген идея болып табылады. Микросервистерді жақтаушылар әр түрлі бизнес тапсырмаларын жеке қызметтерге бөлу шағын, автономды әзірлеу топтарына осындай қызметтердің бүкіл өмірлік циклін бақылауға мүмкіндік береді, бұл оларға сол қызметтерді өз бетінше құру, сынау және орналастыру мүмкіндігін береді деп санайды. Дегенмен, бұл бөлудің кемшілігі - әрбір қызметтің басқалармен қалай әрекеттесетіні туралы ақпараттың жоғалуы. Мұндай жағдайларда таратылған бақылау таптырмас құрал болып табылады деп мәлімдейді жөндеу қызметтер арасындағы күрделі өзара әрекеттесу.
Егер сен шынымен , сосын бірде-бір адам басына ұстай алмайды толық сурет. Шындығында, бұл тіпті мүмкін деген болжамға негізделген құралды әзірлеу анти-үлгі (тиімсіз және өнімсіз тәсіл) болып табылады. Ең дұрысы, отладка көмектесетін құралды қажет етеді іздеу аймағын тарылту, осылайша инженерлер қарастырылатын мәселе сценарийіне қатысты өлшемдер жиынына (қызметтер/пайдаланушылар/хосттар, т.б.) назар аудара алады. Ақаулықтың себебін анықтаған кезде инженерлерден жұмыс кезінде не болғанын түсіну талап етілмейді барлық қызметтерді бірден, өйткені мұндай талап микросервис архитектурасының идеясына қайшы келеді.
Дегенмен, traceview атап айтқанда Бұл. Иә, кейбір бақылау жүйелері іздегі аралықтар саны бір визуализацияда көрсетілмейтіндей үлкен болғанда, сығылған бақылау көріністерін ұсынады. Дегенмен, мұндай жойылған визуализацияның өзінде қамтылған ақпараттың үлкен көлеміне байланысты инженерлер әлі де мәжбүр Мәселелердің көзі болып табылатын қызметтер жиынтығына таңдауды қолмен тарылтып, оны «елеңіз». Өкінішке орай, бұл салада машиналар адамдарға қарағанда әлдеқайда жылдам, қателіктерге бейім емес және олардың нәтижелері қайталанатын болады.
Бақылауды дұрыс емес деп санайтын тағы бір себеп - бұл гипотезаға негізделген жөндеу үшін жақсы емес. Негізінде отладтау болып табылады қайталанатын гипотезадан басталып, жүйеден әртүрлі векторлар бойынша алынған әртүрлі бақылаулар мен фактілерді тексеру, қорытындылар/жалпылау және гипотезаның ақиқаттығын одан әрі бағалаумен жалғасатын процесс.
Қабілеті жылдам және арзан гипотезаларды тексеру және соған сәйкес психикалық модельді жетілдіру болып табылады ірге тасы жөндеу Кез келген отладка құралы болуы керек интерактивті және іздеу кеңістігін тарылтыңыз немесе жалған жетекші болған жағдайда, пайдаланушыға кері қайтып, жүйенің басқа аймағына назар аударуға мүмкіндік беріңіз. Мұны тамаша құрал жасайды белсенді түрде, пайдаланушының назарын бірден ықтимал проблемалық аймақтарға аударады.
Әттең, traceview интерактивті интерфейсі бар құрал деп атауға болмайды. Оны пайдаланған кезде күтуге болатын ең жақсы нәрсе - кідірістің кейбір көзін табу және онымен байланысты барлық ықтимал тегтер мен журналдарды қарау. Бұл инженерге анықтауға көмектеспейді үлгілер кідірістерді бөлу ерекшеліктері сияқты қозғалыста немесе әртүрлі өлшемдер арасындағы корреляцияны анықтайды. осы мәселелердің кейбірін айналып өтуге көмектесуі мүмкін. Шынымен, аномальдық аралықты анықтау және аномальдық мінез-құлықпен байланысты болуы мүмкін тегтер жиынын анықтау үшін машиналық оқытуды пайдалана отырып сәтті талдау. Дегенмен, мен әлі күнге дейін трассалық көріністен немесе DAG (бағытталған ациклдік график) айырмашылығы бар аралықтарға қолданылатын машиналық оқытудың немесе деректерді іздеу нәтижелерінің әсерлі визуализациясын көрмедім.
Аралықтар тым төмен деңгейде
Traceview-тің негізгі мәселесі - бұл аралықтар кешігуді талдау үшін де, түбірлік себептерді талдау үшін де тым төмен деңгейлі примитивтер. Бұл жұмыс істеуге әлдеқайда ыңғайлы backtrace сияқты әлдеқайда жоғары деңгейлі құралдар бар екенін біле отырып, ерекше жағдайды шешуге тырысу үшін жеке процессор пәрмендерін талдау сияқты.
Оның үстіне, мен мынаны айта аламын: дұрысы, бізге қажет емес толық сурет қазіргі заманғы бақылау құралдарымен ұсынылған сұраудың өмірлік циклі кезінде орын алды. Оның орнына, не туралы ақпаратты қамтитын жоғары деңгейлі абстракцияның кейбір түрі қажет қате кетті (backtrace ұқсас), кейбір контекстпен бірге. Бүкіл ізді қараудың орнына мен оны көргенді қалаймын бөлігі, қызықты немесе әдеттен тыс нәрсе орын алатын жерде. Қазіргі уақытта іздеу қолмен жүзеге асырылады: инженер ізді алады және қызықты нәрсені іздеуде аралықтарды дербес талдайды. Күдікті әрекетті анықтауға үміттеніп, жеке іздерде аралықтарға қарап отырған адамдардың көзқарасы мүлде масштабталмайды (әсіресе олар аралық идентификаторы, RPC әдісінің атауы, аралықтың ұзақтығы сияқты әртүрлі ауқымдарда кодталған барлық метадеректерді түсінуі керек болғанда) 'a, журналдар, тегтер және т.б.).
Traceview баламалары
Бақылау нәтижелері жүйенің өзара байланысқан бөліктерінде не болып жатқаны туралы тривиальды емес түсінікті қамтамасыз ететін түрде визуализацияланған кезде ең пайдалы болады. Бұл орын алғанша, отладка процесі негізінен қалады инертті және пайдаланушының дұрыс корреляцияларды байқау, жүйенің дұрыс бөліктерін тексеру немесе басқатырғыш бөліктерін біріктіру қабілетіне байланысты - керісінше құрал, пайдаланушыға осы гипотезаларды тұжырымдауға көмектесу.
Мен визуалды дизайнер немесе UX маманы емеспін, бірақ келесі бөлімде бұл визуализациялар қандай болуы мүмкін екендігі туралы бірнеше идеялармен бөліскім келеді.
Белгілі бір қызметтерге назар аударыңыз
Өнеркәсіп идеялар төңірегінде шоғырланып жатқан уақытта , жеке командалар өз қызметтерінің осы мақсаттарға сәйкес келуін қамтамасыз етуге басымдық беруі орынды сияқты. Осыдан шығады қызмет көрсетуге бағытталған визуализация мұндай командалар үшін ең қолайлы.
Іздер, әсіресе іріктеусіз, таратылған жүйенің әрбір құрамдас бөлігі туралы ақпараттың қазынасы болып табылады. Бұл ақпаратты пайдаланушыларды қамтамасыз ететін айлакер процессорға беруге болады қызмет көрсетуге бағытталған Оларды алдын ала анықтауға болады – тіпті пайдаланушы іздерге қарағанға дейін:
- Кідірістерді тарату диаграммалары тек өте көрнекті сұраулар үшін (шамадан тыс сұраныстар);
- SLO қызметінің мақсаттарына қол жеткізілмеген жағдайлар үшін кідірістерді бөлу диаграммалары;
- Сұраулардағы ең «жалпы», «қызықты» және «біртүрлі» тегтер жиі кездеседі қайталанады;
- Жағдайлар үшін кідірістерді бөлу тәуелділіктер қызметтер SLO мақсаттарына жете алмайды;
- Әр түрлі төмен ағын қызметтері үшін кідірістің бұзылуы.
Бұл сұрақтардың кейбіреулері кірістірілген көрсеткіштер арқылы жауап бермейді, бұл пайдаланушыларды аралықты мұқият тексеруге мәжбүр етеді. Нәтижесінде бізде пайдаланушыға өте дұшпандық механизм бар.
Бұл сұрақ туындайды: әртүрлі командалар басқаратын әртүрлі қызметтер арасындағы күрделі өзара әрекеттесу туралы не деуге болады? Емес пе traceview мұндай жағдайды көрсету үшін ең қолайлы құрал болып саналмайды?
Мобильді әзірлеушілер, азаматтығы жоқ қызметтердің иелері, басқарылатын мемлекеттік қызметтердің иелері (мысалы, дерекқорлар) және платформа иелері басқа нәрсеге қызығушылық танытуы мүмкін. презентация бөлінген жүйе; traceview бұл түбегейлі әртүрлі қажеттіліктер үшін тым жалпы шешім. Тіпті өте күрделі микросервис архитектурасында қызмет иелеріне екі-үштен жоғары және төмен ағындық қызметтер туралы терең білім қажет емес. Негізінде, көптеген сценарийлерде пайдаланушылар тек қатысты сұрақтарға жауап беруі керек қызметтердің шектеулі жиынтығы.
Бұл қызметтердің кішігірім жиынын мұқият қарап шығу үшін үлкейткіш әйнек арқылы қарау сияқты. Бұл пайдаланушыға осы қызметтер мен олардың тікелей тәуелділіктері арасындағы күрделі өзара әрекеттесулерге қатысты өзекті сұрақтар қоюға мүмкіндік береді. Бұл инженер білетін қызметтер әлеміндегі кері ізге ұқсас сол қате, сондай-ақ түсіну үшін айналадағы қызметтерде не болып жатқанын түсінеді неге.
Мен ұсынып отырған тәсіл - жоғарыдан төменге, бақылауға негізделген тәсілге дәл қарама-қарсы, мұнда талдау бүкіл ізден басталады, содан кейін бірте-бірте жеке аралықтарға дейін жұмыс істейді. Керісінше, төменнен жоғарыға бағытталған әдіс оқиғаның ықтимал себебіне жақын шағын аумақты талдаудан басталады, содан кейін қажет болған жағдайда іздеу кеңістігін кеңейтеді (қызметтердің кең спектрін талдау үшін басқа командаларды тарту әлеуеті бар). Екінші тәсіл бастапқы гипотезаларды жылдам тексеру үшін қолайлы. Нақты нәтижелерге қол жеткізгеннен кейін мақсатты және егжей-тегжейлі талдауға көшуге болады.
Топологияны құру
Пайдаланушы білсе, қызметке арналған көріністер керемет пайдалы болуы мүмкін не қызмет немесе қызметтер тобы кідірісті арттыруға немесе қателерді тудыруға жауапты. Дегенмен, күрделі жүйеде бұзылған қызметті анықтау сәтсіздік кезінде маңызды емес тапсырма болуы мүмкін, әсіресе қызметтерден қате туралы хабарлар хабарланбаса.
Қызмет топологиясын құру қай қызметте қателіктердің жоғарылауын немесе қызметтің айтарлықтай нашарлауына әкелетін кідірістің ұлғаюын анықтауға үлкен көмек болуы мүмкін. Мен топологияны құру туралы айтқанда, мен айтпаймын қызметтер картасы, жүйеде қолжетімді және өзімен танымал әрбір қызметті көрсетеді . Бұл көрініс бағытталған ациклдік графикке негізделген бақылаудан жақсы емес. Оның орнына мен көргім келеді динамикалық түрде құрылған қызмет топологиясы, қате жылдамдығы, жауап беру уақыты немесе нақты күдікті қызметтермен жағдайды түсіндіруге көмектесетін кез келген пайдаланушы анықтайтын параметр сияқты белгілі атрибуттарға негізделген.
Мысал келтірейік. Гипотетикалық жаңалықтар сайтын елестетейік. Негізгі бет қызметі (алдыңғы бет) Редиспен, ұсыныс қызметімен, жарнама қызметімен және бейне қызметімен деректер алмасады. Бейне қызметі S3 жүйесінен бейнелерді және DynamoDB метадеректерін алады. Ұсыныс қызметі DynamoDB-дан метадеректерді алады, Redis және MySQL-тен деректерді жүктейді және Кафкаға хабарлар жазады. Жарнама қызметі MySQL-тен деректерді алады және Кафкаға хабарламалар жазады.
Төменде осы топологияның схемалық көрінісі берілген (көптеген коммерциялық маршруттау бағдарламалары топологияны құрастырады). Қызметтік тәуелділіктерді түсіну қажет болса, бұл пайдалы болуы мүмкін. Дегенмен, кезінде жөндеу, белгілі бір қызмет (айталық, бейне қызметі) жауап беру уақытының жоғарылауын көрсеткенде, мұндай топология өте пайдалы емес.
Гипотетикалық жаңалықтар сайтының сервистік диаграммасы
Төмендегі диаграмма жақсырақ болады. Қызметте ақау бар (бейне) дәл ортасында бейнеленген. Пайдаланушы оны бірден байқайды. Бұл визуализациядан негізгі беттің бір бөлігінің жүктелу жылдамдығына әсер ететін S3 жауап беру уақытының ұлғаюына байланысты бейне қызметі қалыпты емес жұмыс істеп тұрғаны белгілі болды.
Тек «қызықты» қызметтерді көрсететін динамикалық топология
Динамикалық түрде жасалған топологиялар статикалық қызмет карталарына қарағанда тиімдірек болуы мүмкін, әсіресе серпімді, автоматты масштабталатын инфрақұрылымдарда. Қызмет топологияларын салыстыру және салыстыру мүмкіндігі пайдаланушыға неғұрлым өзекті сұрақтар қоюға мүмкіндік береді. Жүйе туралы нақтырақ сұрақтар жүйенің қалай жұмыс істейтінін жақсырақ түсінуге әкеледі.
Салыстырмалы көрсету
Тағы бір пайдалы визуализация салыстырмалы дисплей болар еді. Қазіргі уақытта іздер жанама салыстыру үшін өте қолайлы емес, сондықтан салыстыру әдетте аралықтар. Бұл мақаланың негізгі идеясы - бұл аралықтардың тым төмен деңгейлі, ең құнды ақпаратты іздеу нәтижелерінен алу үшін.
Екі ізді салыстыру түбегейлі жаңа визуализацияларды қажет етпейді. Шындығында, трассалық көрініспен бірдей ақпаратты көрсететін гистограмма сияқты нәрсе жеткілікті. Таңқаларлық, тіпті бұл қарапайым әдіс екі ізді бөлек зерттеуден гөрі әлдеқайда көп жеміс әкелуі мүмкін. Мүмкіндік одан да күштірек болар еді визуализациялау іздерін салыстыру Жалпы алғанда. GC (қоқыс жинау) қосу үшін жақында енгізілген дерекқор конфигурациясының өзгеруі бірнеше сағаттық ауқымда төменгі ағындық қызметтің жауап беру уақытына қалай әсер ететінін көру өте пайдалы болар еді. Егер мен мұнда сипаттап отырғаным инфрақұрылымдық өзгерістердің әсеріне қатысты A/B талдауы сияқты көрінсе. көптеген қызметтерде із нәтижелерін пайдаланып, онда сіз шындықтан тым алыс емессіз.
қорытынды
Мен іздеудің пайдалылығына күмән келтірмеймін. Мен іздегідей бай, себепті және контекстік деректерді жинаудың басқа әдісі жоқ екеніне шын жүректен сенемін. Дегенмен, барлық бақылау шешімдері бұл деректерді өте тиімсіз пайдаланады деп ойлаймын. Бақылау құралдары бақылау көрінісінде тұрып қалғанша, олардың іздердегі деректерден алуға болатын құнды ақпаратты барынша пайдалану мүмкіндігі шектеулі болады. Бұған қоса, пайдаланушының қолданбадағы қателерді жою мүмкіндігін айтарлықтай шектейтін мүлдем қолайсыз және интуитивтік визуалды интерфейсті одан әрі дамыту қаупі бар.
Күрделі жүйелерді жөндеу, тіпті соңғы құралдармен де, өте қиын. Құралдар әзірлеушіге гипотезаны тұжырымдауға және сынауға көмектесуі керек, белсенді түрде қамтамасыз етеді сәйкес ақпарат, ауытқуларды анықтау және кідірістерді бөлу ерекшеліктерін атап өту. Өндіріс ақауларын жою немесе бірнеше қызметтерді қамтитын мәселелерді шешу кезінде қадағалау әзірлеушілер үшін таңдау құралы болуы үшін сол қызметтерді жасайтын және басқаратын әзірлеушілердің психикалық үлгісіне сәйкес келетін түпнұсқа пайдаланушы интерфейстері мен визуализациялар қажет.
Бақылау нәтижелерінде қол жетімді әртүрлі сигналдарды талдау мен қорытынды жасауға ыңғайлы етіп оңтайландырылған түрде көрсететін жүйені жобалау үшін айтарлықтай ақыл-ой күш-жігері қажет болады. Пайдаланушыға жеке іздерді немесе аралықты қарамай соқыр дақтарды жеңуге көмектесетіндей жөндеу кезінде жүйе топологиясын қалай абстракциялау керектігі туралы ойлану керек.
Бізге абстракция және қабаттастырудың жақсы мүмкіндіктері қажет (әсіресе пайдаланушы интерфейсінде). Итеративті түрде сұрақтар қоюға және гипотезаларды тексеруге болатын гипотезаға негізделген жөндеу процесіне жақсы сәйкес келетіндер. Олар бақылаудың барлық мәселелерін автоматты түрде шешпейді, бірақ олар пайдаланушыларға түйсігін ашуға және ақылды сұрақтарды құрастыруға көмектеседі. Мен визуализацияға неғұрлым ойластырылған және жаңашыл көзқарасқа шақырамын. Мұнда көкжиектерді кеңейтудің нақты болашағы бар.
Аудармашыдан PS
Біздің блогта да оқыңыз:
- ««;
- ««;
- ««.
Ақпарат көзі: www.habr.com