🧙 ♑️ 🍌 SRE Observability: Ruang nama dan Struktur Metrik 🤳 🎇 👨🏾‍🌾

Spyglass oleh Shorai-san Ruang

nama metrik terstruktur penting untuk akses cepat ke informasi selama insiden. Rencanakan nama dan dimensi metrik dengan hati-hati untuk mendukung berbagai pertanyaan dan ekstensi. Salah satu cara yang efektif dalam menciptakan model metrik yang fleksibel adalah dengan menganggapnya sebagai pohon.

Ini memberikan beberapa keuntungan: melihat himpunan bagian data tertentu, menentukan metrik dalam hal anak-anaknya dan membangun hubungan antar metrik. Mail.ru Artikel yang diterjemahkan oleh

Tim Solusi Cloud , yang membahas properti ruang nama metrik, yang memungkinkan Anda untuk secara bertahap meningkatkan detail kueri dan berpindah ke himpunan bagian data, serta melihat metrik dari sudut pandang metrik yang dikandungnya. Banyak dari konsep ini yang Anda kenal, karena diimplementasikan dalam solusi pemantauan cloud asli seperti Prometheus dan DogStatsD.

Ruang Nama Metrik dan Strukturnya

Ruang nama metrik adalah ruang konseptual tempat metrik hidup. Mereka sering terbatas pada basis data atau akun:

Metrik namespace juga merupakan struktur metrik dalam namespace. Nama dan struktur yang tepat membuka sejumlah keuntungan besar.

Namespace pada diagram di atas tidak memiliki struktur eksplisit. Setiap metrik terpisah dan independen. Metrik tidak memiliki kesamaan kecuali fakta bahwa mereka ada di namespace yang sama. Dalam struktur yang tidak terkait ini, setiap metrik akan digunakan secara individual. Untuk melihat frekuensi permintaan http untuk layanan, metrik layanan harus diakses langsung - service_N_http_requests_total.

Misalkan kita ingin melihat jumlah total permintaan untuk semua layanan. Apa yang terjadi pada contoh di atas jika kita membuat layanan baru?

Jika jumlah total permintaan dihitung dengan menjumlahkan permintaan ke service_1 dan service_2, maka menambahkan service_3 tidak mengubah jumlah total permintaan. Untuk menghitung jumlah total permintaan yang benar, Anda perlu mengubah aturan penghitungan dengan menambahkan service_3_http_requests_total. Lihatlah grafik jumlah permintaan di bawah ini:

Pohon metrik

Alternatif untuk namespace tanpa struktur adalah menerima struktur eksplisit menggunakan nama metrik sebagai namespace. Dalam diagram di bawah ini, Anda melihat struktur ini sebagai pohon:

Di Prometheus dan Datadog, struktur metrik dibuat menggunakan tag dan tag . Tag memungkinkan Anda membangun pohon secara dinamis: setiap kali layanan baru ditambahkan, ini merujuk ke metrik root.

Di Prometheus, jumlah permintaan per detik untuk semua layanan dapat dilihat dengan membuat permintaan, seperti pada gambar di bawah ini:

Dengan namespace terstruktur, Anda dapat secara dinamis menghitung jumlah kueri di seluruh node. Dalam hal ini, Prometheus menghitung jumlah permintaan per detik untuk setiap layanan sebagai metrik terpisah.

Menentukan Metrik Warisan

Saat menggunakan pohon metrik, setiap dimensi metrik (berlabel "layanan") berisi frekuensi masing-masing permintaan untuk layanan tertentu. Dengan menggunakan namespace metrik, Anda bisa mendapatkan tidak hanya frekuensi total permintaan, tetapi juga frekuensi permintaan untuk setiap layanan:

Menggunakan namespace, Anda dapat memilih dan memvisualisasikan tidak hanya data metrik umum, tetapi juga data bagian metrik umum, dikelompokkan berdasarkan beberapa atribut. Jadi, dalam gambar di atas frekuensi permintaan ke layanan individual terlihat, jumlah mereka memberikan frekuensi permintaan ke node.

Mempersempit sampel - himpunan bagian data

Namespaces juga mendukung penyempitan kueri untuk mengambil subset data tertentu. Sebagai contoh, mari kita ajukan pertanyaan: "Apa penundaan p99 (99% permintaan lebih cepat dari penundaan yang ditentukan) di semua permintaan HTTP yang berhasil untuk server dengan penyebaran kenari?".

Pohon di atas memodelkan konsep namespace dan secara opsional memodelkan bagaimana metrik disimpan pada disk. Dengan menggunakan namespace metrik yang terdefinisi dengan baik, Anda dapat memperluas metrik ke parameter apa pun.

Gambar di bawah ini menunjukkan grafik p99 dan p50 dari pohon metrik di atas:

Jika Anda membuat permintaan yang lebih spesifik, Anda dapat, misalnya, menjawab pertanyaan berikut: "Apa keterlambatan p99 dalam semua permintaan HTTP yang berhasil untuk server dengan penyebaran kenari dalam konteks setiap server?"

Di bawah ini adalah visualisasi metrik dengan pilihan oleh machine_id:

Karena metrik memiliki struktur yang terdefinisi dengan baik, kami dapat memilih data yang diperlukan dari metrik tingkat atas dengan menentukan kriteria pemilihan yang diperlukan - dalam kasus kami, machine_id.

Aturan Peluang

Koefisien adalah cara lain untuk menyusun data (korelasi). Ini adalah mekanisme yang sangat kuat dan dasar untuk menghitung ketersediaan dan tingkat kesalahan SLO (indikator ini dipopulerkan oleh para ahli SRE Google).

Koefisien memungkinkan pengguna akhir untuk secara eksplisit mengaitkan metrik, membangun struktur metrik. Hubungan-hubungan ini paling sering dinyatakan sebagai persentase, yaitu aksesibilitas dapat dihitung sebagai rasio “permintaan yang berhasil / jumlah total permintaan”, dan tingkat kesalahan sebagai “jumlah kesalahan / jumlah total permintaan”. Contoh lain dari koefisien adalah seberapa sering satu negara muncul dari beberapa negara.

Mari kita ilustrasikan ini dan anggap ada aplikasi yang mengeksekusi permintaan, dan permintaan tersebut dapat mengarah ke salah satu dari dua status: data yang diambil dari cache (cache_hit: true) atau data yang diambil dari sumber utama (cache_hit: false). Untuk melihat rasio hit cache, data harus disusun sebagai berikut:

Grafik di bawah ini menunjukkan frekuensi cache hit dan miss. Setiap permintaan masuk atau tidak masuk ke cache. Secara total, sekitar 160 permintaan per detik terjadi:

Grafik berikut menunjukkan rasio hit cache relatif terhadap jumlah total permintaan. Koefisien hit adalah 0,5 (50%):

Jadi, Anda dapat menghubungkan dua metrik apa saja. Dalam Datadog dan Prometheus, hubungan ini diungkapkan oleh operasi aritmatika sederhana.

Pertanyaan dijawab oleh data

Penting untuk memikirkan pertanyaan-pertanyaan yang harus dijawab oleh data. Dalam contoh pertama, pengambilan sampel data tidak dapat menjawab pertanyaan dengan tepat: "Berapa banyak kueri per detik yang diproses semua proses instans?", Tapi pohon namespace akan membantu untuk mendapatkan jawabannya.

Kasus umum lainnya adalah namespace metrik klien dengan nama layanan, dan bukan dengan nama pustaka klien. Menambahkan nama perpustakaan klien ke namespace akan menjawab pertanyaan: "Jumlah total permintaan dari semua klien?".

Pertanyaan umum yang berguna menjawab empat sinyal emas Google . Setiap pertanyaan diajukan secara umum, dan kemudian ditentukan:

Berapa banyak total permintaan semua pelanggan?
Berapa banyak permintaan yang dilakukan setiap klien?
Berapa banyak permintaan yang dilakukan setiap klien untuk setiap node?
Berapa persentase permintaan server yang berhasil untuk setiap RPC?

Strategi yang sama berlaku untuk keterlambatan, tingkat kesalahan dan saturasi sumber daya.

Metrik yang ditandai secara umum

Inilah yang saya baca dalam praktik terbaik untuk optimasi kueri dan penyimpanan data untuk Datadog dan Prometheus.

Untuk mendapatkan tampilan global yang mendukung perincian ke segmen tertentu, mulailah dengan namespace atas umum dan tambahkan tag dan label (mulai dengan yang umum, kemudian tambahkan yang lebih spesifik). Dalam melakukannya, pertimbangkan rekomendasi di bawah ini.

Waspadai kardinalitas

Datadog dan Prometheus merekomendasikan untuk membatasi jumlah tag. Mengutip manual Prometheus :

, , , . , .

, 10. , , . .

, 100 , , .

, node_exporter. . , , node_filesystem_avail. 10 000 , 100 000 node_filesystem_avail, Prometheus.

Jika Anda menambahkan kuota FS per pengguna, Anda akan dengan cepat mencapai puluhan juta deret waktu dari 10.000 pengguna per 10.000 node. Ini terlalu banyak untuk implementasi Prometheus saat ini. Bahkan dengan angka yang lebih rendah, Anda tidak lagi memiliki indikator lain yang berpotensi lebih bermanfaat dalam pemantauan ini.

Mulai tanpa tag dan tambahkan lebih banyak tag dari waktu ke waktu sesuai kebutuhan.

Pemantauan tingkat pengguna yang mudah sering kali lebih baik dicapai melalui penelusuran terdistribusi . Pelacakan terdistribusi memiliki ruang metrik sendiri dan praktik terbaik.

Kesimpulan

Penting untuk memahami pertanyaan apa yang dapat dijawab dengan menyusun metrik. Struktur yang salah menyebabkan kesulitan dalam mendapatkan jawaban. Meskipun penataan ruang metrik tidak rumit, diperlukan perencanaan sebelumnya untuk mendapatkan hasil maksimal dari data.

Ketika masalah muncul, kemampuan untuk memperluas metrik secara manual untuk melihat semua status sangat penting, dan penting bahwa namespace tidak mengganggu ini.

Semoga berhasil!

Apa lagi yang harus dibaca :

SRE Observability: Ruang nama dan Struktur Metrik