Märkus tõlke kohta.: Artikli autor on Cindy Sridharan, insener ettevõttes imgix, mis tegeleb API arendamise ja eriti mikroteenuste testimisega. Selles artiklis jagab ta oma põhjalikku nägemust tänapäeva probleemidest jaotatud jälgimises, kus, tema arvates, puuduvad tõeliselt efektiivsed tööriistad igapäevaste probleemide lahendamiseks.
[Illustratsioon on laenatud jaotatud jälgimise kohta.]
Peetakse, et on raske rakendada, ja selle kasu . "Jälgimise problemaatilisust" selgitatakse paljude põhjustega, samas viidatakse sageli iga süsteemi komponente nõudva töömahukuse peale, et edastada vastavad päised iga päringuga. Kuigi see probleem tõepoolest eksisteerib, ei saa seda kindlasti nimetada ületamatuks. Muide, see ei selgita, miks arendajad ei armasta jälgimist (isegi juba toimivat).
Peamine raskus jaotatud jälgimisega ei seisne mitte andmete kogumises, mitte levitamise ja esitamise vormaatide standardimises ning mitte selles, millal, kus ja kuidas valimisi teha. Ma ei ürita sugugi lihtsustada need "kasutamise probleemid" — tõepoolest, on olemas üsna olulisi tehnilisi ja (kui me räägime tõeliselt avatud lähtekoodiga ) poliitilisi väljakutseid, mis tuleb ületada, enne kui neid probleeme saab pidada lahendatuks.
Kuid kui kujutada ette, et kõik need probleemid on lahendatud, on tõenäoliselt suur tõenäosus, et mitte midagi ei muutu oluliselt lõppkasutaja kogemuses. Jälgimine võib endiselt mitte pakkuda praktilist kasu kõige levinumates tõrkeotsingu stsenaariumites — isegi pärast selle juurutamist.
Selline ebaharilik jälgimine
Jaotatud jälgimine hõlmab mitmeid hajutatud komponente:
- rakenduste ja middleware'i varustamine kontrollimise vahenditega;
- jaotatud konteksti edastamine;
- jälgede kogumine;
- jälgede säilitamine;
- nende väljavõtmine ja visualiseerimine.
Palju arutelusid hajustatud jälgimise üle käsitleb seda kui teatud ühtset toimingut, mille ainus eesmärk on aidata süsteemi täieliku diagnostika tegemisel. Suures osas on see seotud sellega, kuidas ajalooliselt on kujunenud arusaamad hajustatud jälgimisest. , kui Zipkini lähtekoodid avaldati, mainiti, et [Zipkin] muudab Twitteri kiiremaks.Esimesed kaubanduslikud pakkumised jälgimise osas reklaamiti samuti kui .
Märkus tõlke kohta.Kuna edasine tekst oleks paremini arusaadav, määratlege kaks põhiterminit vastavalt :
- Span Tegu on hajutatud jälgimise põhikomponendiga. See kirjeldab mingit tööprotsessi (näiteks andmebaasi päringut) koos nimetuse, algus- ja lõppaega, sildistamisandmete, logide ja kontekstiga.
- Spannid sisaldavad tavaliselt viiteid teistele spanidele, mis võimaldab ühendada mitut span'i Trace — visualiseerimiseks, kuidas päring liigub hajutatud süsteemis.
Jälgimisandmed sisaldavad uskumatult väärtuslikku informatsiooni, mis suudab aidata selliste ülesannete lahendamisel nagu: tootmises testimine, hädaolukordade taastumise testimine, vigade sisestamise testimine jne. Tegelikult kasutavad mõned ettevõtted juba jälgimist selliste eesmärkide saavutamiseks. Alustuseks omab muid rakendusi peale lihtsalt spanide edastamise salvestussüsteemi:
- Näiteks Uber jälgimisandmeid testimise liikluse ja tootmisliikluse eristamiseks.
- Facebook jälgimisandmed kriitilise tee analüüsimiseks ja liikluse suunamiseks regulaarsete hädaolukordade taastumise testide ajal.
- Lisaks on sotsiaalvõrk Jupyteri märkmikud, mis võimaldavad arendajatel teostada suvalisi päringuid jälgimisandmete põhjal.
- Toetajad (lineaaži juhitud vea sisestamine) jälgivad jagatud jälgimisi vigade sisestamise katsetamiseks.
Ükski ülalnimetatud variant ei kuulu täielikult veaparandusstsenaariumisse, milles insener püüab lahendada probleemi, vaadates jälgimist. Kui asiküll siiski
jõuab veaparandusstsenaariumisse, jääb esmane liides diagrammaks traceview (kuigi mõned nimetavad seda ka «Gantt-diagrammiks» «kaskaaddiagrammiks» ). All või mõistamema «Gantt-diagrammiks» mõtlen kõik span'id ja kaasnevad metaandmed, mis koos moodustavad trace'i. Igat tüüpi avatud lähtekoodiga jälgimissüsteemid ning iga ärilise jälgimise lahendus pakuvad põhinevat «Gantt-diagrammiks» kasutajaliidest jälgimiste visualiseerimiseks, detailide jagamiseks ja filtriteks.
Probleem, mida olen seni kogenud kõigi jälgimissüsteemidega, on see, et lõppkokkuvõttes visualiseerimine (traceview) peaaegu täielikult peegeldab trace'i genereerimise protsessi eripära. I even when alternative visualizations are offered: intensity maps (heatmap), service topologies, latency histograms, ultimately they all reduce to «Gantt-diagrammiks».
Minevikus ma selle üle, et enamik "uuendusi" jälgimise valdkonnas seoses UI/UX-iga tundub olevat piiratud täiendavaid metaandmeid trace'i, lisades sinna kõrge kardinaalsusega teavet (high-cardinality) või pakkudes võimalust detailida konkreetseid span'e või teha päringuid between and within trace. Sellega samas «Gantt-diagrammiks» jätkub peamise visualiseerimisvahendina. Niikaua kui selline olukord püsib, jääb jaotatud jälgimine (kõige paremas seisus) neljandaks tõrkeotsingutööriistaks, jäädes metrikate, logide ja stack trace'ide taha, ja halvemal juhul muutub see tühiseks raha ja aja raiskamiseks.
Probleem traceview's
Eesmärk «Gantt-diagrammiks» — pakkuda täielikku pilti, kuidas konkreetne päring liikuda kõikide jaotatud süsteemi komponentide vahel, millega tal on seos. Mõned arenenumad jälgimissüsteemid võimaldavad detailida individuaalseid span'e ja vaadata ajaliselt jaotust sees ühe protsessi (kui span'id omavad funktsionaalseid piire).
Mikroteenuste arhitektuuri põhialus on idee, et organisatsiooni struktuur kasvab ettevõtte vajadustega. Mikroteenuste pooldajad väidavad, et erinevate äriülesannete jaotamine eraldi teenustele võimaldab väikestel, iseseisvatel arendustiimidel kontrollida nende teenuste kogu elutsüklit, võimaldades neil neid teenuseid iseseisvalt luua, testida ja juurutada. Küll aga on sellise jaotuse miinuseks see, et kaduma läheb teave selle kohta, kuidas iga teenus omavahel suhtleb. Sellistes tingimustes on jaotatud jälgimine hädavajalik tööriist keerukate Kui asi teenustevaheliste interaktsioonide jaoks.
Kui teil on tõeliselt , siis ei suuda keegi seda täielikku pilti peas hoida. Tegelikult on tööriista arendamine eeldusel, et see on üldse võimalik, midagi sellist nagu antipattern (ebaefektiivne ja viljatu lähenemine). Ideaalses olukorras on tõrgete tõrkeotsimiseks vajalik tööriist, mis aitaks otsinguala kitsendada, et insenerid saaksid keskenduda probleemiga seotud mõõtmete (teenused/kasutajad/hostid jne) alamhulgale. Rikete põhjuse väljaselgitamisel ei pea insenerid aru saama, mis kõikidel teenustel samal ajal juhtus, kuna see nõudmine oleks vastupidine mikroteenuste arhitektuuri põhialusele.
Küll aga esindab traceview just seda. Jah, mõned jälgimissüsteemid pakuvad kokku pressitud traceview't, kui span'ide arv jälgis on nii suur, et ei saa neid ühe visualiseerimise raames kuvada. Kuid isegi sellise lühendatud visualiseerimise suure teabehulga tõttu on insenerid siiski sunnitud selle "läbima" ning käsitsi kitsendama valikut probleemiallikate teenusteni. Kahjuks on masinad sel alal inimesest märgatavalt kiirem, vähem altid vigadele ja nende tulemused on rohkem korduvad. Teine põhjus, miks pean traceview meetodit vale valikuks, on see, et see sobib halvasti hüpoteeside põhjal töötamiseks. Oma olemuselt on tõrkeotsing - see
: iteratiivne protsess, mis algab hüpoteesiga, millele järgneb erinevate jälgimiste ja faktide kontrollimine, saadud süsteemist erinevates suundades, järeldused/üldistused ja edasine hüpoteesi tõe hindamine.
Võimalus kiire ja odav hüpoteeside testimine ja vaimse mudeli vastav kohandamine on nurgakivi silumise. Iga silumisseade peab olema interaktiivne ja kitsendama otsinguruumi või võimaldama kasutajal vale jälje korral tagasi minna ja keskenduda süsteemi teisele alale. Ideaalsed tööriistad teevad seda ennakult, juhtides kohe kasutaja tähelepanu potentsiaalselt probleemsetele ala.
Kahjuks, «Gantt-diagrammiks» ei saa nimetada tööriistaks interaktiivse kasutajaliidesega. Parim, millele selle kasutamisel loota, on tuvastada mõni allikas suurenenud viivitustest ja vaadata läbi kõik võimalikud sildid ja logid, mis sellega seotud. See ei aita inseneril tuvastada mustreid liikluses, näiteks viivituste jaotuse spetsiifikat või tuvastada korrelatsioone erinevate mõõtmiste vahel. võib aidata mõningatest neist probleemidest üle saada. Tõepoolest, edukast analüüsist, kus on kasutatud masinõpet, et tuvastada ebanormaalseid span'e ja identifitseerida alamhulk silte, mis võiksid olla seotud ebanormaalse käitumisega. Sellegipoolest ei ole ma siiani kohanud veenvaid visualiseerimisi leidudest, mis on tehtud masinõppe või andmeanalüüsi abil span'idega, mis oleks oluliselt erinevad traceview'st või DAG-ist (suunatud akitsüklilisest graafist).
Span'id on liiga madala tasemega
Põhiprobleem traceview's on see, et span'id on liiga madala tasemega primitiivid nii viivituste (latency) analüüsimiseks kui ka juurpõhjuste analüüsimiseks. See on sama, mis analüüsida üksikuid protsessorikäske, püüdes eemaldada erandit, teades, et on olemas palju kõrgema tasemega tööriistu, nagu backtrace, millega on palju mugavam töötada.
Lisaks, ma julgen väita järgmist: ideaalis ei vaja me üldse täielikku pilti töövoo ajal esineva taotluse küsimus, mida esitavad kaasaegsed jälgimisriistad. Selle asemel on vajalik kõrgema taseme abstraktsioon, mis sisaldab teavet selle kohta, mida vale läks (sama nagu backtrace), koos teatud konteksti. Selle asemel, et vaadata kogu jälge, eelistan ma näha osa, kus toimub midagi huvitavat või ebatavalist. Praegu toimub otsing käsitsi: insener saab jälje ja analüüsib iseseisvalt span’e, otsides midagi huvitavat. Lähenemine, kus inimesed vaatavad span’e eraldi jälgedes lootuses avastada kahtlast tegevust, ei ole absoluutselt skaleeritav (eriti kui nad peavad mõtlema kõikidele metaandmetele, mis on kodeeritud erinevatesse span’idesse, nagu span ID, RPC meetodi nimi, span’i kestus, logid, sildid jne).
Alternatiivid traceview'le
Jälgimise tulemused on kõige kasulikumad, kui neid saab visualiseerida nii, et saaksime mitte triviaalset ülevaadet sellest, mis toimub omavahel seotud süsteemi osades. Kuni selle on olemas, jääb tõrkeotsing suuresti inertiaks ja sõltub kasutaja võimetest märgata õigeid korrelatsioone, kontrollida õigeid süsteemi osi või kokku panna mosaiiki – erinevalt tööriista, mis aitab kasutajal neid hüpoteese formuleerida.
Ma ei ole visuaalne disainer ega UX-spetsialist, kuid järgmises osas tahan jagada mõningaid ideid selle kohta, kuidas sellised visualiseerimised võiksid välja näha.
Fookus spetsiifiliste teenuste peale
Olukordades, kus tööstus konsolideerib end ideede ümber , tundub mõistlik, et eraldi meeskonnad peaksid kõigepealt jälgima, kuidas nende teenused vastavad nendele eesmärkidele. Sellest tuleneb, et teenusele orienteeritud visualiseerimine sobib kõige paremini sellistele meeskondadele.
Jäljed, eriti ilma valikuta, on infoküllus iga jaotatud süsteemi komponendi kohta. Seda teavet saab sööta nutikale töötlejale, kes pakub kasutajatele teenusele orienteeritud leidmisi. Need võivad olla eelnevalt tuvastatud – veel enne, kui kasutaja jälgedele pilgu heidab:
- Läbivaateltakte hilistamisdiagrammid ainult väljapaistevate päringute jaoks (väljapaistevate päringute jaoks);
- Läbivaateltakte hilistamisdiagrammid olukordades, kus teenuse SLO-eesmärke ei saavutata;
- Kõige «tavalisemad», «huvitavamad» ja «veidramad» sildid päringutes, mis korduvalt ilmnevad;
- Hilinemised, kus sõltuvused teenus ei saavuta seatud SLO-eesmärke;
- Hilinemiste jaotamine erinevatele allavoolu teenustele.
Mõnele neist küsimustest ei saa sisseehitatud meetrikad lihtsalt vastata, sundides kasutajaid põhjalikult uurima span'e. Tulemuseks on äärmiselt kasutajasõbralik mehhanism.
Seoses sellega tekib küsimus: kuidas on lood keerukate suhetega erinevate teenuste vahel, mida juhivad erinevad meeskonnad? Kas «Gantt-diagrammiks» ei peeta seda kõige sobivamaks tööriistaks sellise olukorra selgitamiseks?
Mobiilaarendajad, stateless-teenuste omanikud, stateful-teenuste (nt andmebaaside) omanikud ja platvormi omanikud võivad olla huvitatud muust esitusest jaotatud süsteemi; «Gantt-diagrammiks» – see on liiga universaalne lahendus nende fundamentaalselt erinevate vajaduste jaoks. Isegi väga keerulises mikroteenuste arhitektuuris ei vaja teenuse omanikud sügavaid teadmisi rohkem kui kahe või kolme allavoolu ja ülesvoolu teenuse kohta. Essentsiaalselt on enamikul stsenaariumidest kasutajatel piisav vastata küsimustele, mis käsitlevad piiratust teenuste komplektist.
See on sarnane väikese teenuste alamkomplekti vaatlemisega läbi suurendusklaasi, et põhjalikult uurida. See võimaldab kasutajal esitada asjakohasemaid küsimusi nende teenuste keeruliste omavaheliste suhete ja nende vahetute sõltuvustega. See on sarnane backtrace'iga teenuste maailmas, kus insener teab, mida mis toimub, ning tal on mingi arusaam, mis toimub ümbritsevates teenustes, et mõista, miks.
Minu lähenemine on täielik vastand "ülevalt alla" lähenemisele, mis põhineb traceview'l, kus analüüs algab kogu jäljest ja liikuda järk-järgult üksikute span'ide juurde. Vastupidi, "alt üles" lähenemine algab väikese ala analüüsist, mis on lähedane võimaliku häire põhjusele, seejärel laiendatakse otsinguruumi vajadusel (võimaliku kaasamisega teistelt meeskondadelt, et analüüsida laiemat teenuste spektrit). Teine lähenemine sobib paremini algsete hüpoteeside kiireks kontrollimiseks. Pärast konkreetsete tulemuste saamist saab liikuda suunatud ja detailsemale analüüsile.
Topoloogia loomine
Konkreetsele teenusele seotud vaated võivad olla äärmiselt kasulikud, kui kasutaja teab, milline teenus või teenuste grupp on seotud viivituste suurenemise või vigade allikaid. Kuid keerulises süsteemis võib rikutud teenuse määramine osutuda probleemiks häire ajal, eriti kui teenustelt ei ole saadud veateateid.
Teenuste topoloogia loomine võib väga aidata välja selgitada, milline teenus näitab veaohtude või viivituste suurenemist, mis viib teenuse märgatava halvenemiseni. Kui räägin topoloogia loomise osas, ei mõtle ma mitte teenuste kaardile, mis kuvab igasugused süsteemis olevad teenused ja on tuntud oma . Selline esitus pole parem kui suunatud tsükliline graaf, mis põhineb traceview'l. Selle asemel tahaksin näha dünaamiliselt genereeritud teenuste topoloogiat, mis põhineb teatud atribuutidel, nagu veafrekvents, reageerimisaeg või mis tahes kasutaja määratud parameeter, mis aitab selgitada olukorda konkreetsete kahtlaste teenustega.
Vaatame näidet. Kujutage ette mingit hüpoteetilist uudiste saiti. Pealehe teenus (front page) vahetab andmeid Redis'iga, soovituste teenusega, reklaamiteenusega ja videoteenusega. Videoteenus võtab videoklipid S3-st, samas kui metaandmed tulevad DynamoDB-st. Soovituste teenus saab metaandmed DynamoDB-st, laadib andmeid Redis'ist ja MySQL'ist ning kirjutab sõnumeid Kafka-sse. Reklaamiteenus saab andmeid MySQL'ist ja kirjutab sõnumeid Kafka-sse.
Allpool on schematische pilt sellest topoloogiast (topoloogiat loovad paljud kaubanduslikud programmid jälgimiseks). See võib olla kasulik, kui on vaja mõista teenuste sõltuvusi. Siiski Kui asi, kui mõni teenus (ütleme, videoteenus) demonstreerib suurenenud reageerimisaega, pole selline topoloogia eriti kasulik.
Hüpoteetilise uudisteveebisaidi teenuste skeem
Sobivam oleks diagramm, mis on kujutatud allpool. Probleemne teenus (video) on kujutatud otse keskmes. Kasutaja märkab seda kohe. Sellest visualiseerimisest on selge, et videoteenus töötab ebanormaalselt, kuna S3 reageerimisaeg on suurenenud, mis mõjutab osa peamise lehe laadimiskiirust.
Dünaamiline topoloogia, mis kuvab ainult «huvitavaid» teenuseid
Dünaamiliselt genereeritud topoloogilised skeemid võivad olla tõhusamad kui staatilised teenuste kaardid, eriti elastsetes automaatselt skaleeritavates infrastruktuurides. Võimalus võrrelda ja vastandada teenuste topoloogiaid võimaldab kasutajal esitada asjakohasemaid küsimusi. Täpsemad küsimused süsteemi kohta toovad tõenäolisemalt kaasa parema arusaamise süsteemi toimimisest.
Võrdlev kuvamine
Veel üks kasulik visualiseerimine oleks võrreldav kuvamine. Praegu ei sobi jälgimised hästi kõrvuti võrdlemiseks, seetõttu võrreldakse sageli span'id. Peamine idee selles artiklis on see, et span'id on liiga madala tasemega, et saada kõige väärtuslikumat teavet jälgimise tulemustest.
Kaks jälgimist ei pruugi vajada põhimõtteliselt uusi visualiseerimisi. Tegelikult piisab millestki nagu histogramm, mis esindab samu andmeid, mis traceview. Üllatav, kuid isegi see lihtne meetod võib tuua palju rohkem kasu kui lihtsalt kahe jälgimise eraldi uurimine. Veelgi jõulisem oleks see võimalus. visualiseerida trace'ide võrdlemine kokkuvõttes. Oleks äärmiselt kasulik näha, kuidas hiljuti rakendatud andmebaasi konfiguratsiooni muudatus, kus on aktiveeritud GC (prügikoristus), mõjutab downstream-teenuse vastamisaega mitme tunni vältel. Kui see, mida ma siin kirjeldan, tundub sarnane A/B analüüsile infrastruktuuri muudatuste mõjude osas, siis te ei ole liiga kaugel tõest. paljude teenuste puhul tracing-uuringute tulemuste abil, siis te ei ole tõepoolest vale teel.
Kokkuvõte
Ma ei sea kahtluse alla trace'e kasulikkust. Usun siiralt, et ei ole teist meetodit, mis koguks nii rikkalikku, konteksti rikkast ja casual andmeid nagu need, mis on trace'is. Kuid ma usun ka, et kõik trace'ide lahendused kasutavad neid andmeid äärmiselt ebaefektiivselt. Nii kaua, kuni tracing- tööriistad on kinni trace view esitluses, on nad piiratud väärtusliku teabe maksimaalses kasutuses, mis on välja võetud trace'ide andmetest. Lisaks on oht, et edasi arendada täiesti mitte-sõbralik ja mitte-intuitiivne visuaalne liides, mis piirab tugevalt kasutaja võimet rakenduses vigu leida.
Komplekssete süsteemide tõrkeotsing, isegi uusimate tööriistade kasutamisel, on äärmiselt keeruline. Tööriistad peavad aitama arendajal formuleerida ja testida hüpoteesi, aktiivselt pakkudes asjakohast teavet, tuvastades anomaaliaid ja märkides viivituste jaotumise eripära. Selleks, et tracing muutuks arendajate eelistatud tööriistaks tootmisveakute tõrkeotsingul või probleemide lahendamisel, mis hõlmavad erinevaid teenuseid, on vajalikud originaalsed kasutajaliideste ja visualisatsioonide lähenemised, mis vastavad rohkem arendajate mentaalsele mudelile, kes neid teenuseid loovad ja haldavad.
Nõuab tõsist vaimset pingutust, et projekteerida süsteem, mis esindab erinevaid signaale, mis on kätketud tracing'u tulemustes, viisil, mis on optimeeritud analüüsi ja järelduste lihtsustamiseks. On vajalik mõelda, kuidas abstraktida süsteemi topoloogiat tõrkeotsingute ajal, et aidata kasutajal ületada pimedad alad, ilma et peaks vaatama üksikute trace'ide või span'ide sisse.
Meile on vaja häid abstraktsiooni ja tasandamise võimalusi (eriti kasutajaliideses). Need, mis sobivad hästi hüpoteeside põhjal tehtavasse tõrkeotsingusse, kus saab iteratiivselt küsimusi esitada ja hüpoteese kontrollida. Need ei lahenda automaatselt kõiki vaatamisprobleeme, kuid aitavad kasutajatel oma intuitsiooni lihvida ja tasakaalustatud küsimusi formuleerida. Kutsub üles sügavamale ja uuenduslikumale lähenemisele visualiseerimises. Siin on tõeline perspektiiv silmapiiri laiendamiseks.
P.S. tõlkijalt
Lugege ka meie blogist:
- «»;
- «»;
- «».
Allikas: habr.com
