🥇Pengesanan yang diedarkan: kami melakukan semua yang salah

Catatan. terjemah: Pengarang bahan ini ialah Cindy Sridharan, seorang jurutera di imgix yang pakar dalam pembangunan API dan, khususnya, ujian perkhidmatan mikro. Dalam bahan ini, dia berkongsi wawasan terperinci tentang masalah semasa dalam bidang pengesanan teragih, di mana, pada pendapatnya, terdapat kekurangan alat yang benar-benar berkesan untuk menyelesaikan masalah yang mendesak.

[Ilustrasi diambil daripada bahan lain mengenai pengesanan yang diedarkan.]

Adalah dipercayai bahawa pengesanan yang diedarkan sukar untuk dilaksanakan, dan pulangan ke atasnya paling meragukan. Terdapat banyak sebab mengapa pengesanan bermasalah, selalunya memetik tenaga kerja yang terlibat dalam mengkonfigurasi setiap komponen sistem untuk menghantar pengepala yang sesuai dengan setiap permintaan. Walaupun masalah ini wujud, ia sama sekali tidak dapat diatasi. Ngomong-ngomong, ia tidak menjelaskan mengapa pembangun tidak begitu suka menjejak (walaupun ia sudah berfungsi).

Cabaran utama dengan pengesanan teragih ialah tidak mengumpul data, menyeragamkan format untuk mengedar dan membentangkan hasil, atau menentukan bila, di mana dan cara untuk membuat sampel. Saya tidak cuba membayangkan remeh "masalah kefahaman" ini, sebenarnya, adalah teknikal yang agak ketara dan (jika kami anggap benar-benar Sumber Terbuka) piawaian dan protokol) cabaran politik yang perlu diatasi agar masalah ini dianggap selesai.

Walau bagaimanapun, jika kita membayangkan bahawa semua masalah ini diselesaikan, terdapat kebarangkalian yang tinggi bahawa tiada apa-apa yang akan berubah dengan ketara dari segi pengalaman pengguna akhir. Pengesanan mungkin masih tidak boleh digunakan secara praktikal dalam senario penyahpepijatan yang paling biasa—walaupun selepas ia digunakan.

Jejak yang begitu berbeza

Pengesanan teragih termasuk beberapa komponen yang berbeza:

melengkapkan aplikasi dan perisian tengah dengan alat kawalan;
pemindahan konteks teragih;
pengumpulan jejak;
penyimpanan jejak;
pengekstrakan dan visualisasi mereka.

Banyak perbincangan mengenai pengesanan teragih cenderung menganggapnya sebagai sejenis operasi unari yang tujuan utamanya adalah untuk membantu mendiagnosis sistem sepenuhnya. Ini sebahagian besarnya disebabkan oleh cara idea tentang pengesanan yang diedarkan telah terbentuk secara sejarah. DALAM entri blog, dibuat apabila sumber Zipkin dibuka, disebutkan bahawa ia [Zipkin] menjadikan Twitter lebih pantas. Tawaran komersial pertama untuk pengesanan juga dipromosikan sebagai alatan APM.

Catatan. terjemah: Untuk menjadikan teks selanjutnya lebih mudah difahami, mari kita takrifkan dua istilah asas mengikut Dokumentasi projek OpenTracing:

Span — elemen asas pengesanan teragih. Ia ialah perihalan aliran kerja tertentu (contohnya, pertanyaan pangkalan data) dengan nama, masa mula dan tamat, teg, log dan konteks.
Span biasanya mengandungi pautan ke span lain, membolehkan beberapa span digabungkan Trace — visualisasi hayat permintaan semasa ia bergerak melalui sistem yang diedarkan.

Jejak mengandungi data yang sangat berharga yang boleh membantu dengan tugas seperti ujian pengeluaran, ujian pemulihan bencana, ujian suntikan ralat, dsb. Malah, beberapa syarikat sudah menggunakan pengesanan untuk tujuan yang sama. Mari kita mulakan dengan pemindahan konteks universal mempunyai kegunaan lain selain hanya memindahkan rentang ke sistem storan:

Contohnya, Uber kegunaan mengesan keputusan untuk membezakan antara trafik ujian dan trafik pengeluaran.
Facebook kegunaan data jejak untuk analisis laluan kritikal dan untuk penukaran trafik semasa ujian pemulihan bencana biasa.
Juga rangkaian sosial berlaku Buku nota Jupyter yang membenarkan pembangun menjalankan pertanyaan sewenang-wenangnya pada hasil surih.
Penganut LDFI (Suntikan Kegagalan Didorong Keturunan) menggunakan jejak yang diedarkan untuk ujian dengan suntikan ralat.

Tiada satu pun daripada pilihan yang disenaraikan di atas digunakan sepenuhnya pada senario nyahpepijat, di mana jurutera cuba menyelesaikan masalah dengan melihat kesan.

Bila ia datang lagi mencapai skrip penyahpepijatan, antara muka utama kekal sebagai rajah traceview (walaupun ada juga yang memanggilnya "Carta Gantt" atau "gambar rajah air terjun"). Di bawah traceview я saya maksudkan semua rentang dan metadata yang disertakan bersama-sama membentuk jejak. Setiap sistem pengesanan sumber terbuka, serta setiap penyelesaian pengesanan komersial, menawarkan a traceview antara muka pengguna untuk menggambarkan, memperincikan dan menapis jejak.

Masalah dengan semua sistem pengesanan yang saya lihat setakat ini ialah yang terhasil visualisasi (traceview) hampir sepenuhnya mencerminkan ciri-ciri proses penjanaan surih. Walaupun visualisasi alternatif dicadangkan: peta haba, topologi perkhidmatan, histogram kependaman, ia tetap turun ke traceview.

Pada masa lalu saya merungut bahawa kebanyakan "inovasi" pengesanan UI/UX nampaknya terhad kepada menghidupkan metadata tambahan dalam jejak, melabur di dalamnya maklumat dengan kardinaliti tinggi (kardinaliti tinggi) atau menyediakan keupayaan untuk menelusuri rentang tertentu atau menjalankan pertanyaan inter- dan intra-trace... Di mana traceview kekal sebagai alat visualisasi utama. Selagi keadaan ini berterusan, pengesanan yang diedarkan (paling baik) akan mengambil tempat ke-4 sebagai alat nyahpepijat, selepas metrik, log dan jejak tindanan, dan paling teruk ia akan menjadi pembaziran wang dan masa.

Masalah dengan traceview

Tujuan traceview — memberikan gambaran lengkap tentang pergerakan permintaan tunggal merentasi semua komponen sistem yang diedarkan yang berkaitan dengannya. Beberapa sistem pengesanan yang lebih maju membolehkan anda menelusuri rentang individu dan melihat pecahan dari semasa ke semasa dalam satu proses (apabila rentang mempunyai sempadan fungsi).

Premis asas seni bina perkhidmatan mikro ialah idea bahawa struktur organisasi berkembang mengikut keperluan syarikat. Penyokong perkhidmatan mikro berpendapat bahawa mengagihkan pelbagai tugas perniagaan ke dalam perkhidmatan individu membolehkan pasukan pembangunan yang kecil dan berautonomi mengawal keseluruhan kitaran hayat perkhidmatan tersebut, memberikan mereka keupayaan untuk membina, menguji dan menggunakan perkhidmatan tersebut secara bebas. Walau bagaimanapun, kelemahan pengedaran ini ialah kehilangan maklumat tentang cara setiap perkhidmatan berinteraksi dengan orang lain. Dalam keadaan sedemikian, dakwaan pengesanan yang diedarkan sebagai alat yang sangat diperlukan untuk nyahpepijat interaksi yang kompleks antara perkhidmatan.

Jika anda benar-benar sistem teragih yang sangat kompleks, maka tidak ada seorang pun yang mampu menyimpannya di dalam kepalanya lengkap gambar. Malah, membangunkan alat berdasarkan andaian bahawa ia mungkin adalah sesuatu yang anti-corak (pendekatan yang tidak berkesan dan tidak produktif). Sebaik-baiknya, penyahpepijatan memerlukan alat yang membantu sempitkan kawasan carian anda, supaya jurutera boleh menumpukan pada subset dimensi (perkhidmatan/pengguna/hos, dsb.) yang berkaitan dengan senario masalah yang sedang dipertimbangkan. Apabila menentukan punca kegagalan, jurutera tidak perlu memahami apa yang berlaku semasa semua perkhidmatan sekali gus, kerana keperluan sedemikian akan bercanggah dengan idea seni bina perkhidmatan mikro.

Walau bagaimanapun, traceview adalah iaitu ini. Ya, sesetengah sistem pengesanan menawarkan paparan surih termampat apabila bilangan rentang dalam surih adalah sangat besar sehingga ia tidak dapat dipaparkan dalam satu visualisasi. Walau bagaimanapun, disebabkan oleh jumlah besar maklumat yang terkandung walaupun dalam visualisasi yang dilucutkan, jurutera masih terpaksa "ayak" ia, secara manual menyempitkan pemilihan kepada satu set perkhidmatan yang menjadi punca masalah. Malangnya, dalam bidang ini, mesin jauh lebih pantas daripada manusia, kurang terdedah kepada ralat, dan keputusannya lebih berulang.

Satu lagi sebab saya fikir traceview adalah salah adalah kerana ia tidak baik untuk penyahpepijatan yang dipacu hipotesis. Pada terasnya, penyahpepijatan adalah berulang satu proses yang bermula dengan hipotesis, diikuti dengan pengesahan pelbagai pemerhatian dan fakta yang diperolehi daripada sistem di sepanjang vektor yang berbeza, kesimpulan/generalisasi dan penilaian lanjut tentang kebenaran hipotesis.

Peluang cepat dan murah menguji hipotesis dan memperbaiki model mental sewajarnya adalah batu asas penyahpepijatan Sebarang alat penyahpepijatan sepatutnya interaktif dan sempitkan ruang carian atau, dalam kes petunjuk palsu, benarkan pengguna untuk kembali dan fokus pada kawasan sistem yang berbeza. Alat yang sempurna akan melakukan ini secara proaktif, segera menarik perhatian pengguna kepada kawasan masalah yang berpotensi.

Malangnya, traceview tidak boleh dipanggil alat dengan antara muka interaktif. Perkara terbaik yang anda boleh harapkan apabila menggunakannya ialah mencari beberapa sumber peningkatan kependaman dan melihat semua kemungkinan teg dan log yang dikaitkan dengannya. Ini tidak membantu jurutera untuk mengenal pasti corak dalam trafik, seperti spesifik taburan kelewatan, atau mengesan korelasi antara ukuran yang berbeza. Analisis jejak umum boleh membantu mengatasi beberapa masalah ini. sungguh, ada contoh analisis yang berjaya menggunakan pembelajaran mesin untuk mengenal pasti rentang anomali dan mengenal pasti subset teg yang mungkin dikaitkan dengan tingkah laku anomali. Walau bagaimanapun, saya masih belum melihat visualisasi pembelajaran mesin atau penemuan perlombongan data yang menarik digunakan pada rentang yang jauh berbeza daripada paparan surih atau DAG (graf asiklik terarah).

Span adalah tahap terlalu rendah

Masalah asas dengan traceview ialah menjangkau adalah primitif peringkat rendah untuk kedua-dua analisis kependaman dan analisis punca punca. Ia seperti menghuraikan perintah pemproses individu untuk cuba menyelesaikan pengecualian, mengetahui bahawa terdapat alat tahap yang lebih tinggi seperti jejak belakang yang lebih mudah digunakan.

Lebih-lebih lagi, saya akan mengambil kebebasan untuk menegaskan perkara berikut: idealnya, kita tidak perlu gambar penuh berlaku semasa kitaran hayat permintaan, yang diwakili oleh alat pengesanan moden. Sebaliknya, beberapa bentuk abstraksi peringkat tinggi diperlukan yang mengandungi maklumat tentang apa tersilap (serupa dengan jejak belakang), bersama-sama dengan beberapa konteks. Daripada menonton keseluruhan jejak, saya lebih suka melihatnya часть, di mana sesuatu yang menarik atau luar biasa berlaku. Pada masa ini, carian dijalankan secara manual: jurutera menerima jejak dan secara bebas menganalisis rentang untuk mencari sesuatu yang menarik. Pendekatan orang yang merenung rentang dalam jejak individu dengan harapan dapat mengesan aktiviti yang mencurigakan tidak berskala sama sekali (terutama apabila mereka perlu memahami semua metadata yang dikodkan dalam rentang yang berbeza, seperti ID span, nama kaedah RPC, tempoh rentang 'a, log, tag, dll.).

Alternatif kepada traceview

Hasil surih adalah paling berguna apabila ia boleh divisualisasikan dalam cara yang memberikan cerapan bukan remeh tentang perkara yang berlaku dalam bahagian sistem yang saling berkaitan. Sehingga ini berlaku, proses penyahpepijatan sebahagian besarnya kekal lengai dan bergantung pada keupayaan pengguna untuk melihat korelasi yang betul, menyemak bahagian sistem yang betul atau meletakkan kepingan teka-teki bersama-sama - berbanding dengan alat, membantu pengguna merumuskan hipotesis ini.

Saya bukan pereka visual atau pakar UX, tetapi dalam bahagian seterusnya saya ingin berkongsi beberapa idea tentang rupa visualisasi ini.

Fokus pada perkhidmatan tertentu

Pada masa apabila industri menyatukan idea SLO (objektif tahap perkhidmatan) dan SLI (penunjuk tahap perkhidmatan), nampaknya munasabah bahawa pasukan individu harus mengutamakan memastikan perkhidmatan mereka sejajar dengan matlamat ini. Ia berikutan itu berorientasikan perkhidmatan visualisasi paling sesuai untuk pasukan sedemikian.

Jejak, terutamanya tanpa pensampelan, adalah khazanah maklumat tentang setiap komponen sistem teragih. Maklumat ini boleh disalurkan kepada pemproses licik yang akan membekalkan pengguna berorientasikan perkhidmatan penemuan. Ia boleh dikenal pasti lebih awal - walaupun sebelum pengguna melihat kesan:

Gambar rajah pengedaran kependaman hanya untuk permintaan yang sangat menonjol (permintaan luar biasa);
Gambar rajah pengedaran kelewatan untuk kes apabila matlamat SLO perkhidmatan tidak tercapai;
Teg yang paling "biasa", "menarik" dan "pelik" dalam pertanyaan yang paling kerap diulang;
Pecahan latensi untuk kes di mana kebergantungan perkhidmatan tidak mencapai matlamat SLO mereka;
Pecahan latensi untuk pelbagai perkhidmatan hiliran.

Sesetengah soalan ini tidak dijawab oleh metrik terbina dalam, memaksa pengguna untuk meneliti rentang. Akibatnya, kami mempunyai mekanisme yang sangat memusuhi pengguna.

Ini menimbulkan persoalan: bagaimana pula dengan interaksi kompleks antara pelbagai perkhidmatan yang dikawal oleh pasukan yang berbeza? bukankah traceview tidak dianggap sebagai alat yang paling sesuai untuk menonjolkan keadaan sedemikian?

Pembangun mudah alih, pemilik perkhidmatan tanpa negara, pemilik perkhidmatan stateful terurus (seperti pangkalan data) dan pemilik platform mungkin berminat dengan sesuatu yang lain pembentangan sistem teragih; traceview adalah penyelesaian yang terlalu generik untuk keperluan asas yang berbeza ini. Walaupun dalam seni bina perkhidmatan mikro yang sangat kompleks, pemilik perkhidmatan tidak memerlukan pengetahuan mendalam tentang lebih daripada dua atau tiga perkhidmatan huluan dan hiliran. Pada asasnya, dalam kebanyakan senario, pengguna hanya perlu menjawab soalan berkenaan set perkhidmatan terhad.

Ia seperti melihat subset kecil perkhidmatan melalui kaca pembesar untuk tujuan menelitinya. Ini akan membolehkan pengguna bertanya lebih banyak soalan mendesak mengenai interaksi kompleks antara perkhidmatan ini dan kebergantungan segera mereka. Ini serupa dengan jejak belakang dalam dunia perkhidmatan, di mana jurutera tahu bahawa salah, dan juga mempunyai sedikit pemahaman tentang perkara yang berlaku dalam perkhidmatan sekeliling untuk difahami mengapa.

Pendekatan yang saya promosikan adalah bertentangan dengan pendekatan atas-bawah, berasaskan tinjauan, di mana analisis bermula dengan keseluruhan jejak dan kemudian beransur-ansur turun ke rentang individu. Sebaliknya, pendekatan bawah ke atas bermula dengan menganalisis kawasan kecil berhampiran dengan potensi punca kejadian, dan kemudian mengembangkan ruang carian mengikut keperluan (dengan potensi membawa masuk pasukan lain untuk menganalisis rangkaian perkhidmatan yang lebih luas). Pendekatan kedua lebih sesuai untuk menguji hipotesis awal dengan cepat. Sebaik sahaja keputusan konkrit diperolehi, adalah mungkin untuk beralih kepada analisis yang lebih disasarkan dan terperinci.

Membina topologi

Pandangan khusus perkhidmatan boleh menjadi sangat berguna jika pengguna tahu apa perkhidmatan atau kumpulan perkhidmatan bertanggungjawab untuk meningkatkan kependaman atau menyebabkan ralat. Walau bagaimanapun, dalam sistem yang kompleks, mengenal pasti perkhidmatan yang menyinggung perasaan mungkin merupakan tugas yang tidak remeh semasa kegagalan, terutamanya jika tiada mesej ralat dilaporkan daripada perkhidmatan tersebut.

Membina topologi perkhidmatan boleh menjadi bantuan besar dalam memikirkan perkhidmatan yang mengalami lonjakan dalam kadar ralat atau peningkatan dalam kependaman yang menyebabkan perkhidmatan itu merosot dengan ketara. Apabila saya bercakap tentang membina topologi, saya tidak bermaksud peta perkhidmatan, memaparkan setiap perkhidmatan yang tersedia dalam sistem dan terkenal dengan perkhidmatannya peta seni bina berbentuk bintang kematian. Pandangan ini tidak lebih baik daripada paparan jejak berdasarkan graf akiklik terarah. Sebaliknya saya ingin melihat topologi perkhidmatan yang dijana secara dinamik, berdasarkan atribut tertentu seperti kadar ralat, masa tindak balas atau mana-mana parameter yang ditentukan pengguna yang membantu menjelaskan situasi dengan perkhidmatan yang mencurigakan tertentu.

Mari kita ambil contoh. Mari kita bayangkan tapak berita hipotesis. Perkhidmatan halaman utama (muka depan) bertukar data dengan Redis, dengan perkhidmatan pengesyoran, dengan perkhidmatan pengiklanan dan perkhidmatan video. Perkhidmatan video mengambil video daripada S3 dan metadata daripada DynamoDB. Perkhidmatan pengesyoran menerima metadata daripada DynamoDB, memuatkan data daripada Redis dan MySQL, dan menulis mesej kepada Kafka. Perkhidmatan pengiklanan menerima data daripada MySQL dan menulis mesej kepada Kafka.

Di bawah ialah perwakilan skematik topologi ini (banyak program penghalaan komersial membina topologi). Ia boleh berguna jika anda perlu memahami kebergantungan perkhidmatan. Bagaimanapun, semasa nyahpepijat, apabila perkhidmatan tertentu (katakan, perkhidmatan video) menunjukkan peningkatan masa tindak balas, topologi sedemikian tidak begitu berguna.

Gambar rajah perkhidmatan tapak berita hipotesis

Gambar rajah di bawah adalah lebih sesuai. Terdapat masalah dengan perkhidmatan (video) digambarkan betul-betul di tengah. Pengguna menyedarinya serta-merta. Daripada visualisasi ini, menjadi jelas bahawa perkhidmatan video beroperasi secara tidak normal disebabkan oleh peningkatan dalam masa tindak balas S3, yang menjejaskan kelajuan pemuatan sebahagian halaman utama.

Topologi dinamik hanya memaparkan perkhidmatan "menarik".

Topologi yang dijana secara dinamik boleh menjadi lebih cekap daripada peta perkhidmatan statik, terutamanya dalam infrastruktur penskalaan automatik yang anjal. Keupayaan untuk membandingkan dan membezakan topologi perkhidmatan membolehkan pengguna bertanya soalan yang lebih berkaitan. Soalan yang lebih tepat tentang sistem lebih berkemungkinan membawa kepada pemahaman yang lebih baik tentang cara sistem berfungsi.

Paparan perbandingan

Satu lagi visualisasi berguna ialah paparan perbandingan. Pada masa ini jejak tidak begitu sesuai untuk perbandingan sebelah menyebelah, jadi perbandingan biasanya menjangkau. Dan idea utama artikel ini adalah tepat bahawa rentang terlalu rendah untuk mengekstrak maklumat yang paling berharga daripada hasil surih.

Membandingkan dua jejak tidak memerlukan visualisasi asas yang baharu. Malah, sesuatu seperti histogram yang mewakili maklumat yang sama seperti traceview sudah memadai. Yang menghairankan, walaupun kaedah mudah ini boleh membawa lebih banyak buah daripada hanya mengkaji dua jejak secara berasingan. Lebih kuat lagi kemungkinan itu bayangkan perbandingan jejak Dalam jumlah. Adalah amat berguna untuk melihat bagaimana perubahan konfigurasi pangkalan data yang digunakan baru-baru ini untuk mendayakan GC (pengumpulan sampah) mempengaruhi masa tindak balas perkhidmatan hiliran pada skala beberapa jam. Jika apa yang saya huraikan di sini kelihatan seperti analisis A/B tentang kesan perubahan infrastruktur dalam banyak perkhidmatan menggunakan hasil surih, maka anda tidak terlalu jauh dari kebenaran.

Kesimpulan

Saya tidak mempersoalkan kegunaan pengesanan itu sendiri. Saya benar-benar percaya bahawa tidak ada kaedah lain untuk mengumpul data yang kaya, bersebab dan kontekstual seperti yang terkandung dalam surih. Walau bagaimanapun, saya juga percaya bahawa semua penyelesaian pengesanan menggunakan data ini dengan sangat tidak cekap. Selagi alat pengesanan kekal tersangkut pada perwakilan paparan jejak, mereka akan terhad dalam keupayaan mereka untuk memanfaatkan sepenuhnya maklumat berharga yang boleh diekstrak daripada data yang terkandung dalam jejak. Di samping itu, terdapat risiko untuk membangunkan lagi antara muka visual yang tidak mesra dan tidak intuitif yang akan mengehadkan keupayaan pengguna untuk menyelesaikan masalah dalam aplikasi dengan teruk.

Menyahpepijat sistem kompleks, walaupun dengan alat terkini, adalah sangat sukar. Alat harus membantu pembangun merumus dan menguji hipotesis, secara aktif menyediakan maklumat yang berkaitan, mengenal pasti outlier dan mencatat ciri dalam pengedaran kelewatan. Untuk mengesan menjadi alat pilihan pembangun apabila menyelesaikan masalah kegagalan pengeluaran atau menyelesaikan masalah yang merangkumi pelbagai perkhidmatan, antara muka dan visualisasi pengguna asal diperlukan yang lebih konsisten dengan model mental pembangun yang mencipta dan mengendalikan perkhidmatan tersebut.

Ia akan mengambil usaha mental yang ketara untuk mereka bentuk sistem yang akan mewakili pelbagai isyarat yang tersedia dalam hasil surih dengan cara yang dioptimumkan untuk memudahkan analisis dan inferens. Anda perlu memikirkan cara mengabstraksikan topologi sistem semasa penyahpepijatan dengan cara yang membantu pengguna mengatasi titik buta tanpa melihat jejak atau rentang individu.

Kami memerlukan keupayaan abstraksi dan lapisan yang baik (terutamanya dalam UI). Yang sesuai dengan proses penyahpepijatan yang dipacu hipotesis di mana anda boleh bertanya soalan dan menguji hipotesis secara berulang. Mereka tidak akan menyelesaikan semua masalah kebolehmerhatian secara automatik, tetapi mereka akan membantu pengguna mempertajam gerak hati mereka dan merumuskan soalan yang lebih bijak. Saya menyeru pendekatan yang lebih bijak dan inovatif untuk visualisasi. Terdapat prospek sebenar di sini untuk mengembangkan ufuk.

Penjejakan yang Diedarkan: Kami Salah