Bilješka. prev.: Autorica ovog materijala je Cindy Sridharan, inženjerka u imgixu koja se specijalizirala za razvoj API-ja i, posebno, testiranje mikroservisa. U ovom materijalu ona dijeli svoju detaljnu viziju trenutnih problema u području distribuiranog praćenja, gdje, po njezinom mišljenju, nedostaje istinski učinkovitih alata za rješavanje hitnih problema.
[Ilustracija preuzeta sa o distribuiranom praćenju.]
Smatra se da je teško provedivo, a povrat na to . Mnogo je razloga zašto je praćenje problematično, a često se navode napori uključeni u konfiguriranje svake komponente sustava za prijenos odgovarajućih zaglavlja sa svakim zahtjevom. Iako ovaj problem postoji, on nipošto nije nepremostiv. Usput, to ne objašnjava zašto programeri baš ne vole praćenje (čak i kada već funkcionira).
Glavni izazov s distribuiranim praćenjem nije prikupljanje podataka, standardiziranje formata za distribuciju i predstavljanje rezultata ili određivanje kada, gdje i kako uzorkovati. Ne pokušavam zamisliti trivijalno ovi "problemi razumljivosti" su, zapravo, prilično značajni tehnički i (ako razmatramo istinski otvoreni izvor) ) političke izazove koje treba prevladati da bi se ti problemi mogli smatrati riješenima.
No, ako zamislimo da su svi ovi problemi riješeni, postoji velika vjerojatnost da se ništa bitno neće promijeniti u smislu iskustvo krajnjeg korisnika. Praćenje još uvijek možda neće biti od praktične koristi u najčešćim scenarijima otklanjanja pogrešaka—čak i nakon što je implementirano.
Takav drugačiji trag
Distribuirano praćenje uključuje nekoliko različitih komponenti:
- opremanje aplikacija i međuprograma kontrolnim alatima;
- prijenos distribuiranog konteksta;
- prikupljanje tragova;
- skladištenje tragova;
- njihovo izdvajanje i vizualizacija.
Puno razgovora o distribuiranom praćenju ima tendenciju da ga tretira kao neku vrstu unarne operacije čija je jedina svrha pomoći u potpunoj dijagnostici sustava. To je uglavnom zbog toga kako su ideje o distribuiranom praćenju povijesno oblikovane. U , napravljen kada su Zipkinovi izvori otvoreni, spomenuto je da to [Zipkin] čini Twitter bržim. Prve komercijalne ponude za praćenje također su promovirane kao .
Bilješka. prev.: Radi lakšeg razumijevanja daljnjeg teksta, definirajmo dva osnovna pojma prema :
- Raspon — osnovni element distribuiranog praćenja. To je opis određenog tijeka rada (na primjer, upit baze podataka) s nazivom, vremenom početka i završetka, oznakama, zapisima i kontekstom.
- Rasponi obično sadrže veze s drugim rasponima, omogućujući kombiniranje više raspona Trag — vizualizacija života zahtjeva dok se kreće kroz distribuirani sustav.
Tragovi sadrže nevjerojatno vrijedne podatke koji mogu pomoći u zadacima kao što su testiranje proizvodnje, testiranje oporavka od katastrofe, testiranje ubacivanja pogrešaka itd. Zapravo, neke tvrtke već koriste praćenje u slične svrhe. Počnimo s ima i druge namjene osim jednostavnog premještanja raspona u sustav za pohranu:
- Na primjer, Uber rezultate praćenja radi razlikovanja testnog prometa od proizvodnog prometa.
- Facebook podaci o praćenju za analizu kritičnog puta i za prebacivanje prometa tijekom redovitih testova oporavka od katastrofe.
- Također društvena mreža Jupyter prijenosna računala koja programerima omogućuju pokretanje proizvoljnih upita o rezultatima praćenja.
- Pristaše (Lineage Driven Failure Injection) distribuirani tragovi za testiranje s ubacivanjem pogrešaka.
Nijedna od gore navedenih opcija ne odnosi se u potpunosti na scenarij otklanjanje pogrešaka, tijekom kojeg inženjer pokušava riješiti problem gledajući trag.
Kada dođe još dosegne skriptu za otklanjanje pogrešaka, primarno sučelje ostaje dijagram traceview (iako ga neki zovu i "Gantogram" ili "vodopad dijagram"). Pod, ispod traceview я sve raspone i popratne metapodatke koji zajedno čine trag. Svaki sustav praćenja otvorenog koda, kao i svako komercijalno rješenje za praćenje, nudi traceview korisničko sučelje za vizualizaciju, detaljiziranje i filtriranje tragova.
Problem sa svim sustavima praćenja koje sam do sada vidio je da rezultat vizualizacija (traceview) gotovo u potpunosti odražava značajke procesa stvaranja tragova. Čak i kada se predlože alternativne vizualizacije: toplinske karte, topologije usluga, histogrami latencije, one se u konačnici svode na traceview.
U prošlosti sam na koje se čini da je većina "inovacija" u UI/UX praćenju ograničena dodatne metapodatke u praćenju, ulažući u njih informacije s visokom kardinalnošću (visoka kardinalnost) ili pružanje mogućnosti dubliranja u određene raspone ili pokretanja upita inter- i intra-trace... Pri čemu traceview ostaje primarni alat za vizualizaciju. Sve dok se ovakvo stanje nastavi, distribuirano praćenje će (u najboljem slučaju) zauzeti 4. mjesto kao alat za otklanjanje pogrešaka, nakon metrike, dnevnika i praćenja stogova, au najgorem slučaju ispast će kao gubitak novca i vremena.
Problem s traceviewom
sudbina traceview — pružiti cjelovitu sliku kretanja jednog zahtjeva kroz sve komponente distribuiranog sustava na koji se odnosi. Neki napredniji sustavi praćenja omogućuju vam dubljenje pojedinačnih raspona i pregled raščlambe tijekom vremena u jedan proces (kada rasponi imaju funkcionalne granice).
Osnovna premisa arhitekture mikroservisa je ideja da organizacijska struktura raste s potrebama tvrtke. Zagovornici mikrousluga tvrde da raspodjela različitih poslovnih zadataka u pojedinačne usluge omogućuje malim, autonomnim razvojnim timovima da kontroliraju cijeli životni ciklus takvih usluga, dajući im mogućnost da samostalno izgrade, testiraju i implementiraju te usluge. Međutim, nedostatak ove distribucije je gubitak informacija o tome kako svaka usluga komunicira s drugima. U takvim uvjetima, distribuirano praćenje tvrdi da je nezamjenjiv alat za otklanjanje pogrešaka složene interakcije između usluga.
Ako stvarno , onda to nitko nije u stanju držati u glavi dovršen slika. Zapravo, razvijanje alata na temelju pretpostavke da je to uopće moguće je nešto poput anti-obrasca (neučinkovit i neproduktivan pristup). U idealnom slučaju, otklanjanje pogrešaka zahtijeva alat koji pomaže suzite područje pretraživanja, tako da se inženjeri mogu usredotočiti na podskup dimenzija (usluge/korisnici/domaćini, itd.) relevantnih za scenarij problema koji se razmatra. Prilikom utvrđivanja uzroka kvara, inženjeri nisu dužni razumjeti što se dogodilo tijekom kvara sve usluge odjednom, jer bi takav zahtjev bio u suprotnosti sa samom idejom arhitekture mikroservisa.
Međutim, traceview jest naime Ovaj. Da, neki sustavi praćenja nude komprimirane prikaze tragova kada je broj raspona u tragu toliko velik da se ne mogu prikazati u jednoj vizualizaciji. Međutim, zbog velike količine informacija sadržanih čak iu tako ogoljenoj vizualizaciji, inženjeri i dalje prisilno "prosijati", ručno sužavajući izbor na skup usluga koje su izvori problema. Nažalost, u ovom području strojevi su puno brži od ljudi, manje su skloni pogreškama, a rezultati su im ponovljiviji.
Još jedan razlog zašto mislim da je traceview pogrešan je taj što nije dobar za otklanjanje pogrešaka na temelju hipoteza. U svojoj srži otklanjanje pogrešaka je iterativni proces koji započinje hipotezom, nakon čega slijedi provjera različitih zapažanja i činjenica dobivenih iz sustava duž različitih vektora, zaključci/generalizacije i daljnja procjena istinitosti hipoteze.
Prilika brzo i jeftino testiranje hipoteza i u skladu s tim poboljšavanje mentalnog modela je kamen temeljac otklanjanje pogrešaka Svaki alat za otklanjanje pogrešaka trebao bi biti interaktivni i suziti prostor pretraživanja ili, u slučaju lažnog traga, omogućiti korisniku da se vrati i usredotoči na drugo područje sustava. Savršen alat će to učiniti proaktivno, odmah skrećući pozornost korisnika na potencijalna problematična područja.
jao traceview ne može se nazvati alatom s interaktivnim sučeljem. Najbolje čemu se možete nadati kada ga koristite je pronaći neki izvor povećane latencije i pogledati sve moguće oznake i zapise povezane s njim. Ovo ne pomaže inženjeru da identificira uzorci u prometu, kao što su specifičnosti distribucije kašnjenja, ili otkriti korelacije između različitih mjerenja. može pomoći u rješavanju nekih od ovih problema. Stvarno, uspješnu analizu korištenjem strojnog učenja za identifikaciju nenormalnih raspona i identificiranje podskupa oznaka koje mogu biti povezane s nepravilnim ponašanjem. Međutim, tek trebam vidjeti uvjerljive vizualizacije nalaza strojnog učenja ili rudarenja podataka primijenjenih na raspone koji se značajno razlikuju od traceviewa ili DAG-a (usmjereni aciklički graf).
Rasponi su preniski
Temeljni problem s traceviewom je taj rasponi primitivi su preniske razine i za analizu latencije i za analizu temeljnog uzroka. To je poput raščlanjivanja pojedinačnih naredbi procesora da biste pokušali riješiti iznimku, znajući da postoje alati mnogo više razine poput povratnog praćenja s kojima je mnogo prikladnije raditi.
Štoviše, uzet ću si slobodu ustvrditi sljedeće: u idealnom slučaju, ne trebamo punu sliku dogodilo tijekom životnog ciklusa zahtjeva, što je predstavljeno modernim alatima za praćenje. Umjesto toga, potreban je neki oblik apstrakcije više razine koji sadrži informacije o čemu pošlo krivo (slično povratnom tragu), zajedno s nekim kontekstom. Umjesto da gledam cijeli trag, radije ga vidim часть, gdje se događa nešto zanimljivo ili neobično. Trenutno se pretraga obavlja ručno: inženjer prima trag i samostalno analizira raspone u potrazi za nečim zanimljivim. Pristup ljudi koji zure u raspone u pojedinačnim tragovima u nadi da će otkriti sumnjivu aktivnost uopće nije skaliran (pogotovo kada moraju shvatiti sve metapodatke kodirane u različitim rasponima, kao što su ID raspona, naziv RPC metode, trajanje raspona 'a, dnevnici, oznake itd.).
Alternative za traceview
Rezultati praćenja najkorisniji su kada se mogu vizualizirati na način koji pruža netrivijalan uvid u ono što se događa u međusobno povezanim dijelovima sustava. Dok se to ne dogodi, proces uklanjanja pogrešaka uglavnom ostaje inertan i ovisi o sposobnosti korisnika da uoči prave korelacije, provjeri prave dijelove sustava ili sastavi dijelove slagalice - za razliku od alat, pomažući korisniku da formulira te hipoteze.
Nisam vizualni dizajner ili UX stručnjak, ali u sljedećem odjeljku želim podijeliti nekoliko ideja o tome kako bi te vizualizacije mogle izgledati.
Usredotočite se na specifične usluge
U vrijeme kada se industrija konsolidira oko ideja , čini se razumnim da pojedinačni timovi trebaju dati prioritet osiguravanju da su njihove usluge usklađene s tim ciljevima. Iz toga slijedi da uslužno orijentirani vizualizacija je najprikladnija za takve timove.
Tragovi, posebno bez uzorkovanja, riznica su informacija o svakoj komponenti distribuiranog sustava. Ove informacije mogu se unijeti u lukavi procesor koji će opskrbljivati korisnike uslužno orijentirani Oni se mogu identificirati unaprijed - čak i prije nego što korisnik pogleda tragove:
- Dijagrami distribucije kašnjenja samo za vrlo istaknute zahtjeve (iznimni zahtjevi);
- Dijagrami distribucije kašnjenja za slučajeve kada ciljevi usluge SLO nisu postignuti;
- Najčešće “uobičajene”, “zanimljive” i “čudne” oznake u upitima koji najčešće se ponavljaju;
- Analiza latencije za slučajeve u kojima ovisno o usluge ne postižu svoje ČVN ciljeve;
- Analiza latencije za razne nizvodne usluge.
Na neka od ovih pitanja jednostavno nema odgovora ugrađena metrika, što tjera korisnike da pomno provjeravaju raspone. Kao rezultat, imamo mehanizam koji je krajnje neprijateljski raspoložen prema korisnicima.
To postavlja pitanje: što je sa složenim interakcijama između različitih usluga koje kontroliraju različiti timovi? zar ne traceview ne smatra se najprikladnijim alatom za isticanje takve situacije?
Razvojne programere mobilnih uređaja, vlasnike usluga bez statusa, vlasnike upravljanih usluga sa statusom (poput baza podataka) i vlasnike platformi moglo bi zanimati nešto drugo prezentacija distribuirani sustav; traceview previše je općenito rješenje za ove bitno različite potrebe. Čak i u vrlo složenoj mikroservisnoj arhitekturi, vlasnici servisa ne trebaju duboko poznavanje više od dvije ili tri uzvodne i nizvodne usluge. U osnovi, u većini scenarija, korisnici trebaju samo odgovoriti na pitanja u vezi ograničen skup usluga.
To je kao da mali podskup usluga gledate kroz povećalo da biste ga pažljivo proučili. Ovo će omogućiti korisniku da postavi goruća pitanja u vezi sa složenim interakcijama između ovih usluga i njihovim neposrednim ovisnostima. Ovo je slično povratnom tragu u svijetu usluga, gdje inženjer zna da pogrešno, a također ima određeno razumijevanje o tome što se događa u okolnim uslugama koje treba razumjeti zašto.
Pristup koji promičem upravo je suprotan pristupu odozgo prema dolje, pristupu temeljenom na prikazu tragova, gdje analiza počinje s cijelim tragom, a zatim se postupno spušta do pojedinačnih raspona. Nasuprot tome, pristup odozdo prema gore počinje analizom malog područja u blizini potencijalnog uzroka incidenta, a zatim po potrebi proširuje prostor pretraživanja (s potencijalom uključivanja drugih timova za analizu šireg raspona usluga). Drugi pristup je prikladniji za brzo testiranje početnih hipoteza. Kada se dobiju konkretni rezultati, moći će se prijeći na ciljaniju i detaljniju analizu.
Izgradnja topologije
Pogledi specifični za uslugu mogu biti nevjerojatno korisni ako korisnik zna koji usluga ili grupa usluga odgovorna je za povećanje latencije ili izazivanje pogrešaka. Međutim, u složenom sustavu, identificiranje servisa koji vrijeđa može biti netrivijalan zadatak tijekom kvara, posebno ako usluge nisu prijavile nikakve poruke o pogrešci.
Izgradnja topologije usluge može biti od velike pomoći u otkrivanju koja usluga doživljava skok u stopama pogrešaka ili povećanje latencije što uzrokuje primjetno pogoršanje usluge. Kada govorim o izgradnji topologije, ne mislim na to karta usluga, prikazujući sve usluge dostupne u sustavu i poznate po svojim . Ovaj prikaz nije ništa bolji od traceviewa koji se temelji na usmjerenom acikličkom grafu. Umjesto toga volio bih vidjeti dinamički generirana servisna topologija, na temelju određenih atributa kao što su stopa pogreške, vrijeme odziva ili bilo koji korisnički definirani parametar koji pomaže razjasniti situaciju s određenim sumnjivim uslugama.
Uzmimo primjer. Zamislimo hipotetsku stranicu s vijestima. Usluga početne stranice (Naslovna strana) razmjenjuje podatke s Redisom, s uslugom preporuke, s uslugom oglašavanja i video uslugom. Video servis preuzima video sa S3 i metapodatke iz DynamoDB. Usluga preporuke prima metapodatke iz DynamoDB-a, učitava podatke iz Redisa i MySQL-a i piše poruke Kafki. Usluga oglašavanja prima podatke iz MySQL-a i piše poruke Kafki.
Ispod je shematski prikaz ove topologije (mnogi komercijalni programi za usmjeravanje grade topologiju). Može biti korisno ako trebate razumjeti ovisnosti o uslugama. Međutim, tijekom otklanjanje pogrešaka, kada određena usluga (recimo, video usluga) pokazuje povećano vrijeme odziva, takva topologija nije baš korisna.
Servisni dijagram hipotetske stranice s vijestima
Donji dijagram bi bio bolji. Postoji problem s uslugom (video) prikazan točno u sredini. Korisnik to odmah primijeti. Iz ove vizualizacije postaje jasno da video servis radi nenormalno zbog povećanja vremena odziva S3, što utječe na brzinu učitavanja dijela glavne stranice.
Dinamička topologija koja prikazuje samo "zanimljive" usluge
Dinamički generirane topologije mogu biti učinkovitije od statičkih mapa usluga, posebno u elastičnim infrastrukturama s automatskim skaliranjem. Mogućnost usporedbe i kontrasta topologija usluga omogućuje korisniku postavljanje relevantnijih pitanja. Preciznija pitanja o sustavu vjerojatnije će dovesti do boljeg razumijevanja načina na koji sustav funkcionira.
Usporedni prikaz
Još jedna korisna vizualizacija bio bi usporedni prikaz. Trenutačno tragovi nisu prikladni za usporedne usporedbe, pa usporedbe obično jesu rasponi. A glavna ideja ovog članka je upravo ta da su rasponi preniske razine da bi izvukli najvrednije informacije iz rezultata praćenja.
Usporedba dva traga ne zahtijeva bitno nove vizualizacije. Zapravo, dovoljno je nešto poput histograma koji predstavlja iste informacije kao traceview. Iznenađujuće, čak i ova jednostavna metoda može donijeti puno više ploda nego jednostavno proučavanje dva traga odvojeno. Još bi moćnija bila mogućnost vizualizirati usporedba tragova Ukupno. Bilo bi iznimno korisno vidjeti kako nedavno postavljena promjena konfiguracije baze podataka za omogućavanje GC-a (sakupljanje smeća) utječe na vrijeme odgovora nizvodne usluge na skali od nekoliko sati. Ako ono što ovdje opisujem zvuči kao A/B analiza utjecaja infrastrukturnih promjena u mnogim službama koristeći rezultate tragova, onda niste predaleko od istine.
Zaključak
Ne dovodim u pitanje korisnost samog praćenja. Iskreno vjerujem da ne postoji druga metoda za prikupljanje tako bogatih, kauzalnih i kontekstualnih podataka kao što je ona sadržana u tragu. Međutim, također vjerujem da sva rješenja za praćenje koriste te podatke krajnje neučinkovito. Sve dok alati za praćenje ostaju zaglavljeni na prikazu prikaza praćenja, bit će ograničeni u svojoj sposobnosti da maksimalno iskoriste vrijedne informacije koje se mogu izvući iz podataka sadržanih u tragovima. Osim toga, postoji rizik od daljnjeg razvoja potpuno neprijateljskog i neintuitivnog vizualnog sučelja koje će ozbiljno ograničiti mogućnost korisnika da otkloni pogreške u aplikaciji.
Otklanjanje pogrešaka u složenim sustavima, čak i s najnovijim alatima, nevjerojatno je teško. Alati bi trebali pomoći programeru da formulira i testira hipotezu, aktivno pružanje relevantne informacije, identificiranje outliera i bilježenje značajki u distribuciji kašnjenja. Kako bi praćenje postalo alat izbora za programere pri otklanjanju grešaka u proizvodnji ili rješavanju problema koji se protežu na više usluga, potrebna su originalna korisnička sučelja i vizualizacije koji su više u skladu s mentalnim modelom programera koji stvaraju i upravljaju tim uslugama.
Bit će potreban značajan mentalni napor da se dizajnira sustav koji će predstavljati različite signale dostupne u rezultatima praćenja na način koji je optimiziran za jednostavnu analizu i zaključivanje. Morate razmisliti o tome kako apstrahirati topologiju sustava tijekom otklanjanja pogrešaka na način koji pomaže korisniku da prevlada slijepe točke bez gledanja pojedinačnih tragova ili raspona.
Potrebne su nam dobre mogućnosti apstrakcije i slojevitosti (osobito u korisničkom sučelju). One koje bi se dobro uklopile u proces otklanjanja pogrešaka vođen hipotezom, gdje možete iterativno postavljati pitanja i testirati hipoteze. Oni neće automatski riješiti sve probleme uočljivosti, ali će pomoći korisnicima da izoštre svoju intuiciju i formuliraju pametnija pitanja. Pozivam na promišljeniji i inovativniji pristup vizualizaciji. Ovdje postoji stvarna perspektiva za širenje horizonata.
PS od prevoditelja
Pročitajte i na našem blogu:
- «»;
- «»;
- «".
Izvor: www.habr.com