🖼️ 💲 ✌️ Pencatatan dan penelusuran kueri adalah praktik terbaik. Laporan Yandex 🖕🏽 👏🏽 👨🏿‍🏭

Yandex.Market memiliki arsitektur layanan mikro yang besar. Permintaan peramban dari halaman utama Pasar memunculkan lusinan permintaan tersemat di berbagai layanan (backend) yang dikembangkan oleh orang yang berbeda. Dalam sistem seperti itu, bisa jadi sulit untuk memahami untuk alasan apa permintaan itu jatuh atau butuh waktu lama untuk diproses.

Anatoly Ostrovsky megatolyamenjelaskan bagaimana timnya memecahkan masalah ini, dan berbagi praktik khusus untuk Pasar, tetapi umumnya relevan untuk layanan hebat apa pun. Laporannya didasarkan pada pengalamannya sendiri dalam menempatkan pasar baru dalam waktu yang cukup singkat. Selama beberapa tahun, Tolya memimpin tim pengembangan antarmuka di Pasar, dan sekarang ia telah pindah ke arah kendaraan tak berawak.

- Semua pasar kami dibangun sesuai dengan prinsip-prinsip umum. Ini adalah satu sistem tunggal yang besar. Tetapi jika kita berbicara tentang frontend, maka, dari sudut pandang pengguna, aplikasinya sangat berbeda.

Pada saat yang sama, frontend kami pergi ke banyak backend. Kadang-kadang backend ini mirip satu sama lain (contoh berbeda dari aplikasi yang sama). Dan terkadang mereka unik untuk layanan (penagihan khusus). Struktur sistem semacam itu dapat dianggap sebagai arsitektur layanan mikro klasik.

Selalu ada masalah dalam layanan besar - sulit untuk memahami apa yang sebenarnya terjadi di dalamnya. Atau, misalnya, apa yang terjadi saat kesalahan pembayaran terjadi pada pengguna. Misalkan itu terjadi di tempatnya kemarin, dan hari ini kita perlu memahami apa yang terjadi.

Backend 2 dapat "membakar" baik untuk produk tertentu, atau pada waktu tertentu, atau untuk pengguna tertentu. Kita harus dapat menanggapi situasi apa pun.

Kami memiliki banyak backend, dan, seperti yang saya katakan, mereka dapat berjalan sendiri. Jika ini disajikan dalam bentuk grafik, maka hasilnya akan agak membingungkan. Dalam kehidupan nyata, mungkin ada ratusan layanan mikro. Bayangkan berapa banyak koneksi di antara mereka.

Ada banyak langkah untuk menyelami topik ini. Saya akan berbicara singkat tentang masing-masing dari mereka.

Pertama-tama, sepakati dengan rekan kerja dari backend pada sistem penandaan permintaan yang umum - lebih mudah untuk menemukannya nanti. Selanjutnya, Anda harus dapat mereproduksi masalah dengan cepat. Misalkan terjadi kesalahan pembayaran - cobalah untuk cepat memahami bagaimana itu terjadi dan di mana backend. Menyimpan log tidak hanya dalam file, tetapi juga dalam database sehingga agregasi dapat dilakukan. Dan, tentu saja, bagian penting dari proses ini adalah grafik dan pemantauan. Selanjutnya, secara berurutan.

Sistem identifikasi permintaan terpadu

Ini adalah salah satu alat termudah untuk memahami apa yang terjadi dengan layanan ini. Setuju dengan rekan bahwa, misalnya, frontend Anda menghasilkan beberapa jenis id-request (variabel requestId dalam gambar) dan kemudian melemparkannya ke semua titik akhir dari backend. Dan backend itu sendiri tidak menciptakan kembali apa pun. Dia mengambil requestId yang telah tiba dan meneruskannya lebih lanjut dalam permintaan ke backends-nya. Pada saat yang sama, ia dapat menentukan awalannya, sehingga di antara requestId identik itu akan mungkin untuk menemukan backend khusus ini.

Jadi, ketika Anda melahap log Anda, maka, memastikan bahwa log Anda mengatakan, misalnya, bahwa backend adalah lima ratus, mungkin ada dua opsi. Anda akan memberikan id permintaan ini kepada kolega Anda dan mereka akan melihatnya di log mereka, atau Anda akan melihatnya sendiri.

Semua log kami ditandai dengan id sedemikian sehingga tidak hanya untuk memahami apa yang terjadi dan pada saat apa, tetapi juga untuk menjaga konteks permintaan ini. Ini asinkron, nanti dapat menambahkan sesuatu ke log. Dan jika Anda menggigit pada requestId, tidak ada hal baik yang akan terjadi.

ikal

Untuk mereproduksi masalah, kami menggunakan utilitas cURL. Ini adalah utilitas konsol yang membuat permintaan jaringan - http dan https. cURL mendukung banyak protokol yang berbeda, tetapi ketika melakukan pengembangan web, lebih mudah untuk menganggap bahwa ini adalah alat untuk bekerja dengan permintaan http (s).

Untuk berkenalan dengan tim CURL, Anda dapat pergi ke situs mana pun, lalu pergi ke Jaringan dan menyalin permintaan apa pun dalam bentuk CURL. Hasilnya adalah garis besar:

Jika Anda mencoba mencari tahu, maka tidak ada yang perlu dikhawatirkan. Mari kita coba untuk memisahkannya.

Ini adalah permintaan ke market.yandex.ru.

Agen-Pengguna telah ditambahkan di sini, yang sudah memakan banyak ruang.

Padahal, sisanya adalah cookies. Ada cukup banyak dari mereka dalam kode Yandex. Dalam bentuk serial, mereka memiliki tampilan yang sangat tangguh. Bahkan, tidak ada yang lain selain mereka.

Jadi untuk apa cURL berguna? Jika Anda menyalinnya sendiri dan menjalankannya, Anda akan melihat halaman market.yandex.ru yang sama seperti yang saya lakukan - hanya komputer yang menjalankannya akan berbeda. Tentu saja, beberapa efek samping dapat memberikan perbedaan dalam alamat IP, tetapi secara umum mereka akan menjadi permintaan yang sama. Kami akan mereproduksi skenario yang sama.

Agar tidak menciptakan kueri CURL seperti itu setiap kali, Anda dapat menggunakan ikal format paket-npm.

Dibutuhkan semua parameter permintaan yang biasanya dibutuhkan fungsi - yaitu, dalam hal ini hanya header dan url. Tapi dia juga tahu bagaimana cara query, body, dll. Dan hasilnya hanyalah string dengan permintaan CURL.

Karena itu, semua log kami di lingkungan dev juga berisi permintaan CURL.

Kami bahkan login permintaan CURL backend langsung di browser untuk segera melihat bagaimana kami pergi ke backends kami tanpa melihat konsol browser.

Harap perhatikan bahwa permintaan CURL melibatkan transfer cookie sesi - ini buruk. Jika Anda membuang permintaan CURL kepada saya di market.yandex.ru, maka saya bisa memasuki Pasar Anda dan layanan Yandex lainnya di bawah login Anda. Karenanya, kami tidak menyimpan permintaan semacam itu di mana pun, dan mencatatnya hanya di bangku uji untuk kami sendiri - data tersebut tidak dapat dibocorkan.

Clickhouse

Selanjutnya saya akan berbicara tentang log terstruktur. Di sini saya akan mengingat database ClickHouse tertentu, tetapi Anda dapat memilih salah satunya. ClickHouse adalah DBMS kolumnar, lebih mudah untuk memilih dari sejumlah besar data dan menerima potongan besar data. Baik karena Anda dapat menyimpan sepotong besar log di dalamnya dan kemudian, misalnya, membuat semacam agregasi dari satu miliar catatan.

Dalam hal ini, contoh pilih ClickHouse adalah SQL biasa. Di sini kami menunjukkan jumlah permintaan kode status untuk hari ini.

Akibatnya, kita akan memiliki 180 ribu dua ratus tujuh lima ratus, dan kode status yang tersisa, misalnya, tidak menarik bagi kita. Tapi bagaimana kita bisa menggunakan ini dengan menarik?

Kita dapat mengatakan bahwa rasio dua ratus terhadap rasio jumlah jawaban adalah Indikator Tingkat Layanan, yang menjawab pertanyaan seberapa baik aplikasi kita bekerja dalam hal kode status. Meski sederhana, ia sudah membicarakan sesuatu.

Berdasarkan indikator kami, kami dapat menghasilkan SLI pertama, yaitu, katakanlah, misalnya, bahwa 99% dari permintaan kami harus OK. Dan di sini kita dapat membandingkan bahwa kami melakukan SLI kami. Jika mereka tidak memenuhi, kita bisa mencoba membuat beberapa permintaan terakhir yang mungkin lima ratus, atau hanya hal-hal kritis.

Misalnya, kesalahan pembayaran sangat penting bagi kami, tetapi dalam kasus ini mereka akan mengembalikan nol - untung :)

Bagaimana memastikan bahwa log Anda ada dalam formulir yang mudah digunakan dan dapat diambil melalui SQL?

Ini adalah topik untuk laporan besar yang terpisah, dan semuanya tergantung pada infrastruktur Anda. Tapi sepertinya ada dua cara. Pertama: kirim metadata langsung ke runtime, langsung ke database. Kami melakukannya secara berbeda, dengan cara kedua: kami mengikuti file log dan mengirimkan potongan-potongan baik dalam database atau di tempat perantara.

Ini berfungsi bagi kami agak berlapis-banyak - kami mengirim log dari contoh khusus ke server penyimpanan jarak jauh dari log semacam itu.

Lacak Permintaan

Tidak ada konsep "penelusuran kueri". Istilah ini diciptakan oleh Google.

Jika Anda mencari "penelusuran penelusuran" di Internet, Anda akan melihat perintah traceroute. Mungkin ini mirip dengan penelusuran kueri.

Bahkan ada program konsol, dan di sini saya menjalankannya untuk situs bringly.ru (layanan yang kami kembangkan musim semi lalu). Ini membantu untuk memahami melalui mesin dan server mana permintaan berjalan sebelum sampai ke penyeimbang, yang akan merespon baik dengan tata letak atau oleh sesuatu yang lain.

Inilah penyeimbang kami. Dengan penelusuran kueri, yang kami maksud bukan ini, tetapi semua yang terjadi di dalam penyeimbang kami - bagaimana permintaan tinggal lebih jauh di dalam aplikasi node.js kami.

Kami melihat ini dalam bentuk garis waktu, di mana waktu horizontal ditampilkan, dan urutan vertikal permintaan. Dalam hal ini, kami memiliki permintaan ke kartu produk, di mana dapat dilihat bahwa ini adalah permintaan ke backend dari otorisasi kami. Setelah keputusannya, tiga baris panjang - ini adalah permintaan ke backend utama kami untuk keranjang, kartu produk dan produk sejenis. Jadi kita punya jejak.

Di sini Anda melihat permintaan otorisasi yang sama, dan kemudian backend pergi. Dalam hal ini, backend tidak berperilaku sangat optimal, karena memiliki banyak permintaan berturut-turut ke databasenya. Mungkin, permintaan seperti itu dapat dioptimalkan.

Dan di sini adalah contoh jejak, ketika kami tidak pergi ke backend, tetapi segera memberi status 500. Bagaimana jejak ini berguna bagi kami? Kami tidak perlu mengganggu rekan. Kami memiliki id dari permintaan ini, sehingga kami dapat melihat sendiri log dan mencari tahu apa yang terjadi.

Inilah situasi yang berlawanan. Backend mengatakan bahwa ada sesuatu yang salah dan pada saat yang sama menulis dalam meta-informasi apa yang sebenarnya terjadi - semacam jejak tumpukan muncul.

Bagaimana cara membuat diri Anda menjadi alat yang sama?

Yang paling penting di sini adalah database. Jika Anda memiliki "INSERT INTO" yang paling sederhana dalam database beberapa tindakan dengan layanan ini, nanti Anda setidaknya dapat menggunakan SQL untuk menemukan peristiwa yang diperlukan. Dan jika perlu, Anda dapat membuat antarmuka untuk ini.

Grafik

Ini adalah topik yang sangat menarik, saya tidak akan membahasnya secara rinci hari ini, tentu saja, :)

Mari kita bicara tentang logging. Kami memiliki banyak grafik, kami melihatnya ketika kami meluncurkan sesuatu - dan dalam timing ada suara seperti itu.

Grafik membantu secara visual melihat bahwa ada sesuatu yang salah. Dan kemudian Anda masih perlu melihat log dan mengerti apa yang salah dengan mereka. Dalam hal ini, lonjakan segera setelah rilis setidaknya berarti bahwa rilis seperti itu perlu segera diputar kembali.

Pemantauan

Bagian yang lebih penting dan tingkat perendaman yang lebih kuat dalam topik ini adalah pemantauan. Dengan memantau, saya mengerti, pertama, pemantauan otomatis grafik dan, kedua, aturan otomatis untuk memantau sesuatu.

Kami memantau rasio lima ratus dengan jumlah total tanggapan per menit. Kami juga memantau empat ratus, keberadaan beban pada layanan, memeriksa kenop pemeriksaan kesehatan, yang menarik kenop ping dari masing-masing backend, dll.

Selain itu, kami memiliki dasbor pemantauan yang kami sertakan di layar dekat workstation. Jadi kita langsung melihat mana dari "blush" pemantauan. Sebagai contoh, ini dia salah satu yang utama, di mana frontend dan backend utama kita terlihat. Di sini Anda dapat melihat bahwa beberapa pemantauan menyala di backend. Ini berarti bahwa pada saat itu orang yang bertanggung jawab atas layanan ini akan menerima pesan di Telegram, atau mungkin mereka bahkan akan memanggilnya - itu tergantung pada pengaturan pemantauan.

Ringkasan

Satu requestId akan membantu Anda menemukan masalah dengan lebih mudah dalam layanan yang terdiri dari beberapa aplikasi. CURL yang benar akan memungkinkan Anda mereproduksi masalah dengan lebih akurat dan melihat bagaimana Anda sendiri, misalnya, mengirim data ke backend. Log terstruktur akan memungkinkan Anda membuat SLI, dan lebih nyaman digunakan daripada log teks biasa. Dan jangan lupa untuk mengikuti grafik dan melakukan pemantauan.

Saya sarankan membaca buku Rekayasa Keandalan Situs dari Google jika Anda tertarik pada hal-hal infrastruktur.

Pencatatan dan penelusuran kueri adalah praktik terbaik. Laporan Yandex