Catetan. narjamahkeun.: Panulis bahan ieu Cindy Sridharan, insinyur di imgix anu specializes dina ngembangkeun API sarta, hususna, nguji microservice. Dina bahan ieu, manehna babagi visi detil na masalah ayeuna dina widang tracing disebarkeun, dimana, dina pamadegan dirina, aya kurangna parabot sabenerna éféktif pikeun ngarengsekeun masalah mencet.
[Ilustrasi dicokot tina ngeunaan tracing anu disebarkeun.]
Hal ieu dipercaya éta hese dilaksanakeun, sarta balik deui ka dinya . Aya loba alesan naha tracing aya masalah, mindeng citing kuli aub dina ngonpigurasikeun unggal komponén sistem pikeun ngirimkeun headers luyu jeung unggal pamundut. Sanaos masalah ieu aya, éta sanés hartosna teu tiasa diatasi. Ku jalan kitu, éta henteu ngajelaskeun naha pamekar henteu resep ngalacak (sanaos éta parantos dianggo).
Tangtangan utama pikeun ngalacak anu disebarkeun nyaéta henteu ngumpulkeun data, ngabakukeun format pikeun nyebarkeun sareng nampilkeun hasil, atanapi nangtoskeun iraha, dimana, sareng kumaha conto. Abdi henteu nyobian ngabayangkeun sepele ieu "masalah pamahaman" téh, kanyataanna, rada signifikan teknis na (lamun urang tempo sabenerna Open Source) ) tangtangan politik anu kudu diungkulan sangkan masalah-masalah ieu dianggap bisa direngsekeun.
Nanging, upami urang ngabayangkeun yén sadaya masalah ieu direngsekeun, aya kamungkinan luhur yén teu aya anu bakal robih sacara signifikan dina hal pangalaman pamaké tungtung. Nyukcruk masih henteu tiasa dianggo sacara praktis dina skénario debugging anu paling umum-sanaos saatos dipasang.
Sapertos jejak anu béda
Tracing anu disebarkeun kalebet sababaraha komponén anu béda:
- equipping aplikasi tur middleware kalawan parabot kontrol;
- mindahkeun konteks disebarkeun;
- kumpulan ngambah;
- neundeun jejak;
- ékstraksi jeung visualisasi maranéhanana.
Seueur omongan ngeunaan tracing anu disebarkeun condong ngarawat éta salaku jinis operasi unary anu tujuanna tunggal pikeun ngabantosan diagnosis sistem. Ieu umumna kusabab kumaha ideu ngeunaan tracing anu disebarkeun sacara sajarahna kabentuk. DI , Dijieun nalika sumber Zipkin dibuka, ieu disebutkeun yen eta [Zipkin] ngajadikeun Twitter gancang. The kurban komérsial munggaran pikeun tracing ogé diwanohkeun salaku .
Catetan. narjamahkeun.: Pikeun nyieun téks salajengna gampang ngartos, hayu urang nangtukeun dua istilah dasar nurutkeun :
- bentang - unsur dasar tracing disebarkeun. Éta mangrupikeun pedaran ngeunaan alur kerja anu tangtu (contona, pamundut database) kalayan nami, waktos ngamimitian sareng akhir, tag, log sareng kontéks.
- Rentang ilaharna ngandung tumbu ka bentang séjén, sahingga sababaraha bentang bisa digabungkeun kana renik - visualisasi kahirupan hiji pamundut sakumaha ngalir ngaliwatan sistem disebarkeun.
Lacak ngandung data anu luar biasa berharga anu tiasa ngabantosan tugas sapertos uji produksi, uji pamulihan bencana, uji suntikan kasalahan, jsb. Nyatana, sababaraha perusahaan parantos nganggo ngalacak pikeun tujuan anu sami. Hayu urang mimitian ku gaduh kagunaan séjén salian ngan saukur mindahkeun bentang ka sistem panyimpenan:
- Contona, Uber ngalacak hasil pikeun ngabédakeun antara lalu lintas tés sareng lalu lintas produksi.
- Facebook data renik pikeun analisis jalur kritis jeung switching lalulintas salila tés recovery musibah biasa.
- Ogé jaringan sosial notebooks Jupyter nu ngidinan pamekar pikeun ngajalankeun queries sawenang on hasil renik.
- panganut (Suntikan Kegagalan Didorong Lineage) ngambah disebarkeun pikeun nguji jeung suntik kasalahan.
Euweuh sahiji pilihan nu didaptarkeun di luhur dilarapkeun sagemblengna ka skenario debug, salila insinyur nyobian pikeun ngajawab masalah ku nempo renik.
Lamun datang acan ngahontal skrip debugging, panganteur primér tetep diagram traceview (sanajan sababaraha ogé nyebutna "Bagan Gantt" atawa "diagram curug"). Sahandapeun traceview я sadaya bentang sareng metadata anu disarengan anu ngahijikeun ngalacak. Unggal sistem tracing open source, kitu ogé unggal solusi tracing komérsial, nawarkeun hiji traceview panganteur pamaké pikeun visualizing, detailing jeung nyaring ngambah.
Masalah sareng sadaya sistem ngalacak anu kuring parantos ningali ayeuna nyaéta hasilna visualisasi (traceview) ampir sakabéhna ngagambarkeun fitur tina prosés generasi renik. Sanaos visualisasi alternatif diajukeun: peta panas, topologi jasa, histogram latensi, aranjeunna tetep dugi ka traceview.
Baheula mah yén paling "inovasi" dina UI / UX tracing sigana dugi ka metadata tambahan dina renik, investasi di aranjeunna informasi kalawan cardinality tinggi (kardinalitas luhur) atawa nyadiakeun kamampuhan pikeun bor handap kana bentang husus atawa ngajalankeun queries inter- jeung intra-trace... Dimana traceview tetep alat visualisasi primér. Salami kaayaan ieu terus, tracing disebarkeun bakal (paling pangalusna) tempat 4 salaku alat debugging, sanggeus metrics, log jeung ngambah tumpukan, sarta di awon eta bakal tétéla jadi runtah duit jeung waktu.
Masalah sareng traceview
takdir traceview - nyadiakeun gambaran lengkep ngeunaan gerakan hiji pamundut tunggal sakuliah sakabéh komponén sistem disebarkeun nu patali. Sababaraha sistem ngalacak anu langkung maju ngamungkinkeun anjeun pikeun ngebor kana bentang individu sareng ningali ngarecahna kana waktosna di jero hiji prosés (lamun bentang boga wates fungsi).
Premis dasar arsitéktur microservices nyaéta ideu yén struktur organisasi tumbuh sareng kabutuhan perusahaan. Proponents of microservices ngajawab yén ngadistribusikaeun rupa tugas bisnis kana jasa individu ngamungkinkeun leutik, tim ngembangkeun otonom ngadalikeun sakabéh lifecycle jasa misalna, mere aranjeunna kamampuhan pikeun mandiri ngawangun, nguji, sarta nyebarkeun jasa maranéhanana. Tapi, kalemahan distribusi ieu nyaéta leungitna inpormasi ngeunaan kumaha unggal jasa berinteraksi sareng anu sanés. Dina kaayaan kitu, disebarkeun tracing klaim janten alat indispensable pikeun debug interaksi kompléks antara jasa.
Lamun bener , mangka moal aya hiji jalma anu bisa nyimpen eta dina sirah na lengkep gambar. Kanyataanna, ngamekarkeun alat dumasar kana asumsi yén éta malah mungkin mangrupa hal tina pola anti (pendekatan teu éféktif jeung unproductive). Ideally, debugging merlukeun alat nu mantuan sempit wewengkon pilarian Anjeun, ku kituna insinyur bisa difokuskeun sawaréh dimensi (jasa / pamaké / host, jsb) relevan jeung skenario masalah keur dianggap. Nalika nangtoskeun panyabab gagalna, insinyur henteu kedah ngartos naon anu kajantenan salami sadaya jasa sakaligus, Kusabab sarat sapertos kitu bakal ngabantah pisan ideu arsitéktur microservice.
Sanajan kitu, traceview nyaeta nyaéta Ieu. Leres, sababaraha sistem nyukcruk nawiskeun traceviews anu dikomprés nalika jumlah bentang dina ngambah ageung pisan sahingga henteu tiasa ditampilkeun dina hiji visualisasi. Sanajan kitu, alatan jumlah badag informasi ngandung malah dina visualisasi dilucuti-handap sapertos, insinyur masih kapaksa "Ayak" éta, sacara manual ngahususkeun pilihan kana sakumpulan jasa anu sumber masalah. Hanjakalna, dina widang ieu, mesin langkung gancang tibatan manusa, kirang rawan kasalahan, sareng hasilna langkung tiasa diulang.
Alesan sejen Jigana traceview salah sabab teu alus pikeun debugging hypothesis-disetir. Dina inti na, debugging nyaeta iteratif prosés dimimitian ku hipotesa, dituturkeun ku verifikasi rupa observasi jeung fakta dicandak tina sistem sapanjang vektor béda, conclusions / generalizations sarta assessment salajengna ngeunaan bebeneran hipotesa.
kasempetan gancang jeung murah nguji hipotésis jeung ngaronjatkeun modél mental sasuai téh batu penjuru debugging Sagala alat debugging kedah interaktif sareng ngahususkeun rohangan panéangan atanapi, upami aya kalungguhan palsu, ngantepkeun pangguna uih deui sareng museurkeun kana daérah sistem anu béda. Alat anu sampurna bakal ngalakukeun ieu sacara proaktif, geuwat narik perhatian pamaké ka wewengkon masalah poténsial.
Aduh, traceview teu bisa disebut alat jeung panganteur interaktif. Anu pangsaéna anu anjeun ngarepkeun nalika nganggo éta nyaéta milarian sababaraha sumber paningkatan latency sareng ningali sadaya tag anu mungkin sareng log anu aya hubunganana. Ieu henteu ngabantosan insinyur pikeun ngaidentipikasi pola-pola dina patalimarga, sapertos spésifik distribusi reureuh, atanapi ngadeteksi korelasi antara ukuran anu béda. tiasa ngabantosan sababaraha masalah ieu. Nyaan, analisis suksés ngagunakeun learning mesin pikeun ngaidentipikasi bentang anomali sarta ngaidentipikasi sawaréh tina tag nu bisa jadi pakait jeung kabiasaan anomali. Najan kitu, kuring can ningali visualizations compelling learning mesin atawa data pertambangan papanggihan dilarapkeun ka bentang anu béda sacara signifikan ti traceview atawa DAG (diarahkeun grafik asiklik).
Spans tingkat teuing low
Masalah dasar sareng traceview éta bentang Éta primitif tingkat rendah teuing pikeun analisis latency sareng analisis akar sabab. Éta sapertos parsing paréntah prosésor individu pikeun nyobian ngabéréskeun pengecualian, terang yén aya alat tingkat anu langkung luhur sapertos backtrace anu langkung gampang dianggo.
Sumawona, kuring bakal nyandak kabébasan pikeun negeskeun ieu: idéal, urang henteu peryogi gambar pinuh lumangsung salila siklus hirup pamundut, nu digambarkeun ku parabot tracing modern. Gantina, sababaraha bentuk abstraksi tingkat luhur diperlukeun nu ngandung émbaran ngeunaan naon lepat (sarupa jeung backtrace), babarengan jeung sababaraha konteks. Tinimbang ningali sakabeh jejak, kuring leuwih resep ningali eta bagian tina, dimana hal metot atawa mahiwal kajadian. Ayeuna, panéangan dilaksanakeun sacara manual: insinyur nampi jejak sareng sacara mandiri nganalisa bentang pikeun milarian anu pikaresepeun. Pendekatan jalma-jalma neuteup bentang dina ngambah individu dina harepan pikeun ngadeteksi kagiatan anu curiga henteu skala pisan (utamana nalika aranjeunna kedah ngartos sadaya metadata anu disandikeun dina bentang anu béda, sapertos span ID, nami metode RPC, durasi bentang. 'a, log, tag, jsb).
Alternatif pikeun traceview
Hasil renik paling mangpaat nalika aranjeunna tiasa ditingali ku cara anu masihan wawasan anu teu penting kana naon anu lumangsung dina bagian sistem anu saling nyambungkeun. Dugi ka ieu kajadian, prosés debugging sakitu legana tetep inert sarta gumantung kana kamampuh pamaké pikeun perhatikeun korelasi katuhu, pariksa bagian katuhu tina sistem, atawa nempatkeun potongan teka babarengan - sabalikna Instrumén, mantuan pamaké ngarumuskeun hipotesis ieu.
Abdi sanes desainer visual atanapi spesialis UX, tapi dina bagian salajengna Abdi hoyong bagikeun sababaraha gagasan ngeunaan naon visualizations ieu bisa kasampak kawas.
Difokuskeun jasa husus
Dina waktu nalika industri ieu consolidating sabudeureun gagasan , Sigana lumrah yén tim individu kedah prioritas mastikeun jasa maranéhanana anu Blok kalawan tujuan ieu. Ieu nuturkeun éta berorientasi jasa visualisasi paling cocog pikeun tim sapertos kitu.
Ngambah, utamana tanpa sampling, mangrupakeun trove harta inpormasi ngeunaan unggal komponén sistem disebarkeun. Inpormasi ieu tiasa disayogikeun ka prosesor licik anu bakal nyayogikeun pangguna berorientasi jasa Éta tiasa diidentifikasi sateuacanna - bahkan sateuacan pangguna ningali jejak:
- Diagram distribusi latency ngan pikeun paménta anu kacida menonjol (paménta luar biasa);
- Diagram distribusi reureuh pikeun kasus nalika tujuan SLO jasa henteu kahontal;
- Tag anu paling "umum", "menarik" sareng "aneh" dina patarosan anu paling sering anu diulang;
- Latency ngarecahna pikeun kasus dimana gumantung jasa teu ngahontal tujuan SLO maranéhna;
- Ngarecahna latency pikeun sagala rupa layanan hilir.
Sababaraha patarosan ieu ngan saukur teu diwaler ku métrik diwangun-di, forcing pamaké pikeun scrutinize bentang. Hasilna, urang boga mékanisme pisan-musuhan pamaké.
Ieu raises patarosan: kumaha upami interaksi kompléks antara rupa-rupa layanan dikawasa ku tim béda? Nya henteu traceview henteu dianggap alat anu paling pas pikeun nyorot kaayaan sapertos kitu?
Pamekar mobile, nu boga jasa stateless, nu boga jasa stateful junun (sapertos database) jeung nu boga platform bisa jadi kabetot dina hal sejenna. presentasi sistem disebarkeun; traceview Ieu teuing generik solusi pikeun kaperluan ieu fundamentally béda. Malah dina arsitéktur microservice pisan kompléks, boga jasa teu merlukeun pangaweruh jero leuwih ti dua atawa tilu jasa hulu jeung hilir. Intina, dina kalolobaan skenario, pangguna ngan ukur kedah ngajawab patarosan ngeunaan set kawates jasa.
Éta sapertos ningali sawaréh leutik jasa ngalangkungan kaca pembesar pikeun ngariksa éta. Ieu bakal ngamungkinkeun pamaké pikeun naroskeun patarosan anu langkung mendesak ngeunaan interaksi kompleks antara jasa ieu sareng katergantungan langsungna. Ieu sami sareng backtrace di dunya jasa, dimana insinyur terang yen salah, sarta ogé mibanda sababaraha pamahaman naon anu lumangsung dina layanan sabudeureun ngartos naha.
Pendekatan anu kuring promosikeun nyaéta sabalikna ti luhur-handap, pendekatan dumasar-traceview, dimana analisa dimimitian ku sadayana renik teras laun-laun jalan ka bentang individu. Kontras, pendekatan handap-up dimimitian ku analisa wewengkon leutik deukeut potensi ngabalukarkeun kajadian, lajeng expands spasi pilarian sakumaha diperlukeun (kalawan potensi bringing di tim séjén pikeun nganalisis rentang lega tina jasa). Pendekatan kadua leuwih cocog pikeun nguji hipotésis awal gancang. Sakali hasil kongkrit dicandak, éta bakal tiasa ngaléngkah ka analisis anu langkung difokuskeun sareng detil.
Ngawangun topologi
Pintonan khusus jasa tiasa janten mangpaat upami pangguna terang nu mana jasa atawa grup jasa boga tanggung jawab pikeun ngaronjatkeun latency atawa ngabalukarkeun kasalahan. Nanging, dina sistem anu kompleks, ngaidentipikasi jasa anu nyinggung tiasa janten tugas anu teu penting nalika gagal, khususna upami henteu aya pesen kasalahan anu dilaporkeun ti jasa éta.
Ngawangun topologi jasa tiasa janten bantosan anu ageung pikeun milari jasa mana anu ngalaman lonjakan tingkat kasalahan atanapi paningkatan latency anu nyababkeun jasa janten nyata degradasi. Nalika kuring ngobrol ngeunaan ngawangun topologi, kuring henteu hartosna peta jasa, mintonkeun unggal jasa sadia dina sistem jeung dipikawanoh pikeun na . Pandangan ieu henteu langkung saé tibatan traceview dumasar kana grafik asiklik terarah. Gantina Abdi hoyong ningali topologi jasa dihasilkeun dinamis, dumasar kana atribut nu tangtu kayaning laju kasalahan, waktu respon, atawa parameter-diartikeun-pamaké nu mantuan netelakeun kaayaan kalawan layanan curiga husus.
Hayu urang nyandak conto. Hayu urang ngabayangkeun situs warta hypothetical. jasa kaca imah (kaca hareup) tukeur data sareng Redis, sareng ladenan rekomendasi, sareng ladenan iklan sareng ladenan video. Ladenan vidéo nyandak pidéo tina S3 sareng metadata tina DynamoDB. Ladenan rekomendasi nampi metadata ti DynamoDB, ngamuat data ti Redis sareng MySQL, sareng nyerat pesen ka Kafka. Ladenan iklan nampi data tina MySQL sareng nyerat pesen ka Kafka.
Di handap ieu ngagambarkeun skéma topologi ieu (seueur program routing komérsial ngawangun topologi). Éta tiasa mangpaat upami anjeun kedah ngartos katergantungan jasa. Sanajan kitu, salila debug, Lamun layanan tangtu (sebutkeun, layanan video) némbongkeun ngaronjat waktu respon, topology misalna teu pisan mangpaat.
Diagram jasa tina situs warta hypothetical
Diagram di handap bakal leuwih cocog. Aya masalah sareng jasa (video) digambarkeun katuhu di tengah. pamaké éta notices langsung. Tina visualisasi ieu, janten écés yén layanan pidéo berpungsi sacara teu normal kusabab paningkatan waktos réspon S3, anu mangaruhan laju ngamuat bagian tina halaman utama.
Topologi dinamis ngan ukur nunjukkeun jasa "menarik".
Topologi anu dihasilkeun sacara dinamis tiasa langkung éfisién tibatan peta jasa statik, khususna dina infrastruktur skala otomatis anu elastis. Kamampuhan pikeun ngabandingkeun sareng kontras topologi jasa ngamungkinkeun pangguna pikeun naroskeun patarosan anu langkung relevan. Patarosan anu langkung tepat ngeunaan sistem anu langkung dipikaresep nyababkeun pamahaman anu langkung saé ngeunaan kumaha sistem jalanna.
tampilan komparatif
visualisasi mangpaat sejen bakal tampilan komparatif. Ayeuna ngambah teu cocog pisan pikeun babandingan sisi-demi-sisi, jadi babandinganana biasana bentang. Sareng ideu utama tulisan ieu nyaéta yén bentangna tingkat rendah teuing pikeun nimba inpormasi anu paling berharga tina hasil ngalacak.
Ngabandingkeun dua ngambah teu merlukeun visualizations fundamentally anyar. Kanyataanna, hal kawas histogram ngagambarkeun informasi sarua salaku traceview a cukup. Ahéng, sanajan métode basajan ieu bisa mawa leuwih loba buah ti saukur diajar dua ngambah misah. Malah leuwih kuat bakal kamungkinan ngabayangkeun ngabandingkeun ngambah Sakabehna. Ieu bakal mangpaat pisan ningali kumaha parobahan konfigurasi database nembe deployed pikeun ngaktipkeun GC (koléksi sampah) mangaruhan waktu respon hiji layanan hilir dina skala sababaraha jam. Upami naon anu kuring dijelaskeun di dieu sapertos analisa A / B ngeunaan dampak parobahan infrastruktur dina loba jasa ngagunakeun hasil renik, mangka anjeun teu jauh teuing tina bebeneran.
kacindekan
Abdi henteu naroskeun mangpaat tina nyukcruk sorangan. Kuring tulus yakin yén teu aya padika séjén pikeun ngumpulkeun data sakumaha euyeub, kausal jeung kontekstual sakumaha anu dikandung dina renik a. Nanging, kuring ogé yakin yén sadaya solusi ngalacak ngagunakeun data ieu sacara teu éfisién. Salami parabot tracing tetep nyangkut dina ngagambarkeun traceview, aranjeunna bakal diwatesan dina pangabisa maranéhna pikeun nyieun kalolobaan inpo berharga nu bisa sasari tina data dikandung dina ngambah. Salaku tambahan, aya résiko ngembangkeun antarmuka visual anu teu ramah sareng teu intuitif anu parah bakal ngabatesan kamampuan pangguna pikeun ngungkulan kasalahan dina aplikasi.
Debugging sistem kompléks, sanajan kalawan parabot panganyarna, nyaeta incredibly hésé. Alat kedah ngabantosan pamekar ngarumuskeun sareng nguji hipotésis, aktip nyadiakeun informasi relevan, ngaidentipikasi outliers sarta noting fitur dina sebaran reureuh. Pikeun ngalacak janten alat pilihan pikeun pamekar nalika ngungkulan kagagalan produksi atanapi ngarengsekeun masalah anu ngalangkungan sababaraha jasa, antarmuka pangguna asli sareng visualisasi diperyogikeun anu langkung konsisten sareng modél mental para pamekar anu nyiptakeun sareng ngoperasikeun jasa éta.
Butuh usaha méntal anu penting pikeun ngarancang sistem anu bakal ngawakilan rupa-rupa sinyal anu aya dina hasil ngambah ku cara anu dioptimalkeun pikeun ngagampangkeun analisa sareng inferensi. Anjeun kedah mikirkeun kumaha cara abstrak topologi sistem nalika debugging ku cara anu ngabantosan pangguna pikeun ngatasi bintik buta tanpa ningali jejak atanapi bentang individu.
Urang peryogi kamampuan abstraksi sareng layering anu saé (utamana dina UI). Anu bakal pas kana prosés debugging anu didorong hipotésis dimana anjeun tiasa naroskeun patarosan sareng nguji hipotesis. Aranjeunna moal otomatis ngajawab sagala masalah observasi, tapi maranéhna bakal mantuan pamaké ngasah intuisi maranéhanana sarta ngarumuskeun patarosan smarter. Kuring nyauran pendekatan anu langkung wijaksana sareng inovatif pikeun visualisasi. Aya prospek nyata di dieu pikeun ngalegaan cakrawala.
PS ti penerjemah
Baca ogé dina blog urang:
- «";
- «";
- «".
sumber: www.habr.com