Jegyzet. ford.: Ennek az anyagnak a szerzője Cindy Sridharan, az imgix mérnöke, aki API-fejlesztésre és különösen a mikroszolgáltatások tesztelésére specializálódott. Ebben az anyagban részletes elképzelését osztja meg az elosztott nyomkövetés aktuális problémáiról, ahol véleménye szerint hiányoznak az igazán hatékony eszközök a sürgető problémák megoldására.
[Az illusztráció innen származik az elosztott nyomkövetésről.]
Úgy tartják, hogy nehezen kivitelezhető, és ennek megtérülése . Számos oka lehet annak, hogy a nyomkövetés problémás, gyakran arra hivatkozva, hogy az egyes rendszerösszetevők konfigurálása során a megfelelő fejléceket minden kéréssel elküldik. Bár ez a probléma létezik, korántsem megoldhatatlan. Mellesleg, ez nem magyarázza meg, hogy a fejlesztők miért nem igazán szeretik a nyomkövetést (még akkor sem, ha már működik).
Az elosztott nyomkövetés fő kihívása nem az adatok gyűjtése, az eredmények elosztására és bemutatására szolgáló formátumok szabványosítása, vagy annak meghatározása, hogy mikor, hol és hogyan kell mintát venni. Nem próbálom elképzelni jelentéktelen ezek az "érthetőségi problémák" valójában meglehetősen jelentős technikai és (ha valóban nyílt forráskódot vesszük figyelembe) ) politikai kihívások, amelyeket le kell küzdeni ahhoz, hogy ezeket a problémákat megoldottnak tekintsük.
Ha azonban azt képzeljük, hogy mindezek a problémák megoldódtak, nagy a valószínűsége annak, hogy semmi sem fog lényegesen megváltozni végfelhasználói élmény. Előfordulhat, hogy a nyomkövetés még mindig nem használható gyakorlatiasan a leggyakoribb hibakeresési forgatókönyvekben – még a telepítés után sem.
Annyira más nyom
Az elosztott nyomkövetés több különböző összetevőt tartalmaz:
- alkalmazások és köztes szoftverek felszerelése vezérlőeszközökkel;
- elosztott kontextus átvitel;
- nyomok gyűjtése;
- nyomtárolás;
- kinyerésük és megjelenítésük.
Az elosztott nyomkövetésről sok szó esik egyfajta unáris műveletként, amelynek egyetlen célja a rendszer teljes körű diagnosztizálása. Ez nagyrészt annak köszönhető, hogy az elosztott nyomkövetéssel kapcsolatos elképzelések történelmileg kialakultak. BAN BEN , a Zipkin-források megnyitásakor készült, szóba került, hogy ez [Zipkin] gyorsabbá teszi a Twittert. A nyomkövetés első kereskedelmi ajánlatait is népszerűsítették .
Jegyzet. ford.: A további szövegek érthetősége érdekében definiáljunk két alapfogalmat a szerint :
- Span — az elosztott nyomkövetés alapeleme. Ez egy bizonyos munkafolyamat (például egy adatbázis-lekérdezés) leírása névvel, kezdési és befejezési időpontokkal, címkékkel, naplókkal és kontextussal.
- A szakaszok jellemzően más szakaszokra mutató hivatkozásokat tartalmaznak, lehetővé téve több span kombinálását Nyom — egy kérés életének vizualizálása, amint az elosztott rendszeren keresztül halad.
A nyomkövetések hihetetlenül értékes adatokat tartalmaznak, amelyek segíthetnek olyan feladatokban, mint a gyártási tesztelés, a katasztrófa-helyreállítási tesztelés, a hibabefecskendezés tesztelése stb. Valójában néhány vállalat már használja a nyomkövetést hasonló célokra. Kezdjük azzal más felhasználási területei is vannak, azon kívül, hogy a tartományokat egyszerűen áthelyezi a tárolórendszerbe:
- Például az Uber az eredmények nyomon követése a tesztforgalom és az éles forgalom megkülönböztetésére.
- Facebook nyomkövetési adatok a kritikus útvonalelemzéshez és a forgalomváltáshoz a rendszeres katasztrófa-helyreállítási tesztek során.
- Szintén közösségi hálózat Jupyter notebookok, amelyek lehetővé teszik a fejlesztők számára tetszőleges lekérdezések futtatását a nyomkövetési eredményeken.
- Hívei (Leágazás által vezérelt hibabefecskendezés) elosztott nyomokat hibabefecskendezéssel történő teszteléshez.
A fent felsorolt lehetőségek egyike sem vonatkozik teljes mértékben a forgatókönyvre hibakeresés, melynek során a mérnök a nyomra nézve próbálja megoldani a problémát.
Amikor jön még eléri a hibakereső szkriptet, az elsődleges interfész a diagram marad traceview (bár egyesek úgy is hívják "Gantt-diagram" vagy "vízesés diagram"). Alatt traceview я az összes kiterjedést és a kísérő metaadatokat, amelyek együtt alkotják a nyomkövetést. Minden nyílt forráskódú nyomkövetési rendszer, valamint minden kereskedelmi nyomkövetési megoldás kínál a traceview felhasználói felület a nyomok megjelenítéséhez, részletezéséhez és szűréséhez.
Az a probléma az összes nyomkövető rendszerrel, amit eddig láttam, hogy az eredmény vizualizáció (traceview) szinte teljesen tükrözi a nyomgenerálási folyamat jellemzőit. Még akkor is, ha alternatív vizualizációkat javasolnak: hőtérképek, szolgáltatás topológiák, késleltetési hisztogramok, végül mégis traceview.
A múltban I hogy a legtöbb UI/UX nyomkövetési „újítás” arra korlátozódik további metaadatok nyomon követése, befektetések bennük az információk nagy számossággal (magas kardinalitású) vagy lehetővé teszi, hogy részletezzen bizonyos tartományokba vagy lekérdezéseket futtasson inter- és intra-trace... Hol traceview továbbra is az elsődleges vizualizációs eszköz. Amíg ez a helyzet folytatódik, az elosztott nyomkövetés (legjobb esetben) a 4. helyet foglalja el hibakereső eszközként a metrikák, naplók és veremnyomok után, legrosszabb esetben pedig pénz- és időpazarlásnak bizonyul.
Probléma a traceview-val
sors traceview — teljes képet adjon egyetlen kérelem mozgásáról az elosztott rendszer összes olyan összetevőjében, amelyhez az kapcsolódik. Egyes fejlettebb nyomkövetési rendszerek lehetővé teszik az egyes szakaszok lefúrását és az időbeli lebontások megtekintését belső egy folyamat (amikor a fesztávoknak funkcionális határai vannak).
A mikroszolgáltatási architektúra alaptétele az az elképzelés, hogy a szervezeti struktúra a vállalat igényeivel együtt nő. A mikroszolgáltatások támogatói azzal érvelnek, hogy a különböző üzleti feladatok egyedi szolgáltatásokra történő felosztása lehetővé teszi a kis, önálló fejlesztőcsapatok számára az ilyen szolgáltatások teljes életciklusának ellenőrzését, lehetővé téve számukra a szolgáltatások önálló felépítését, tesztelését és üzembe helyezését. Ennek a disztribúciónak azonban az a hátránya, hogy elveszik az információkat arról, hogy az egyes szolgáltatások hogyan kommunikálnak másokkal. Ilyen körülmények között az elosztott nyomkövetés nélkülözhetetlen eszköznek tartja magát hibakeresés szolgáltatások közötti komplex interakciók.
Ha tényleg , akkor egyetlen ember sem képes a fejében tartani teljes kép. Valójában egy olyan eszköz kifejlesztése, amely azon a feltételezésen alapul, hogy ez még lehetséges is, valami anti-minta (nem hatékony és nem produktív megközelítés). Ideális esetben a hibakereséshez olyan eszközre van szükség, amely segít szűkítse a keresési területet, hogy a mérnökök a dimenziók egy részhalmazára (szolgáltatások/felhasználók/gazdagépek stb.) összpontosíthassanak a vizsgált problémaforgatókönyv szempontjából. A meghibásodás okának meghatározásakor a mérnököknek nem kell megérteniük, mi történt a meghibásodás során az összes szolgáltatást egyszerre, mivel egy ilyen követelmény ellentmondana a mikroszolgáltatási architektúra elképzelésének.
A traceview azonban igen pontosan Ez. Igen, egyes nyomkövetési rendszerek tömörített nyomkövetési nézeteket kínálnak, ha a nyomkövetési szakaszok száma olyan nagy, hogy nem jeleníthetők meg egyetlen vizualizációban. A nagy mennyiségű információ miatt azonban még egy ilyen lecsupaszított vizualizációban is a mérnökök még mindig kényszerű „rostálja” azt, manuálisan szűkítve a választékot a problémákat okozó szolgáltatások körére. Sajnos ezen a téren a gépek sokkal gyorsabbak, mint az emberek, kevésbé hajlamosak a hibákra, eredményeik pedig jobban megismételhetőek.
A másik ok, amiért úgy gondolom, hogy a traceview téves, az az, hogy nem alkalmas hipotézisvezérelt hibakeresésre. Lényege a hibakeresés ismétlődő egy hipotézissel kezdődő folyamat, amelyet a rendszerből származó különböző megfigyelések és tények különböző vektorok mentén történő igazolása, következtetések/általánosítások és a hipotézis igazságának további értékelése követ.
Alkalom gyors és olcsó hipotézisek tesztelése és a mentális modell ennek megfelelő javítása az sarokkő hibakeresés Bármilyen hibakereső eszköznek kell lennie interaktív és szűkítse a keresési teret, vagy hamis lead esetén lehetővé tegye a felhasználó számára, hogy visszamenjen, és a rendszer egy másik területére összpontosítson. A tökéletes eszköz ezt megteszi proaktívan, azonnal felhívja a felhasználó figyelmét a lehetséges problémás területekre.
Jaj, traceview nem nevezhető interaktív felülettel rendelkező eszköznek. Használata során a legjobb, amit remélhet, hogy megtalálja a megnövekedett késleltetés forrását, és megvizsgálja a hozzá kapcsolódó összes lehetséges címkét és naplót. Ez nem segíti a mérnököt az azonosításban minták a forgalomban, mint például a késleltetési eloszlás sajátosságai, vagy a különböző mérések közötti összefüggések kimutatása. segíthet megkerülni ezeket a problémákat. Igazán, sikeres elemzés a gépi tanulás segítségével a rendellenes tartományok azonosítására és a címkék egy részhalmazának azonosítására, amelyek a rendellenes viselkedéshez kapcsolhatók. Azonban még nem láttam meggyőző megjelenítést a gépi tanulásról vagy az adatbányászati eredményekről olyan tartományokra, amelyek jelentősen eltérnek a nyomkövetési nézettől vagy a DAG-tól (irányított aciklikus gráf).
A fesztávok túl alacsonyak
A traceview alapvető problémája az átíveli túl alacsony szintű primitívek mind a látenciaelemzés, mind a kiváltó ok elemzéséhez. Ez olyan, mint az egyes processzorparancsok elemzése, hogy megpróbáljunk feloldani egy kivételt, tudván, hogy vannak sokkal magasabb szintű eszközök, mint például a backtrace, amelyekkel sokkal kényelmesebb dolgozni.
Sőt, megragadom a bátorságot, hogy kijelentsem a következőket: ideális esetben nincs szükségünk teljes kép a kérés életciklusa során történt, amelyet modern nyomkövetési eszközök képviselnek. Ehelyett valamilyen magasabb szintű absztrakcióra van szükség, amely információt tartalmaz arról, hogy mi rosszul ment (hasonlóan a backtrace-hez), némi kontextussal együtt. Ahelyett, hogy az egész nyomot nézném, inkább látni szeretném часть, ahol valami érdekes vagy szokatlan történik. Jelenleg a keresést manuálisan hajtják végre: a mérnök megkapja a nyomkövetést, és önállóan elemzi az íveket, hogy valami érdekeset keressen. Egyáltalán nem skálázódik az a megközelítés, amikor az emberek egyedi nyomokban bámulják a szakaszokat a gyanús tevékenység észlelésének reményében (különösen akkor, ha értelmezniük kell a különböző tartományokban kódolt összes metaadatot, például a tartományazonosítót, az RPC-metódus nevét, az időtartam időtartamát). 'a, naplók, címkék stb.).
A traceview alternatívái
A nyomkövetési eredmények akkor a leghasznosabbak, ha olyan módon jeleníthetők meg, amely nem triviális betekintést nyújt abba, hogy mi történik a rendszer összekapcsolt részein. Amíg ez meg nem történik, a hibakeresési folyamat nagyrészt megmarad inert és attól függ, hogy a felhasználó képes-e észrevenni a megfelelő összefüggéseket, ellenőrizni a rendszer megfelelő részeit, vagy összerakni a puzzle darabjait – ellentétben szerszám, segítve a felhasználót ezen hipotézisek megfogalmazásában.
Nem vagyok vizuális tervező vagy UX specialista, de a következő részben szeretnék megosztani néhány ötletet arról, hogyan nézhetnek ki ezek a vizualizációk.
Konkrét szolgáltatásokra összpontosítson
Abban az időben, amikor az ipar az ötletek körül konszolidálódik , ésszerűnek tűnik, hogy az egyes csapatok prioritásként kezeljék annak biztosítását, hogy szolgáltatásaik összhangban legyenek ezekkel a célokkal. Ebből következik, hogy szolgáltatásközpontú a vizualizáció az ilyen csapatok számára a legalkalmasabb.
A nyomok, különösen mintavétel nélkül, az elosztott rendszer minden egyes összetevőjével kapcsolatos információ kincses tárháza. Ezt az információt egy ravasz processzornak lehet betáplálni, amely ellátja a felhasználókat szolgáltatásközpontú Előre azonosíthatók – még mielőtt a felhasználó megnézné a nyomokat:
- A késleltetési eloszlási diagramok csak kiemelkedően feltűnő kérések esetén (kiugró kérések);
- A késleltetés eloszlásának diagramja azokra az esetekre, amikor a szolgáltatás SLO céljait nem érik el;
- A „leggyakoribb”, „érdekesebb” és „furcsa” címkék olyan lekérdezésekben, amelyek leggyakrabban ismétlődnek;
- A késleltetés lebontása olyan esetekben, amikor attól függően, hogy a szolgáltatások nem érik el SLO-céljaikat;
- Különböző downstream szolgáltatások késleltetési lebontása.
E kérdések némelyikére a beépített mérőszámok egyszerűen nem adnak választ, ami arra kényszeríti a felhasználókat, hogy alaposan átvizsgálják a tartományokat. Ennek eredményeként egy rendkívül felhasználóellenes mechanizmussal rendelkezünk.
Ez felveti a kérdést: mi a helyzet a különböző csapatok által irányított, különféle szolgáltatások közötti komplex interakciókkal? Ugye traceview nem tekinthető a legmegfelelőbb eszköznek egy ilyen helyzet kiemelésére?
A mobilfejlesztőket, az állapot nélküli szolgáltatások tulajdonosait, a felügyelt állapotalapú szolgáltatások (például adatbázisok) tulajdonosait és a platformtulajdonosokat más érdekelheti bemutatás elosztott rendszer; traceview túl általános megoldás ezekre az alapvetően eltérő igényekre. Még egy nagyon összetett mikroszolgáltatás-architektúrában sem kell a szolgáltatástulajdonosoknak kettőnél vagy háromnál több upstream és downstream szolgáltatás alapos ismerete. Lényegében a legtöbb esetben a felhasználóknak csak a vonatkozó kérdésekre kell válaszolniuk korlátozott szolgáltatások.
Ez olyan, mintha a szolgáltatások egy kis részhalmazát néznénk nagyítón keresztül az alapos vizsgálat kedvéért. Ez lehetővé teszi a felhasználó számára, hogy sürgetőbb kérdéseket tegyen fel e szolgáltatások közötti összetett interakciókkal és közvetlen függőségeikkel kapcsolatban. Ez hasonló a visszakövetéshez a szolgáltatások világában, ahol a mérnök tudja hogy hibás, és azt is megérti, hogy mi történik a környező szolgáltatásokban miért.
Az általam népszerűsített megközelítés pontosan az ellentéte a felülről lefelé irányuló, nyomkövetési alapú megközelítésnek, ahol az elemzés a teljes nyomkövetéssel kezdődik, majd fokozatosan az egyes szakaszokig terjed. Ezzel szemben az alulról felfelé irányuló megközelítés az incidens lehetséges okához közeli kis terület elemzésével kezdődik, majd szükség szerint kibővíti a keresési teret (más csapatok bevonásával a szolgáltatások szélesebb körének elemzésére). A második megközelítés alkalmasabb a kezdeti hipotézisek gyors tesztelésére. A konkrét eredmények elérése után lehetőség nyílik egy célzottabb és részletesebb elemzésre.
Topológia felépítése
A szolgáltatás-specifikus nézetek hihetetlenül hasznosak lehetnek, ha a felhasználó tudja ami egy szolgáltatás vagy szolgáltatáscsoport felelős a késleltetés növeléséért vagy a hibák előidézéséért. Egy összetett rendszerben azonban a sértő szolgáltatás azonosítása nem triviális feladat lehet egy meghibásodás során, különösen akkor, ha nem érkezett hibaüzenet a szolgáltatásoktól.
A szolgáltatástopológia felépítése nagy segítséget jelenthet annak meghatározásában, hogy melyik szolgáltatásnál tapasztalható megugrás a hibaarányban vagy a várakozási idő növekedése, ami a szolgáltatás észrevehető romlását okozza. Amikor a topológia felépítéséről beszélek, nem úgy értem szolgáltatások térképe, amely megjeleníti a rendszerben elérhető és arról ismert összes szolgáltatást . Ez a nézet nem jobb, mint egy irányított aciklikus gráfon alapuló traceview. Ehelyett szeretném látni dinamikusan generált szolgáltatás topológia, bizonyos attribútumok, például hibaarány, válaszidő vagy bármely olyan felhasználó által meghatározott paraméter alapján, amely segít tisztázni a helyzetet bizonyos gyanús szolgáltatásokkal.
Vegyünk egy példát. Képzeljünk el egy hipotetikus híroldalt. Kezdőlap szolgáltatás (Címlap) adatot cserél a Redisszel, ajánló szolgáltatással, reklámszolgáltatással és videószolgáltatással. A videoszolgáltatás az S3-ból veszi a videókat, a DynamoDB-ből pedig a metaadatokat. Az ajánlási szolgáltatás metaadatokat kap a DynamoDB-től, adatokat tölt be a Redisből és a MySQL-ből, és üzeneteket ír Kafkának. A hirdetési szolgáltatás adatokat fogad a MySQL-től, és üzeneteket ír Kafkának.
Az alábbiakban ennek a topológiának a sematikus ábrázolása látható (sok kereskedelmi útválasztó program építi fel a topológiát). Hasznos lehet, ha meg kell értenie a szolgáltatásfüggőségeket. Azonban közben hibakeresés, amikor egy bizonyos szolgáltatás (mondjuk egy videoszolgáltatás) megnövelt válaszidőt mutat, az ilyen topológia nem túl hasznos.
Egy hipotetikus híroldal szolgáltatási diagramja
Az alábbi diagram jobban megfelelne. Probléma van a szolgáltatással (videó) közvetlenül a közepén ábrázolva. A felhasználó azonnal észreveszi. Ebből a megjelenítésből világossá válik, hogy a videószolgáltatás rendellenesen működik az S3 válaszidő növekedése miatt, ami befolyásolja a főoldal egy részének betöltési sebességét.
Dinamikus topológia, amely csak „érdekes” szolgáltatásokat jelenít meg
A dinamikusan előállított topológiák hatékonyabbak lehetnek, mint a statikus szolgáltatástérképek, különösen rugalmas, automatikusan skálázó infrastruktúrákban. A szolgáltatás topológiák összehasonlításának és szembeállításának képessége lehetővé teszi a felhasználó számára, hogy relevánsabb kérdéseket tegyen fel. A rendszerrel kapcsolatos pontosabb kérdések nagyobb valószínűséggel vezetnek a rendszer működésének jobb megértéséhez.
Összehasonlító kijelző
Egy másik hasznos vizualizáció egy összehasonlító megjelenítés lenne. Jelenleg a nyomok nem nagyon alkalmasak egymás melletti összehasonlításra, ezért az összehasonlítások általában igen átíveli. És ennek a cikknek a fő gondolata pontosan az, hogy a tartományok túl alacsonyak ahhoz, hogy a legértékesebb információkat kinyerjék a nyomkövetési eredményekből.
Két nyom összehasonlítása nem igényel alapvetően új vizualizációkat. Valójában elég egy hisztogram, amely ugyanazt az információt reprezentálja, mint a nyomkövetés. Meglepő módon még ez az egyszerű módszer is sokkal több gyümölcsöt hozhat, mint egyszerűen két nyomot külön-külön tanulmányozni. Még erősebb lenne a lehetőség vizualizálni nyomok összehasonlítása Összesen. Rendkívül hasznos lenne látni, hogy egy nemrégiben telepített adatbázis-konfiguráció módosítása a GC (szemétgyűjtés) engedélyezéséhez hogyan befolyásolja a downstream szolgáltatás válaszidejét több órás léptékben. Ha az, amit itt leírok, úgy hangzik, mint az infrastruktúra-változások hatásának A/B elemzése számos szolgáltatásban a nyomkövetési eredmények felhasználásával, akkor nem vagy túl messze az igazságtól.
Következtetés
Nem kérdőjelezem meg magának a nyomkövetésnek a hasznosságát. Őszintén hiszem, hogy nincs más módszer olyan gazdag, ok-okozati és kontextuális adatok gyűjtésére, mint a nyomokban található adatok. Ugyanakkor úgy gondolom, hogy minden nyomkövetési megoldás rendkívül rosszul használja fel ezeket az adatokat. Mindaddig, amíg a nyomkövetési eszközök a traceview reprezentáción maradnak, korlátozottak lesznek abban a képességükben, hogy a legtöbbet hozzák ki a nyomokban található adatokból kinyerhető értékes információkat. Ezenkívül fennáll a veszélye egy teljesen barátságtalan és intuitív vizuális felület továbbfejlesztésének, amely súlyosan korlátozza a felhasználót az alkalmazás hibáinak elhárításában.
Az összetett rendszerek hibakeresése még a legújabb eszközökkel is hihetetlenül nehéz. Az eszközöknek segíteniük kell a fejlesztőt hipotézis megfogalmazásában és tesztelésében, aktívan biztosítva releváns információk, a kiugró értékek azonosítása és a késések eloszlásának jellemzői. Ahhoz, hogy a nyomkövetés a fejlesztők által választott eszközzé váljon a gyártási hibák hibaelhárítása vagy a több szolgáltatást átfogó problémák megoldása során, olyan eredeti felhasználói felületekre és vizualizációkra van szükség, amelyek jobban megfelelnek a szolgáltatásokat létrehozó és üzemeltető fejlesztők mentális modelljének.
Jelentős szellemi erőfeszítést igényel egy olyan rendszer megtervezése, amely a nyomkövetési eredményekben elérhető különböző jeleket az elemzés és a következtetések egyszerűsítése érdekében optimalizált módon reprezentálja. Át kell gondolnia, hogyan lehet a rendszer topológiáját absztrahálni a hibakeresés során oly módon, hogy segítse a felhasználót a vakfoltok leküzdésében anélkül, hogy az egyes nyomokat vagy íveket nézné.
Jó absztrakciós és rétegezési képességekre van szükségünk (főleg a felhasználói felületen). Olyanok, amelyek jól illeszkednének egy hipotézisvezérelt hibakeresési folyamatba, ahol iteratív kérdéseket tehet fel és hipotéziseket tesztelhet. Nem oldanak meg automatikusan minden megfigyelhetőségi problémát, de segítenek a felhasználóknak élesíteni intuíciójukat és okosabb kérdéseket megfogalmazni. A vizualizáció átgondoltabb és innovatívabb megközelítését kérem. Itt valódi kilátás nyílik a látókör bővítésére.
PS a fordítótól
Olvassa el blogunkon is:
- «";
- «";
- «".
Forrás: will.com