Cathetan. nerjemahake.: Penulis materi iki yaiku Cindy Sridharan, insinyur ing imgix sing duwe spesialisasi ing pangembangan API lan, utamane, pengujian layanan mikro. Ing materi iki, dheweke nuduhake visi rinci babagan masalah saiki ing bidang tracing sing disebarake, ing ngendi, miturut dheweke, ana kekurangan alat sing efektif kanggo ngrampungake masalah sing ditekan.
[Ilustrasi dijupuk saka babagan tracing sing disebarake.]
Iki dipercaya manawa angel kanggo ngleksanakake, lan bali ing . Ana akeh alasan ngapa nelusuri masalah, asring nyebutake tenaga kerja sing melu ngatur saben komponen sistem kanggo ngirim header sing cocog karo saben panyuwunan. Sanajan masalah iki ana, nanging ora bisa diatasi. Miturut cara, ora nerangake kenapa pangembang ora seneng nglacak (sanajan wis bisa digunakake).
Tantangan utama karo tracing sing disebarake yaiku ora ngumpulake data, nggawe standarisasi format kanggo nyebarake lan nampilake asil, utawa nemtokake kapan, ing endi, lan carane nggawe sampel. Aku ora nyoba mbayangno sepele "Masalah pemahaman" iki, nyatane, teknis sing cukup signifikan lan (yen kita nganggep sejatine Open Source) ) tantangan politik sing kudu diatasi supaya masalah kasebut bisa dianggep rampung.
Nanging, yen kita mbayangno yen kabeh masalah iki wis ditanggulangi, ana kemungkinan gedhe yen ora ana owah-owahan sing signifikan babagan pengalaman pangguna pungkasan. Nelusuri isih ora bisa digunakake kanthi praktis ing skenario debugging sing paling umum-sanajan wis dipasang.
Tilak sing beda
Tracing sing disebarake kalebu sawetara komponen sing beda:
- nglengkapi aplikasi lan middleware kanthi alat kontrol;
- transfer konteks sing disebarake;
- koleksi jejak;
- panyimpenan tilak;
- extraction lan visualisasi sing.
Akeh pirembagan babagan tracing sing disebarake cenderung nganggep minangka operasi unary sing tujuane mung kanggo mbantu diagnosa sistem kanthi lengkap. Iki umume amarga kepiye ide babagan tracing sing disebarake kanthi historis. ING , digawe nalika sumber Zipkin dibukak, iki kasebut iku [Zipkin] ndadekake Twitter luwih cepet. Penawaran komersial pisanan kanggo nelusuri uga disedhiyakake minangka .
Cathetan. nerjemahake.: Kanggo nggawe teks luwih gampang dingerteni, ayo padha nemtokake rong istilah dhasar miturut :
- span - unsur dhasar saka tracing disebarake. Iki minangka katrangan babagan alur kerja tartamtu (contone, query database) kanthi jeneng, wektu wiwitan lan pungkasan, tag, log lan konteks.
- Spans biasane ngemot pranala menyang span liyane, ngidini sawetara span bisa digabungake Nglacak - visualisasi urip panyuwunan nalika pindhah liwat sistem sing disebarake.
Jejak ngemot data sing luar biasa sing bisa mbantu tugas kayata tes produksi, tes pemulihan bencana, tes injeksi kesalahan, lsp. Nyatane, sawetara perusahaan wis nggunakake tracing kanggo tujuan sing padha. Ayo dadi miwiti karo nduweni kegunaan liyane kajaba mung mindhah rentang menyang sistem panyimpenan:
- Contone, Uber asil nelusuri kanggo mbedakake antarane lalu lintas test lan lalu lintas produksi.
- Facebook data tilak kanggo analisis path kritis lan kanggo ngoper lalu lintas sak tes Recovery bilai biasa.
- Uga jaringan sosial Notebook Jupyter sing ngidini pangembang mbukak pitakon sewenang-wenang babagan asil tilak.
- Penganut (Lineage Driven Failure Injection) tilak mbagekke kanggo testing karo injeksi kesalahan.
Ora ana pilihan sing kadhaptar ing ndhuwur ditrapake kanggo skenario debug, sajrone insinyur nyoba ngatasi masalah kasebut kanthi ndeleng jejak kasebut.
Nalika teka durung tekan skrip debugging, antarmuka utama tetep diagram traceview (sanajan sawetara uga nyebutake "Gantt chart" utawa "diagram air terjun"). Ing traceview я kabeh jengkal lan metadata sing bebarengan nggawe tilak. Saben sistem tracing open source, uga saben solusi nelusuri komersial, nawakake a traceview antarmuka panganggo kanggo visualizing, rinci lan nyaring ngambah.
Masalah karo kabeh sistem nelusuri aku wis katon supaya adoh iku asil visualisasi (traceview) meh rampung nggambarake fitur saka proses generasi tilak. Sanajan visualisasi alternatif diusulake: peta panas, topologi layanan, histogram latensi, pungkasane isih mudhun menyang traceview.
Ing jaman biyen aku sing paling UI / UX nelusuri "inovasi" koyone diwatesi kanggo metadata tambahan ing tilak, nandur modal ing wong informasi karo cardinality dhuwur (kardinalitas dhuwur) utawa nyediakake kemampuan kanggo ngebor mudhun menyang span tartamtu utawa mbukak pitakon inter- lan intra-trace... Ing endi traceview tetep alat visualisasi utama. Anggere kahanan iki terus, mbagekke nelusuri bakal (paling apik) njupuk Panggonan 4th minangka alat debugging, sawise metrik, log lan tumpukan tilak, lan paling awon bakal dadi sampah dhuwit lan wektu.
Masalah karo traceview
Tujuan traceview - nyedhiyakake gambaran lengkap babagan gerakan panyuwunan siji ing kabeh komponen sistem sing disebarake sing ana gandhengane. Sawetara sistem tracing sing luwih maju ngidini sampeyan ngebor menyang rentang individu lan ndeleng risak saka wektu ing njero siji proses (nalika span duwe wates fungsional).
Premis dhasar arsitektur microservices yaiku ide manawa struktur organisasi tuwuh kanthi kabutuhan perusahaan. Panyengkuyung microservices mbantah manawa nyebarake macem-macem tugas bisnis menyang layanan individu ngidini tim pangembangan otonom cilik ngontrol kabeh siklus urip layanan kasebut, menehi kemampuan kanggo mbangun, nguji, lan nyebarake layanan kasebut kanthi mandiri. Nanging, kerugian distribusi iki yaiku kelangan informasi babagan carane saben layanan sesambungan karo wong liya. Ing kahanan kaya mengkono, mbagekke nelusuri claims dadi alat indispensable kanggo debug interaksi Komplek antarane layanan.
Yen pancene , banjur ora ana wong siji-sijia sing bisa nyimpen ing sirahe lengkap gambar. Nyatane, ngembangake alat adhedhasar asumsi yen bisa uga ana sing anti-pola (pendekatan sing ora efektif lan ora produktif). Saenipun, debugging mbutuhake alat sing mbantu sempit area telusuran sampeyan, supaya insinyur bisa fokus ing subset saka dimensi (layanan / pangguna / host, etc.) sing cocog karo skenario masalah sing dianggep. Nalika nemtokake sabab saka Gagal, engineers ora dibutuhake kanggo ngerti apa kedaden sak kabeh layanan bebarengan, amarga syarat kasebut bakal mbantah ide arsitektur layanan mikro.
Nanging, traceview iku yaiku Iki. Ya, sawetara sistem nelusuri nawakake traceviews sing dikompres nalika jumlah jengkal ing jejak kasebut akeh banget, mula ora bisa ditampilake ing siji visualisasi. Nanging, amarga akeh informasi sing ana sanajan ing visualisasi sing diudani, para insinyur isih dipeksa "sift", kanthi manual narrowing pilihan kanggo pesawat saka layanan sing sumber masalah. Sayange, ing lapangan iki, mesin luwih cepet tinimbang manungsa, kurang rentan kanggo kasalahan, lan asil luwih bisa diulang.
Alesan liyane sing dakanggep traceview salah amarga ora apik kanggo debugging sing didorong hipotesis. Ing inti, debugging punika iteratif proses diwiwiti karo hipotesis, ngiring dening verifikasi saka macem-macem pengamatan lan kasunyatan dijupuk saka sistem bebarengan vektor beda, kesimpulan / generalizations lan Assessment luwih saka bebener hipotesis.
Opportunity cepet lan murah nguji hipotesis lan ningkatake model mental sing cocog yaiku watu pojok debugging Sembarang alat debugging kudu gawe gathuk ing rembugan lan sempit ruang telusuran utawa, yen ana timbal palsu, ngidini pangguna bali lan fokus ing area sistem sing beda. Alat sing sampurna bakal nindakake iki kanthi proaktif, langsung narik kawigaten pangguna menyang area masalah potensial.
Adhuh, traceview ora bisa disebut alat karo antarmuka interaktif. Sing paling apik sing bisa sampeyan ngarep-arep nalika nggunakake yaiku golek sawetara sumber tambah latensi lan deleng kabeh tag lan log sing ana gandhengane. Iki ora mbantu insinyur kanggo ngenali pola-pola ing lalu lintas, kayata spesifik distribusi wektu tundha, utawa ndeteksi korélasi antarane pangukuran sing beda. bisa mbantu ngatasi sawetara masalah kasebut. tenan, analisis sukses nggunakake machine learning kanggo ngenali span anomali lan ngenali subset saka tags sing bisa digandhengake karo prilaku anomali. Nanging, aku durung bisa ndeleng visualisasi pembelajaran mesin utawa temuan data mining sing ditrapake kanggo span sing beda banget karo traceview utawa DAG (grafik asiklik terarah).
Spans tingkat banget kurang
Masalah dhasar karo traceview yaiku mbentang minangka primitif tingkat rendah banget kanggo analisis latensi lan analisis sabab akar. Iku kaya parsing printah prosesor individu kanggo nyoba kanggo mutusake masalah pangecualian, ngerti sing ana akeh piranti tingkat sing luwih dhuwur kaya backtrace sing luwih trep kanggo nggarap.
Kajaba iku, aku bakal njupuk kamardikan kanggo nyatakake ing ngisor iki: saenipun, kita ora perlu gambar lengkap kedadeyan sajrone siklus urip panyuwunan, sing diwakili dening alat tracing modern. Nanging, sawetara wangun abstraksi tingkat sing luwih dhuwur dibutuhake sing ngemot informasi babagan apa tindak salah (padha karo backtrace), bebarengan karo sawetara konteks. Tinimbang nonton kabeh jejak, aku luwih seneng ndeleng bagean saka, ing ngendi ana kedadeyan sing menarik utawa ora biasa. Saiki, telusuran ditindakake kanthi manual: insinyur nampa jejak lan kanthi mandiri nganalisa rentang kanggo nggoleki sing menarik. Pendekatan wong sing ndeleng span ing jejak individu kanthi pangarep-arep bisa ndeteksi aktivitas sing curiga ora ukurane (utamane yen kudu ngerteni kabeh metadata sing dikodekan ing rentang sing beda-beda, kayata span ID, jeneng metode RPC, durasi span). 'a, log, tag, lsp).
Alternatif kanggo traceview
Asil trace paling migunani nalika bisa digambarake kanthi cara sing menehi wawasan sing ora pati penting babagan apa sing kedadeyan ing bagean sistem sing gegandhengan. Nganti kedadeyan kasebut, proses debugging isih tetep inert lan gumantung ing kemampuan pangguna kanggo nggatekake korélasi sing bener, mriksa bagean sistem sing bener, utawa nggabungake potongan-potongan teka-teki kasebut - minangka lawan saka instrumen, mbantu pangguna ngrumusake hipotesis kasebut.
Aku dudu desainer visual utawa spesialis UX, nanging ing bagean sabanjure aku pengin nuduhake sawetara ide babagan visualisasi kasebut.
Fokus ing layanan tartamtu
Ing wektu nalika industri wis consolidating watara gagasan , misale jek wajar yen tim individu kudu menehi prioritas kanggo mesthekake layanan kasebut selaras karo tujuan kasebut. Iku nderek sing layanan oriented visualisasi paling cocog kanggo tim kasebut.
Jejak, utamane tanpa sampling, minangka bandha informasi babagan saben komponen sistem sing disebarake. Informasi iki bisa diwenehake menyang prosesor licik sing bakal nyedhiyakake pangguna layanan oriented Temuan kasebut bisa diidentifikasi luwih dhisik - sanajan sadurunge pangguna ndeleng jejak kasebut:
- Diagram distribusi latensi mung kanggo panjaluk sing penting banget (panyuwunan luar biasa);
- Diagram distribusi wektu tundha kanggo kasus nalika tujuan SLO layanan ora digayuh;
- Tag sing paling "umum", "menarik" lan "aneh" ing pitakon sing paling kerep sing bola-bali;
- Latency risak kanggo kasus ngendi ketergantungan layanan ora entuk gol SLO;
- Rincian latensi kanggo macem-macem layanan hilir.
Sawetara pitakonan kasebut mung ora dijawab dening metrik sing dibangun, meksa pangguna kanggo nliti span. Akibaté, kita duwe mekanisme banget musuhan pangguna.
Iki nuwuhake pitakon: kepiye interaksi kompleks antarane macem-macem layanan sing dikontrol dening tim sing beda-beda? Apa ora traceview ora dianggep minangka alat sing paling cocok kanggo nyorot kahanan kaya ngono?
Pangembang seluler, pamilik layanan tanpa kewarganegaraan, pamilik layanan stateful sing dikelola (kaya database) lan pamilik platform bisa uga kasengsem ing liya. presentasi sistem distribusi; traceview solusi umum banget kanggo kabutuhan dhasar beda. Malah ing arsitektur microservice sing rumit banget, pamilik layanan ora mbutuhake kawruh jero babagan luwih saka loro utawa telung layanan hulu lan hilir. Ateges, ing umume skenario, pangguna mung kudu mangsuli pitakon babagan pesawat winates saka layanan.
Kayane ndeleng subset layanan cilik liwat kaca pembesar kanggo nliti. Iki bakal ngidini pangguna takon pitakonan sing luwih penting babagan interaksi kompleks antarane layanan kasebut lan dependensi langsung. Iki padha karo backtrace ing donya layanan, ing ngendi insinyur ngerti sing salah, lan uga wis sawetara pangerten apa mengkono ing layanan lingkungan mangertos ngapa.
Pendekatan sing dak promosiake yaiku kebalikan saka pendekatan adhedhasar traceview ndhuwur-mudhun, ing ngendi analisis kasebut diwiwiti kanthi kabeh jejak lan banjur mboko sithik mudhun menyang rentang individu. Ing kontras, pendekatan ngisor-up diwiwiti kanthi nganalisa area cilik sing cedhak karo panyebab potensial kedadeyan kasebut, lan banjur nggedhekake ruang telusuran kaya sing dibutuhake (kanthi potensial nggawa tim liyane kanggo nganalisa luwih akeh layanan). Pendekatan kapindho luwih cocog kanggo nguji hipotesis awal kanthi cepet. Sawise asil konkrit dipikolehi, bakal bisa nerusake menyang analisis sing luwih diangkah lan rinci.
Nggawe topologi
Tampilan khusus layanan bisa migunani banget yen pangguna ngerti apa layanan utawa klompok layanan tanggung jawab kanggo nambah latensi utawa nyebabake kesalahan. Nanging, ing sistem sing rumit, ngenali layanan sing nyinggung bisa dadi tugas sing ora pati penting nalika gagal, utamane yen ora ana pesen kesalahan sing dilaporake saka layanan kasebut.
Nggawe topologi layanan bisa dadi bantuan gedhe kanggo ngerteni layanan endi sing ngalami lonjakan tingkat kesalahan utawa paningkatan latensi sing nyebabake layanan kasebut rusak banget. Nalika aku ngomong babagan mbangun topologi, aku ora ateges peta layanan, nampilake saben layanan sing kasedhiya ing sistem lan dikenal kanggo sawijining . Tampilan iki ora luwih apik tinimbang traceview adhedhasar grafik asiklik sing diarahake. Nanging aku pengin ndeleng topologi layanan sing digawe kanthi dinamis, adhedhasar atribut tartamtu kayata tingkat kesalahan, wektu nanggepi, utawa parameter sing ditemtokake pangguna sing mbantu njlentrehake kahanan kasebut kanthi layanan curiga tartamtu.
Ayo dadi conto. Ayo mbayangno situs berita hipotetis. Layanan kaca ngarep (kaca ngarep) ijol-ijolan data karo Redis, karo layanan rekomendasi, karo layanan iklan lan layanan video. Layanan video njupuk video saka S3 lan metadata saka DynamoDB. Layanan rekomendasi nampa metadata saka DynamoDB, ngemot data saka Redis lan MySQL, lan nulis pesen menyang Kafka. Layanan iklan nampa data saka MySQL lan nulis pesen menyang Kafka.
Ing ngisor iki minangka representasi skematik saka topologi iki (akeh program routing komersial mbangun topologi). Bisa migunani yen sampeyan kudu ngerti dependensi layanan. Nanging, sak debug, nalika layanan tartamtu (ngomong, layanan video) nuduhake wektu respon tambah, topologi kuwi ora banget migunani.
Diagram layanan situs warta hipotetis
Diagram ing ngisor iki bakal luwih cocog. Ana masalah karo layanan (video) digambarake ing tengah. Pangguna sok dong mirsani. Saka visualisasi iki, dadi cetha yen layanan video ora normal amarga nambah wektu respon S3, sing mengaruhi kacepetan loading bagean kaca utama.
Topologi dinamis mung nampilake layanan "menarik".
Topologi sing digawe kanthi dinamis bisa luwih efisien tinimbang peta layanan statis, utamane ing infrastruktur skala otomatis sing elastis. Kemampuan kanggo mbandhingake lan kontras topologi layanan ngidini pangguna takon pitakonan sing luwih relevan. Pitakonan sing luwih tepat babagan sistem kasebut luwih bisa nyebabake pemahaman sing luwih apik babagan cara kerja sistem kasebut.
Tampilan komparatif
Visualisasi liyane sing migunani bakal dadi tampilan komparatif. Saiki jejak ora cocog banget kanggo mbandhingake sisih, mula biasane mbandhingake mbentang. Lan gagasan utama artikel iki yaiku yen rentang banget tingkat kurang kanggo ngekstrak informasi sing paling berharga saka asil tilak.
Mbandhingake rong jejak ora mbutuhake visualisasi dhasar anyar. Nyatane, kaya histogram sing nuduhake informasi sing padha karo traceview cukup. Sing nggumunake, sanajan cara sing gampang iki bisa ngasilake luwih akeh tinimbang mung sinau rong jejak kanthi kapisah. Malah luwih kuat bakal kamungkinan nggambarake mbandhingake jejak Gunggunge. Iku bakal migunani banget kanggo ndeleng carane owah-owahan konfigurasi database bubar disebaraké kanggo ngaktifake GC (koleksi sampah) mengaruhi wektu respon saka layanan hilir ing ukuran sawetara jam. Yen apa sing dakgambarake ing kene kaya ana analisis A/B babagan pengaruh owah-owahan infrastruktur ing akeh layanan nggunakake asil tilak, banjur sampeyan ora adoh banget saka bebener.
kesimpulan
Aku ora takon bab migunani saka tracing dhewe. Aku kanthi tulus percaya yen ora ana cara liya kanggo ngumpulake data sing sugih, sebab lan kontekstual kaya sing ana ing tilak. Nanging, aku uga percaya yen kabeh solusi nelusuri nggunakake data iki kanthi ora efisien. Anggere alat nelusuri tetep macet ing perwakilan traceview, padha bakal diwatesi ing kemampuan kanggo ngoptimalake informasi terkenal sing bisa dijupuk saka data sing ana ing tilak. Kajaba iku, ana risiko ngembangake antarmuka visual sing ora ramah lan ora intuisi sing bakal mbatesi kemampuan pangguna kanggo ngatasi kesalahan ing aplikasi kasebut.
Debugging sistem Komplek, malah karo alat paling anyar, iku luar biasa angel. Piranti kudu mbantu pangembang ngrumusake lan nguji hipotesis, aktif nyediakake informasi sing cocog, ngenali outlier lan nyathet fitur ing distribusi telat. Kanggo nelusuri dadi alat pilihan kanggo pangembang nalika ngatasi masalah kegagalan produksi utawa ngrampungake masalah sing kalebu macem-macem layanan, antarmuka pangguna asli lan visualisasi dibutuhake sing luwih konsisten karo model mental para pangembang sing nggawe lan ngoperasikake layanan kasebut.
Perlu gaweyan mental sing signifikan kanggo ngrancang sistem sing bakal makili macem-macem sinyal sing kasedhiya ing asil tilak kanthi cara sing dioptimalake supaya gampang dianalisis lan inferensi. Sampeyan kudu mikir babagan carane abstrak topologi sistem sajrone debugging kanthi cara sing mbantu pangguna ngatasi titik wuta tanpa ndeleng jejak utawa rentang individu.
Kita butuh kemampuan abstraksi lan layering sing apik (utamane ing UI). Siji-sijine sing cocog karo proses debugging sing didorong hipotesis ing ngendi sampeyan bisa terus takon lan nguji hipotesis. Dheweke ora bakal ngrampungake kabeh masalah observasi kanthi otomatis, nanging bakal mbantu pangguna ngasah intuisi lan ngrumusake pitakonan sing luwih cerdas. Aku njaluk pendekatan sing luwih wicaksana lan inovatif kanggo visualisasi. Ana prospek nyata ing kene kanggo nggedhekake cakrawala.
PS saka penerjemah
Waca uga ing blog kita:
- «";
- «";
- «".
Source: www.habr.com