Bilješka. transl.: Autor ovog materijala je Cindy Sridharan, inženjer u imgix-u koji je specijaliziran za razvoj API-ja i, posebno, testiranje mikroservisa. U ovom materijalu ona iznosi svoju detaljnu viziju aktuelnih problema u oblasti distribuiranog praćenja, gdje, prema njenom mišljenju, nedostaju istinski efikasni alati za rješavanje hitnih problema.
[Ilustracija preuzeta sa o distribuiranom praćenju.]
Veruje se da je to teška za implementaciju i povrat na to . Postoji mnogo razloga zašto je praćenje problematično, često navodeći trud uključen u konfiguraciju svake komponente sistema za prijenos odgovarajućih zaglavlja sa svakim zahtjevom. Iako ovaj problem postoji, on nikako 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 da zamislim trivijalan ovi "problemi s razumljivošću" su, u stvari, prilično značajni tehnički i (ako razmatramo istinski Open Source) ) politički izazovi koje je potrebno savladati da bi se ovi problemi smatrali riješenim.
Međutim, ako zamislimo da su svi ovi problemi riješeni, postoji velika vjerovatnoća da se ništa bitno neće promijeniti u smislu iskustvo krajnjeg korisnika. Praćenje možda i dalje neće biti od praktične koristi u najčešćim scenarijima otklanjanja grešaka - čak i nakon što je implementirano.
Tako drugačiji trag
Distribuirano praćenje uključuje nekoliko različitih komponenti:
- opremanje aplikacija i međuprograma kontrolnim alatima;
- distribuirani prijenos konteksta;
- prikupljanje tragova;
- skladištenje tragova;
- njihovo izdvajanje i vizualizacija.
Mnogo priča o distribuiranom praćenju ima tendenciju da ga tretira kao neku vrstu unarne operacije čija je jedina svrha da pomogne u potpunoj dijagnostici sistema. To je uglavnom zbog toga kako su se ideje o distribuiranom praćenju povijesno formirale. IN , napravljenog prilikom otvaranja Zipkinovih izvora, spomenuto je da to [Zipkin] čini Twitter bržim. Prve komercijalne ponude za praćenje su također promovirane kao .
Bilješka. transl.: Da bismo olakšali razumijevanje daljnjeg teksta, definirajmo dva osnovna pojma prema :
- raspon — osnovni element distribuiranog praćenja. To je opis određenog toka posla (na primjer, upit baze podataka) s imenom, vremenom početka i završetka, oznakama, zapisnicima i kontekstom.
- Rasponi obično sadrže veze s drugim rasponima, što omogućava kombiniranje više raspona Trace — vizualizacija života zahtjeva dok se kreće kroz distribuirani sistem.
Tragovi sadrže nevjerovatno vrijedne podatke koji mogu pomoći u zadacima kao što su testiranje proizvodnje, testiranje oporavka od katastrofe, testiranje ubrizgavanja greške itd. Zapravo, neke kompanije već koriste praćenje u slične svrhe. Počnimo sa ima i druge namjene osim jednostavnog premještanja raspona u sistem za skladištenje:
- Na primjer, Uber praćenje rezultata da se napravi razlika između testnog saobraćaja i proizvodnog saobraćaja.
- Facebook podaci praćenja za analizu kritične putanje i za prebacivanje saobraćaja tokom redovnih testova oporavka od katastrofe.
- Takođe društvena mreža Jupyter notebook računari koji omogućavaju programerima da pokreću proizvoljne upite o rezultatima praćenja.
- Followers (Lineage Driven Failure Injection) distribuirani tragovi za testiranje sa ubacivanjem greške.
Nijedna od gore navedenih opcija ne odnosi se u potpunosti na scenarij otklanjanje grešaka, tokom kojeg inženjer pokušava riješiti problem gledajući trag.
Kad dođe još dođe do skripte za otklanjanje grešaka, primarni interfejs ostaje dijagram traceview (iako ga neki nazivaju i "Gantogram" ili "dijagram vodopada"). Ispod traceview я svi rasponi i prateći metapodaci koji zajedno čine trag. Svaki sistem praćenja otvorenog koda, kao i svako komercijalno rješenje za praćenje, nudi a traceview korisničko sučelje za vizualizaciju, detaljizaciju i filtriranje tragova.
Problem sa svim sistemima praćenja koje sam do sada vidio je to što rezultira vizualizacija (traceview) gotovo u potpunosti odražava karakteristike procesa generiranja tragova. Čak i kada se predlože alternativne vizualizacije: toplotne karte, topologije usluga, histogrami kašnjenja, oni se na kraju ipak svode na traceview.
U prošlosti sam čini se da je većina "inovacija" u UI/UX praćenju ograničena dodatni metapodaci u tragovima, ulažući u njih informacije visoke kardinalnosti (visoke kardinalnosti) ili pružanje mogućnosti da se detaljno analiziraju određeni rasponi ili da se izvode upiti inter- i intra-trace... U č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 grešaka, nakon metrike, dnevnika i praćenja stekova, au najgorem slučaju će se ispostaviti kao gubitak novca i vremena.
Problem sa prikazom praćenja
Svrha traceview — pružiti potpunu sliku kretanja jednog zahtjeva kroz sve komponente distribuiranog sistema na koji se odnosi. Neki napredniji sistemi praćenja vam omogućavaju da se udubite u pojedinačne raspone i pogledate kvar tokom vremena unutar jedan proces (kada rasponi imaju funkcionalne granice).
Osnovna premisa mikroservisne arhitekture je ideja da organizaciona struktura raste sa potrebama kompanije. Zagovornici mikroservisa tvrde da distribucija različitih poslovnih zadataka u pojedinačne usluge omogućava malim, autonomnim razvojnim timovima da kontrolišu čitav životni ciklus takvih usluga, dajući im mogućnost da samostalno grade, testiraju i implementiraju te usluge. Međutim, nedostatak ove distribucije je gubitak informacija o tome kako svaka usluga komunicira s drugima. U takvim uslovima, distribuirano praćenje tvrdi da je nezamjenjiv alat za otklanjanje grešaka složene interakcije između usluga.
Ako zaista , onda to nijedna osoba ne može zadržati u svojoj glavi kompletan slika. U stvari, razvijanje alata zasnovanog na pretpostavci da je to uopšte moguće je nešto kao anti-uzorak (neefikasan i neproduktivan pristup). U idealnom slučaju, otklanjanje grešaka zahtijeva alat koji pomaže suzite područje pretraživanja, tako da se inženjeri mogu fokusirati na podskup dimenzija (usluge/korisnici/hostovi, itd.) relevantnih za scenarij problema koji se razmatra. Prilikom utvrđivanja uzroka kvara, inženjeri ne moraju razumjeti šta se dogodilo tokom kvara sve usluge odjednom, budući da bi takav zahtjev bio u suprotnosti sa samom idejom mikroservisne arhitekture.
Međutim, prikaz praćenja jeste naime Ovo. Da, neki sistemi praćenja nude komprimirane prikaze praćenja kada je broj raspona u praćenju toliko velik da se ne mogu prikazati u jednoj vizualizaciji. Međutim, zbog velike količine informacija sadržanih čak i u tako smanjenoj vizualizaciji, inženjeri i dalje prisilno “prosejati” ga, ručno sužavajući izbor na skup usluga koje su izvor problema. Nažalost, na ovom polju mašine su mnogo brže od ljudi, manje su sklone greškama, a njihovi rezultati su ponovljiviji.
Drugi razlog zbog kojeg mislim da je pregled praćenja pogrešan je zato što nije dobar za otklanjanje grešaka vođeno hipotezama. U svojoj srži je otklanjanje grešaka iterativno proces koji počinje hipotezom, nakon čega slijedi provjera različitih zapažanja i činjenica dobijenih iz sistema duž različitih vektora, zaključaka/generalizacija i daljnja procjena istinitosti hipoteze.
Sposobnost brzo i jeftino testiranje hipoteza i poboljšanje mentalnog modela u skladu s tim je kamen temeljac otklanjanje grešaka Bilo koji alat za otklanjanje grešaka bi trebao biti interaktivno i suzite prostor za pretragu ili, u slučaju lažnog traga, omogućite korisniku da se vrati i fokusira na drugo područje sistema. Savršen alat će to učiniti proaktivno, odmah skrećući pažnju korisnika na potencijalna problematična područja.
jao, traceview ne može se nazvati alatom sa interaktivnim interfejsom. 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 se identifikuje uzorci u saobraćaju, kao što su specifičnosti distribucije kašnjenja, ili otkriti korelacije između različitih mjerenja. može pomoći da se zaobiđu neki od ovih problema. stvarno, uspješna analiza korištenjem strojnog učenja za identifikaciju anomalnih raspona i identifikaciju podskupa oznaka koje mogu biti povezane s anomalnim ponašanjem. Međutim, još nisam vidio uvjerljive vizualizacije nalaza strojnog učenja ili rudarenja podataka primijenjenih na raspone koji se značajno razlikuju od prikaza praćenja ili DAG-a (usmjereni aciklički graf).
Rasponi su preniski
Osnovni problem sa praćenjem je to rasponi su primitivi preniskog nivoa za analizu kašnjenja i analizu uzroka. To je kao raščlanjivanje pojedinačnih komandi procesora da se pokuša riješiti izuzetak, znajući da postoje alati višeg nivoa kao što je backtrace sa kojima je mnogo pogodnije raditi.
Štaviše, uzeću sebi slobodu da tvrdim sledeće: u idealnom slučaju, ne trebamo puna slika dogodio tokom životnog ciklusa zahtjeva, što je predstavljeno modernim alatima za praćenje. Umjesto toga, potreban je neki oblik apstrakcije višeg nivoa koji sadrži informacije o tome šta pošlo po zlu (slično kao unatrag), zajedno s nekim kontekstom. Umjesto da gledam cijeli trag, radije ga vidim dio, gdje se dešava 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 bulje u raspone u pojedinačnim tragovima u nadi da će otkriti sumnjivu aktivnost uopće se ne povećava (posebno kada moraju razumjeti sve metapodatke kodirane u različitim rasponima, kao što su ID raspona, naziv RPC metode, trajanje raspona 'a, evidencije, oznake, itd.).
Alternative za traceview
Rezultati praćenja su najkorisniji kada se mogu vizualizirati na način koji pruža netrivijalan uvid u ono što se dešava u međusobno povezanim dijelovima sistema. Dok se to ne dogodi, proces otklanjanja grešaka uglavnom ostaje inertan i ovisi o sposobnosti korisnika da uoči prave korelacije, provjeri prave dijelove sistema ili sastavi dijelove slagalice - za razliku od alat, pomažući korisniku da formulira ove hipoteze.
Nisam vizualni dizajner ili stručnjak za UX, ali u sljedećem odjeljku želim podijeliti nekoliko ideja o tome kako bi ove vizualizacije mogle izgledati.
Fokusirajte se na određene usluge
U vrijeme kada se industrija konsoliduje oko ideja , čini se razumnim da pojedinačni timovi daju prioritet osiguravanju da su njihove usluge usklađene sa ovim ciljevima. Iz toga slijedi servisno orijentisan vizualizacija je najprikladnija za takve timove.
Tragovi, posebno bez uzorkovanja, su riznica informacija o svakoj komponenti distribuiranog sistema. Ove informacije se mogu predati lukavom procesoru koji će opskrbljivati korisnike servisno orijentisan Nalazi se mogu identificirati unaprijed - čak i prije nego što korisnik pogleda tragove:
- Dijagrami distribucije kašnjenja samo za vrlo istaknute zahtjeve (izuzetni zahtjevi);
- Dijagrami distribucije kašnjenja za slučajeve kada ciljevi usluge SLO nisu postignuti;
- Najčešći “uobičajeni”, “zanimljivi” i “čudni” tagovi u upitima se ponavljaju;
- Raščlamba kašnjenja za slučajeve kada zavisnosti službe ne postižu svoje SLO ciljeve;
- Raščlamba kašnjenja za različite nizvodne usluge.
Na neka od ovih pitanja jednostavno ne odgovara ugrađena metrika, što primorava korisnike da pažljivo prouče raspone. Kao rezultat toga, imamo mehanizam koji je izuzetno neprijateljski raspoložen prema korisnicima.
Ovo postavlja pitanje: šta je sa složenim interakcijama između različitih usluga koje kontrolišu različiti timovi? zar ne traceview ne smatra se najprikladnijim alatom za isticanje takve situacije?
Programeri mobilnih uređaja, vlasnici usluga bez državljanstva, vlasnici usluga kojima se upravlja stanjem (kao što su baze podataka) i vlasnici platformi mogu biti zainteresirani za nešto drugo prezentacija distribuirani sistem; traceview je previše generičko rješenje za ove fundamentalno različite potrebe. Čak iu vrlo složenoj mikroservisnoj arhitekturi, vlasnicima usluga nije potrebno duboko poznavanje više od dvije ili tri upstream i downstream usluge. U suštini, u većini scenarija, korisnici trebaju samo odgovoriti na pitanja u vezi ograničen set usluga.
To je kao da gledate mali podskup usluga kroz lupu radi pregleda. Ovo će omogućiti korisniku da postavi hitnija pitanja u vezi sa složenim interakcijama između ovih usluga i njihovih neposrednih zavisnosti. Ovo je slično traganju unazad u svijetu usluga, gdje inženjer zna da pogrešno, a takođe ima izvesno razumevanje onoga što se dešava u okolnim servisima da razume zašto.
Pristup koji promovišem je suprotan pristupu odozgo prema dolje, pristupu zasnovanom na prikazu praćenja, gdje analiza počinje s cijelim tragom, a zatim se postepeno svodi na pojedinačne raspone. Nasuprot tome, pristup odozdo prema gore počinje analizom malog područja blizu potencijalnog uzroka incidenta, a zatim proširuje prostor za pretragu po potrebi (sa potencijalom dovođenja drugih timova za analizu šireg spektra usluga). Drugi pristup je pogodniji za brzo testiranje početnih hipoteza. Kada se dobiju konkretni rezultati, biće moguće preći na fokusiraniju i detaljniju analizu.
Izgradnja topologije
Pogledi specifični za uslugu mogu biti nevjerovatno korisni ako korisnik zna šta usluga ili grupa usluga odgovorna je za povećanje kašnjenja ili izazivanje grešaka. Međutim, u složenom sistemu, identifikacija pogrešne usluge može biti netrivijalan zadatak tokom kvara, posebno ako od usluga nisu prijavljene poruke o grešci.
Izgradnja topologije usluge može biti od velike pomoći u otkrivanju koja usluga doživljava porast u stopama grešaka ili povećanje latencije koje uzrokuje primjetno degradaciju usluge. Kada govorim o izgradnji topologije, ne mislim mapa usluga, prikazujući sve usluge dostupne u sistemu i poznate po tome . Ovaj prikaz nije ništa bolji od prikaza praćenja zasnovanog na usmjerenom acikličkom grafu. Umesto toga, voleo bih da vidim dinamički generirana topologija usluge, na osnovu određenih atributa kao što su stopa greške, vrijeme odgovora ili bilo koji korisnički definirani parametar koji pomaže u razjašnjavanju situacije s određenim sumnjivim uslugama.
Uzmimo primjer. Zamislimo hipotetičku stranicu s vijestima. Usluga početne stranice (naslovna strana) razmjenjuje podatke sa Redis-om, sa servisom preporuke, sa uslugom oglašavanja i video uslugom. Video servis preuzima video zapise sa S3 i metapodatke iz DynamoDB. Usluga preporuke prima metapodatke od 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 šematski prikaz ove topologije (mnogi komercijalni programi za rutiranje grade topologiju). Može biti korisno ako trebate razumjeti ovisnosti o uslugama. Međutim, tokom otklanjanje grešaka, kada određena usluga (recimo, video usluga) pokazuje povećano vrijeme odgovora, takva topologija nije od velike koristi.
Servisni dijagram hipotetičke stranice s vijestima
Donji dijagram bi bolje odgovarao. Postoji problem sa uslugom (video) prikazan tačno u centru. Korisnik to odmah primijeti. Iz ove vizualizacije postaje jasno da video servis radi nenormalno zbog povećanja vremena odziva S3, što utiče na brzinu učitavanja dijela glavne stranice.
Dinamička topologija koja prikazuje samo "zanimljive" usluge
Dinamički generisane topologije mogu biti efikasnije od statičkih mapa usluga, posebno u elastičnim infrastrukturama s automatskim skaliranjem. Mogućnost poređenja i kontrastiranja topologija usluga omogućava korisniku da postavlja relevantnija pitanja. Preciznija pitanja o sistemu će vjerojatnije dovesti do boljeg razumijevanja kako sistem funkcionira.
Uporedni prikaz
Još jedna korisna vizualizacija bila bi uporedni prikaz. Tragovi trenutno nisu pogodni za uporedna poređenja, pa su poređenja obično rasponi. A glavna ideja ovog članka je upravo ta da su rasponi preniski da bi izvukli najvrednije informacije iz rezultata praćenja.
Poređenje dva traga ne zahtijeva fundamentalno nove vizualizacije. Zapravo, dovoljno je nešto poput histograma koji predstavlja iste informacije kao i prikaz praćenja. Iznenađujuće, čak i ova jednostavna metoda može donijeti mnogo više ploda nego jednostavno proučavanje dva traga odvojeno. Još moćnija bi bila mogućnost vizualizirati poređenje tragova Ukupno. Bilo bi izuzetno korisno vidjeti kako nedavno implementirana promjena konfiguracije baze podataka radi omogućavanja GC-a (sakupljanje smeća) utječe na vrijeme odgovora nizvodne usluge u razmjeru od nekoliko sati. Ako ovo što ovdje opisujem zvuči kao A/B analiza utjecaja promjena infrastrukture u mnogim službama koristeći rezultate praćenja, onda niste previše daleko od istine.
zaključak
Ne dovodim u pitanje korisnost samog praćenja. Iskreno vjerujem da ne postoji drugi metod za prikupljanje tako bogatih, kauzalnih i kontekstualnih podataka kao što su oni sadržani u tragu. Međutim, također vjerujem da sva rješenja za praćenje koriste ove podatke krajnje neefikasno. Sve dok alati za praćenje ostaju zaglavljeni u prikazu praćenja, biće ograničeni u svojoj sposobnosti da maksimalno iskoriste vrijedne informacije koje se mogu izdvojiti iz podataka sadržanih u praćenju. Osim toga, postoji rizik od daljnjeg razvoja potpuno neprijateljskog i neintuitivnog vizualnog interfejsa koji će ozbiljno ograničiti mogućnost korisnika da otkloni greške u aplikaciji.
Otklanjanje grešaka u složenim sistemima, čak i sa najnovijim alatima, je neverovatno teško. Alati bi trebali pomoći programeru da formulira i testira hipotezu, aktivno pružanje relevantne informacije, identifikujući izuzetke i uočavajući karakteristike u distribuciji kašnjenja. Da bi praćenje postalo alat izbora za programere prilikom rješavanja problema u proizvodnji ili rješavanja problema koji se protežu na više usluga, potrebna su originalna korisnička sučelja i vizualizacije koje su u skladu s mentalnim modelom programera koji kreiraju i upravljaju tim uslugama.
Biće potreban značajan mentalni napor da se dizajnira sistem koji će predstavljati različite signale dostupne u rezultatima praćenja na način koji je optimizovan za lakoću analize i zaključivanja. Morate razmisliti o tome kako apstrahovati topologiju sistema tokom otklanjanja grešaka na način koji pomaže korisniku da prevlada mrtve tačke bez gledanja pojedinačnih tragova ili raspona.
Potrebne su nam dobre mogućnosti apstrakcije i slojevitosti (posebno u korisničkom sučelju). One koje bi se dobro uklopile u proces otklanjanja grešaka vođen hipotezama gdje možete iterativno postavljati pitanja i testirati hipoteze. 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 realna perspektiva za proširenje vidika.
PS od prevodioca
Pročitajte i na našem blogu:
- «»;
- «»;
- «".
izvor: www.habr.com