Catatan. terjemahan: Penulis materi ini adalah Cindy Sridharan, seorang insinyur di imgix yang berspesialisasi dalam pengembangan API dan, khususnya, pengujian layanan mikro. Dalam materi ini, ia membagikan visi rincinya tentang permasalahan terkini di bidang penelusuran terdistribusi, di mana menurutnya, alat yang benar-benar efektif untuk memecahkan masalah yang mendesak masih kurang.
[Ilustrasi diambil dari tentang penelusuran terdistribusi.]
Hal ini diyakini bahwa sulit untuk diterapkan, dan keuntungannya . Ada banyak alasan mengapa penelusuran menjadi masalah, sering kali mengutip tenaga kerja yang terlibat dalam mengonfigurasi setiap komponen sistem untuk mengirimkan header yang sesuai dengan setiap permintaan. Meskipun masalah ini memang ada, namun bukan berarti masalah ini tidak dapat diatasi. Omong-omong, ini tidak menjelaskan mengapa pengembang tidak terlalu menyukai penelusuran (meskipun sudah berfungsi).
Tantangan utama penelusuran terdistribusi bukanlah pengumpulan data, standarisasi format untuk mendistribusikan dan menyajikan hasil, atau menentukan kapan, di mana, dan bagaimana mengambil sampel. Saya tidak mencoba membayangkan remeh "masalah pemahaman" ini, pada kenyataannya, bersifat teknis dan cukup signifikan (jika kita mempertimbangkan Open Source yang sesungguhnya) ) tantangan politik yang perlu diatasi agar permasalahan tersebut dianggap terpecahkan.
Namun, jika kita membayangkan bahwa semua masalah ini telah terpecahkan, kemungkinan besar tidak ada perubahan signifikan dalam hal ini pengalaman pengguna akhir. Penelusuran mungkin masih belum berguna secara praktis dalam skenario proses debug yang paling umum—bahkan setelah pelacakan diterapkan.
Jejak yang berbeda
Penelusuran terdistribusi mencakup beberapa komponen berbeda:
- melengkapi aplikasi dan middleware dengan alat kontrol;
- transfer konteks terdistribusi;
- kumpulan jejak;
- penyimpanan jejak;
- ekstraksi dan visualisasinya.
Banyak pembicaraan tentang penelusuran terdistribusi cenderung memperlakukannya sebagai semacam operasi tunggal yang tujuan utamanya adalah membantu mendiagnosis sistem sepenuhnya. Hal ini sebagian besar disebabkan oleh bagaimana gagasan tentang penelusuran terdistribusi terbentuk secara historis. DI DALAM , dibuat saat sumber Zipkin dibuka, disebutkan demikian itu [Zipkin] membuat Twitter lebih cepat. Penawaran komersial pertama untuk penelusuran juga dipromosikan sebagai .
Catatan. terjemahan: Untuk membuat teks selanjutnya lebih mudah dipahami, mari kita definisikan dua istilah dasar menurut :
- Menjangkau — elemen dasar penelusuran terdistribusi. Ini adalah deskripsi alur kerja tertentu (misalnya, kueri database) dengan nama, waktu mulai dan berakhir, tag, log, dan konteks.
- Rentang biasanya berisi tautan ke rentang lain, sehingga memungkinkan beberapa rentang digabungkan menjadi satu Jejak — visualisasi kehidupan permintaan saat bergerak melalui sistem terdistribusi.
Jejak berisi data yang sangat berharga yang dapat membantu tugas-tugas seperti pengujian produksi, pengujian pemulihan bencana, pengujian injeksi kesalahan, dll. Faktanya, beberapa perusahaan sudah menggunakan penelusuran untuk tujuan serupa. Mari kita mulai dengan memiliki kegunaan lain selain sekadar memindahkan rentang ke sistem penyimpanan:
- Misalnya Uber hasil penelusuran untuk membedakan antara lalu lintas pengujian dan lalu lintas produksi.
- Facebook melacak data untuk analisis jalur kritis dan peralihan lalu lintas selama pengujian pemulihan bencana rutin.
- Juga jejaring sosial Notebook Jupyter yang memungkinkan pengembang menjalankan kueri arbitrer pada hasil penelusuran.
- Penganut (Injeksi Kegagalan Berbasis Silsilah) jejak terdistribusi untuk pengujian dengan injeksi kesalahan.
Tak satu pun dari opsi yang tercantum di atas berlaku sepenuhnya untuk skenario ini melakukan debug, di mana insinyur mencoba memecahkan masalah dengan melihat jejaknya.
Ketika itu datang belum mencapai skrip debugging, antarmuka utama tetap berupa diagram tampilan jejak (walaupun ada juga yang menyebutnya "Bagan Gantt" или "diagram air terjun"). Di bawah tampilan jejak я semua rentang dan metadata yang menyertainya yang bersama-sama membentuk jejak. Setiap sistem penelusuran sumber terbuka, serta setiap solusi penelusuran komersial, menawarkan a tampilan jejak antarmuka pengguna untuk memvisualisasikan, merinci, dan memfilter jejak.
Masalah dengan semua sistem penelusuran yang saya lihat sejauh ini adalah hasilnya visualisasi (tampilan jejak) hampir sepenuhnya mencerminkan fitur proses pembuatan jejak. Bahkan ketika visualisasi alternatif diusulkan: peta panas, topologi layanan, histogram latensi, pada akhirnya tetap saja tampilan jejak.
Di masa lalu saya bahwa sebagian besar "inovasi" dalam penelusuran UI/UX tampaknya terbatas metadata tambahan dalam penelusuran, memasukkan informasi dengan kardinalitas tinggi ke dalamnya (kardinalitas tinggi) atau memberikan kemampuan untuk menelusuri rentang tertentu atau menjalankan kueri antar dan intra-jejak... Di mana tampilan jejak tetap menjadi alat visualisasi utama. Selama keadaan ini terus berlanjut, pelacakan terdistribusi (yang terbaik) akan menempati posisi ke-4 sebagai alat debugging, setelah metrik, log, dan pelacakan tumpukan, dan yang terburuk, hal ini akan membuang-buang uang dan waktu.
Masalah dengan tampilan jejak
Tujuan tampilan jejak — memberikan gambaran lengkap tentang pergerakan satu permintaan di seluruh komponen sistem terdistribusi yang terkait. Beberapa sistem penelusuran yang lebih canggih memungkinkan Anda menelusuri rentang individual dan melihat pengelompokannya dari waktu ke waktu dalam satu proses (ketika rentang memiliki batas fungsional).
Premis dasar arsitektur layanan mikro adalah gagasan bahwa struktur organisasi berkembang seiring dengan kebutuhan perusahaan. Para pendukung layanan mikro berpendapat bahwa mendistribusikan berbagai tugas bisnis ke dalam layanan individual memungkinkan tim pengembangan kecil dan otonom mengendalikan seluruh siklus hidup layanan tersebut, sehingga memberi mereka kemampuan untuk secara mandiri membangun, menguji, dan menerapkan layanan tersebut. Namun, kelemahan dari distribusi ini adalah hilangnya informasi tentang bagaimana setiap layanan berinteraksi dengan layanan lainnya. Dalam kondisi seperti itu, penelusuran terdistribusi diklaim sebagai alat yang sangat diperlukan melakukan debug interaksi kompleks antar layanan.
Jika kamu benar-benar , maka tidak ada seorang pun yang mampu mengingatnya lengkap gambar. Faktanya, mengembangkan alat berdasarkan asumsi bahwa hal itu mungkin dilakukan adalah sesuatu yang anti-pola (pendekatan yang tidak efektif dan tidak produktif). Idealnya, debugging memerlukan alat yang membantu mempersempit area pencarian Anda, sehingga teknisi dapat fokus pada subset dimensi (layanan/pengguna/host, dll.) yang relevan dengan skenario masalah yang sedang dipertimbangkan. Saat menentukan penyebab kegagalan, insinyur tidak diharuskan memahami apa yang terjadi selama kegagalan semua layanan sekaligus, karena persyaratan seperti itu akan bertentangan dengan gagasan arsitektur layanan mikro.
Namun, tampilan jejak adalah persis Ini. Ya, beberapa sistem penelusuran menawarkan tampilan penelusuran terkompresi ketika jumlah rentang dalam penelusuran sangat besar sehingga tidak dapat ditampilkan dalam satu visualisasi. Namun, karena banyaknya informasi yang terkandung bahkan dalam visualisasi yang disederhanakan, para insinyur tetap melakukannya dipaksa “menyaringnya”, secara manual mempersempit pilihan ke serangkaian layanan yang menjadi sumber masalah. Sayangnya, dalam bidang ini, mesin jauh lebih cepat dibandingkan manusia, tidak terlalu rentan terhadap kesalahan, dan hasilnya lebih dapat diulang.
Alasan lain menurut saya traceview salah adalah karena ini tidak baik untuk debugging berdasarkan hipotesis. Pada intinya, debugging adalah berulang suatu proses yang dimulai dengan hipotesis, dilanjutkan dengan verifikasi berbagai pengamatan dan fakta yang diperoleh dari sistem sepanjang vektor yang berbeda, kesimpulan/generalisasi dan penilaian lebih lanjut terhadap kebenaran hipotesis.
Kesempatan cepat dan murah menguji hipotesis dan memperbaiki model mental yang sesuai landasan melakukan debug Alat debugging apa pun seharusnya interaktif dan mempersempit ruang pencarian atau, dalam kasus petunjuk yang salah, memungkinkan pengguna untuk kembali dan fokus pada area lain dari sistem. Alat yang sempurna akan melakukan ini secara proaktif, segera menarik perhatian pengguna ke area masalah potensial.
Sayang, tampilan jejak tidak bisa disebut alat dengan antarmuka interaktif. Hal terbaik yang dapat Anda harapkan saat menggunakannya adalah menemukan sumber latensi yang meningkat dan melihat semua kemungkinan tag dan log yang terkait dengannya. Ini tidak membantu insinyur untuk mengidentifikasi pola dalam lalu lintas, seperti distribusi penundaan secara spesifik, atau mendeteksi korelasi antara pengukuran yang berbeda. dapat membantu mengatasi beberapa masalah ini. Benar-benar, analisis yang berhasil menggunakan pembelajaran mesin untuk mengidentifikasi rentang anomali dan mengidentifikasi subkumpulan tag yang mungkin terkait dengan perilaku anomali. Namun, saya belum melihat visualisasi menarik dari pembelajaran mesin atau temuan penambangan data yang diterapkan pada rentang yang sangat berbeda dari tampilan jejak atau DAG (grafik asiklik terarah).
Rentangnya terlalu rendah
Masalah mendasar dengan traceview adalah itu membentang adalah primitif tingkat rendah untuk analisis latensi dan analisis akar penyebab. Ini seperti mengurai perintah prosesor individual untuk mencoba menyelesaikan pengecualian, mengetahui bahwa ada alat tingkat yang lebih tinggi seperti penelusuran balik yang jauh lebih nyaman untuk digunakan.
Selain itu, saya akan dengan leluasa menyatakan hal berikut: idealnya, kita tidak membutuhkannya gambar lengkap terjadi selama siklus hidup permintaan, yang diwakili oleh alat penelusuran modern. Sebaliknya, diperlukan suatu bentuk abstraksi tingkat tinggi yang berisi informasi tentang apa salah (mirip dengan penelusuran balik), bersama dengan beberapa konteks. Daripada melihat keseluruhan jejaknya, saya lebih memilih melihatnya часть, tempat terjadinya sesuatu yang menarik atau tidak biasa. Saat ini, pencarian dilakukan secara manual: insinyur menerima jejak dan secara mandiri menganalisis bentang untuk mencari sesuatu yang menarik. Pendekatan orang-orang yang menatap rentang dalam jejak individual dengan harapan mendeteksi aktivitas mencurigakan tidak berskala sama sekali (terutama ketika mereka harus memahami semua metadata yang dikodekan dalam rentang berbeda, seperti ID rentang, nama metode RPC, durasi rentang 'a, log, tag, dll.).
Alternatif untuk penelusuran jejak
Hasil penelusuran paling berguna bila dapat divisualisasikan sedemikian rupa sehingga memberikan wawasan yang tidak sepele tentang apa yang terjadi di bagian-bagian sistem yang saling berhubungan. Sampai hal ini terjadi, sebagian besar proses debugging masih ada lembam dan bergantung pada kemampuan pengguna untuk memperhatikan korelasi yang benar, memeriksa bagian yang tepat dari sistem, atau menyatukan potongan-potongan teka-teki - bukannya alat, membantu pengguna merumuskan hipotesis ini.
Saya bukan seorang desainer visual atau spesialis UX, namun di bagian selanjutnya saya ingin berbagi beberapa ide tentang seperti apa visualisasi tersebut.
Fokus pada layanan tertentu
Pada saat industri sedang melakukan konsolidasi seputar ide , tampaknya masuk akal jika masing-masing tim harus memprioritaskan memastikan layanan mereka selaras dengan tujuan tersebut. Oleh karena itu berorientasi pada layanan visualisasi paling cocok untuk tim seperti itu.
Jejak, terutama tanpa pengambilan sampel, adalah gudang informasi tentang setiap komponen sistem terdistribusi. Informasi ini dapat diumpankan ke prosesor licik yang akan memasok pengguna berorientasi pada layanan Temuan tersebut dapat diidentifikasi terlebih dahulu - bahkan sebelum pengguna melihat jejaknya:
- Diagram distribusi latensi hanya untuk permintaan yang sangat menonjol (permintaan outlier);
- Diagram distribusi penundaan untuk kasus ketika sasaran SLO layanan tidak tercapai;
- Tag paling “umum”, “menarik”, dan “aneh” dalam kueri yang paling sering diulangi;
- Perincian latensi untuk kasus di mana зависимости layanan tidak mencapai sasaran SLO-nya;
- Perincian latensi untuk berbagai layanan hilir.
Beberapa pertanyaan ini tidak terjawab oleh metrik bawaan, sehingga memaksa pengguna untuk meneliti rentang. Akibatnya, kami memiliki mekanisme yang sangat tidak bersahabat dengan pengguna.
Hal ini menimbulkan pertanyaan: bagaimana dengan interaksi kompleks antara beragam layanan yang dikendalikan oleh tim berbeda? Bukan begitu tampilan jejak tidak dianggap sebagai alat yang paling tepat untuk menyoroti situasi seperti ini?
Pengembang seluler, pemilik layanan tanpa kewarganegaraan, pemilik layanan berstatus terkelola (seperti basis data), dan pemilik platform mungkin tertarik pada hal lain presentasi sistem terdistribusi; tampilan jejak merupakan solusi yang terlalu umum untuk kebutuhan-kebutuhan yang berbeda secara mendasar ini. Bahkan dalam arsitektur layanan mikro yang sangat kompleks, pemilik layanan tidak memerlukan pengetahuan mendalam tentang lebih dari dua atau tiga layanan hulu dan hilir. Pada dasarnya, di sebagian besar skenario, pengguna hanya perlu menjawab pertanyaan mengenai serangkaian layanan terbatas.
Ini seperti melihat sebagian kecil layanan melalui kaca pembesar demi untuk menelitinya. Hal ini akan memungkinkan pengguna untuk mengajukan pertanyaan yang lebih mendesak mengenai interaksi kompleks antara layanan ini dan ketergantungan langsungnya. Hal ini mirip dengan penelusuran balik di dunia jasa, dimana teknisi mengetahuinya bahwa salah, dan juga memiliki pemahaman tentang apa yang terjadi di sekitar layanan untuk dipahami mengapa.
Pendekatan yang saya promosikan adalah kebalikan dari pendekatan top-down, berbasis traceview, yang mana analisis dimulai dengan keseluruhan jejak dan kemudian secara bertahap turun ke rentang individual. Sebaliknya, pendekatan bottom-up dimulai dengan menganalisis area kecil yang dekat dengan potensi penyebab insiden, dan kemudian memperluas ruang pencarian sesuai kebutuhan (dengan potensi mendatangkan tim lain untuk menganalisis layanan yang lebih luas). Pendekatan kedua lebih cocok untuk menguji hipotesis awal dengan cepat. Setelah hasil konkrit diperoleh, maka akan dimungkinkan untuk melanjutkan ke analisis yang lebih tepat sasaran dan rinci.
Membangun topologi
Tampilan khusus layanan bisa sangat berguna jika pengguna mengetahuinya apa? suatu layanan atau sekelompok layanan bertanggung jawab untuk meningkatkan latensi atau menyebabkan kesalahan. Namun, dalam sistem yang kompleks, mengidentifikasi layanan yang melanggar mungkin merupakan tugas yang tidak sepele selama terjadi kegagalan, terutama jika tidak ada pesan kesalahan yang dilaporkan dari layanan tersebut.
Membangun topologi layanan dapat sangat membantu dalam mencari tahu layanan mana yang mengalami lonjakan tingkat kesalahan atau peningkatan latensi yang menyebabkan penurunan layanan secara nyata. Ketika saya berbicara tentang membangun topologi, saya tidak bermaksud demikian peta layanan, menampilkan setiap layanan yang tersedia di sistem dan dikenal dengan layanan tersebut . Tampilan ini tidak lebih baik dari traceview berdasarkan grafik asiklik terarah. Sebaliknya saya ingin melihat topologi layanan yang dihasilkan secara dinamis, berdasarkan atribut tertentu seperti tingkat kesalahan, waktu respons, atau parameter apa pun yang ditentukan pengguna yang membantu memperjelas situasi dengan layanan mencurigakan tertentu.
Mari kita ambil contoh. Mari kita bayangkan sebuah situs berita hipotetis. Layanan halaman rumah (halaman Depan) bertukar data dengan Redis, dengan layanan rekomendasi, dengan layanan periklanan dan layanan video. Layanan video mengambil video dari S3 dan metadata dari DynamoDB. Layanan rekomendasi menerima metadata dari DynamoDB, memuat data dari Redis dan MySQL, dan menulis pesan ke Kafka. Layanan periklanan menerima data dari MySQL dan menulis pesan ke Kafka.
Di bawah ini adalah representasi skema topologi ini (banyak program perutean komersial membangun topologi tersebut). Ini bisa berguna jika Anda perlu memahami dependensi layanan. Namun, selama melakukan debug, ketika layanan tertentu (misalnya, layanan video) menunjukkan peningkatan waktu respons, topologi seperti itu tidak terlalu berguna.
Diagram layanan situs berita hipotetis
Diagram di bawah ini akan lebih cocok. Ada masalah dengan layanannya (video) digambarkan tepat di tengah. Pengguna segera menyadarinya. Dari visualisasi ini terlihat jelas bahwa layanan video tidak berfungsi secara normal karena peningkatan waktu respons S3, yang mempengaruhi kecepatan pemuatan sebagian halaman utama.
Topologi dinamis hanya menampilkan layanan “menarik”.
Topologi yang dihasilkan secara dinamis bisa lebih efisien dibandingkan peta layanan statis, terutama dalam infrastruktur penskalaan otomatis yang elastis. Kemampuan untuk membandingkan dan membedakan topologi layanan memungkinkan pengguna untuk mengajukan pertanyaan yang lebih relevan. Pertanyaan yang lebih tepat tentang sistem akan lebih memungkinkan untuk menghasilkan pemahaman yang lebih baik tentang cara kerja sistem.
Tampilan komparatif
Visualisasi lain yang berguna adalah tampilan komparatif. Saat ini jejak tidak terlalu cocok untuk perbandingan berdampingan, jadi perbandingan biasanya cocok membentang. Dan gagasan utama artikel ini adalah bahwa rentangnya terlalu rendah untuk mengekstrak informasi paling berharga dari hasil penelusuran.
Membandingkan dua jejak tidak memerlukan visualisasi baru yang mendasar. Faktanya, sesuatu seperti histogram yang mewakili informasi yang sama dengan traceview sudah cukup. Anehnya, bahkan metode sederhana ini dapat membawa lebih banyak manfaat daripada sekadar mempelajari dua jejak secara terpisah. Kemungkinan yang lebih kuat lagi membayangkan perbandingan jejak Secara keseluruhan. Akan sangat berguna untuk melihat bagaimana perubahan konfigurasi database yang baru-baru ini diterapkan untuk mengaktifkan GC (pengumpulan sampah) memengaruhi waktu respons layanan downstream dalam skala beberapa jam. Jika yang saya uraikan di sini terdengar seperti analisis A/B tentang dampak perubahan infrastruktur di banyak layanan dengan menggunakan hasil penelusuran, maka anda tidak terlalu jauh dari kebenaran.
Kesimpulan
Saya tidak mempertanyakan kegunaan penelusuran itu sendiri. Saya sangat yakin bahwa tidak ada metode lain untuk mengumpulkan data yang kaya, kausal, dan kontekstual seperti yang terkandung dalam penelusuran. Namun, saya juga yakin bahwa semua solusi penelusuran menggunakan data ini dengan sangat tidak efisien. Selama alat penelusuran tetap terjebak pada representasi traceview, kemampuannya akan terbatas dalam memanfaatkan informasi berharga yang dapat diekstraksi dari data yang terkandung dalam jejak. Selain itu, terdapat risiko pengembangan lebih lanjut antarmuka visual yang benar-benar tidak ramah dan tidak intuitif yang akan sangat membatasi kemampuan pengguna untuk memecahkan masalah kesalahan dalam aplikasi.
Men-debug sistem yang kompleks, bahkan dengan alat terbaru, sangatlah sulit. Alat harus membantu pengembang merumuskan dan menguji hipotesis, secara aktif menyediakan informasi yang relevan, mengidentifikasi outlier dan mencatat fitur-fitur dalam distribusi penundaan. Agar penelusuran menjadi alat pilihan bagi pengembang saat memecahkan masalah kegagalan produksi atau menyelesaikan masalah yang mencakup beberapa layanan, diperlukan antarmuka pengguna dan visualisasi asli yang lebih konsisten dengan model mental pengembang yang membuat dan mengoperasikan layanan tersebut.
Dibutuhkan upaya mental yang signifikan untuk merancang sistem yang akan mewakili berbagai sinyal yang tersedia dalam hasil penelusuran dengan cara yang dioptimalkan untuk kemudahan analisis dan inferensi. Anda perlu memikirkan cara mengabstraksi topologi sistem selama proses debug dengan cara yang membantu pengguna mengatasi titik buta tanpa melihat jejak atau rentang individual.
Kita membutuhkan kemampuan abstraksi dan layering yang baik (terutama di UI). Yang cocok dengan proses debugging berbasis hipotesis di mana Anda dapat mengajukan pertanyaan dan menguji hipotesis secara berulang. Mereka tidak secara otomatis memecahkan semua masalah observasi, namun mereka akan membantu pengguna mempertajam intuisi mereka dan merumuskan pertanyaan yang lebih cerdas. Saya menyerukan pendekatan visualisasi yang lebih bijaksana dan inovatif. Ada prospek nyata di sini untuk memperluas wawasan.
PS dari penerjemah
Baca juga di blog kami:
- «»;
- «»;
- «'.
Sumber: www.habr.com