Terjemahan artikel disiapkan khusus untuk mahasiswa kursus tersebut .
adalah pengembang perangkat lunak, fanatik Go, dan pemecah masalah. Ia juga merupakan pengelola Prometheus dan salah satu pendiri instrumentasi Kubernetes SIG. Sebelumnya, dia adalah seorang insinyur produksi di SoundCloud dan memimpin tim pemantauan di CoreOS. Saat ini bekerja di Google.
- Insinyur Infrastruktur di Improbable. Dia tertarik pada teknologi baru dan masalah sistem terdistribusi. Dia memiliki pengalaman pemrograman tingkat rendah di Intel, pengalaman kontributor di Mesos, dan pengalaman produksi SRE kelas dunia di Improbable. Didedikasikan untuk meningkatkan dunia layanan mikro. Tiga kesukaannya: Golang, open source, dan bola voli.
Melihat produk andalan kami, SpatialOS, Anda dapat menebak bahwa Improbable memerlukan infrastruktur cloud berskala global yang sangat dinamis dengan lusinan cluster Kubernetes. Kami adalah salah satu orang pertama yang menggunakan sistem pemantauan . Prometheus mampu melacak jutaan metrik secara real-time dan dilengkapi dengan bahasa kueri canggih yang memungkinkan Anda mengekstrak informasi yang Anda perlukan.
Kesederhanaan dan keandalan Prometheus adalah salah satu keunggulan utamanya. Namun, setelah kami melewati skala tertentu, kami menemui beberapa kelemahan. Untuk mengatasi masalah ini kami telah mengembangkannya adalah proyek sumber terbuka yang dibuat oleh Improbable untuk mengubah kluster Prometheus yang ada menjadi sistem pemantauan tunggal dengan penyimpanan data historis tanpa batas. Thanos tersedia di Github .
Tujuan kami dengan Thanos
Pada skala tertentu, muncul masalah yang berada di luar kemampuan vanilla Prometheus. Bagaimana cara menyimpan data historis berukuran petabyte secara andal dan ekonomis? Bisakah hal ini dilakukan tanpa mengurangi waktu respons? Apakah mungkin untuk mengakses semua metrik yang terletak di server Prometheus berbeda dengan satu permintaan API? Apakah ada cara untuk menggabungkan data replikasi yang dikumpulkan menggunakan Prometheus HA?
Untuk mengatasi masalah ini, kami menciptakan Thanos. Bagian berikut menjelaskan cara kami menangani masalah ini dan menjelaskan tujuan kami.
Membuat kueri data dari beberapa instance Prometheus (kueri global)
Prometheus menawarkan pendekatan fungsional untuk sharding. Bahkan satu server Prometheus memberikan skalabilitas yang cukup untuk membebaskan pengguna dari kerumitan sharding horizontal di hampir semua kasus penggunaan.
Meskipun ini adalah model penerapan yang hebat, sering kali diperlukan akses data pada server Prometheus yang berbeda melalui satu API atau UI - tampilan global. Tentu saja, beberapa kueri dapat ditampilkan dalam satu panel Grafana, tetapi setiap kueri hanya dapat dijalankan di satu server Prometheus. Di sisi lain, dengan Thanos Anda dapat melakukan kueri dan menggabungkan data dari beberapa server Prometheus karena semuanya dapat diakses dari satu titik akhir.
Sebelumnya, untuk mendapatkan tampilan global di Improbable, kami mengatur instance Prometheus kami ke dalam multi-level . Ini berarti membuat satu server meta Prometheus yang mengumpulkan beberapa metrik dari setiap server daun.
Pendekatan ini terbukti bermasalah. Hal ini mengakibatkan konfigurasi yang lebih kompleks, penambahan potensi titik kegagalan tambahan, dan penerapan aturan kompleks untuk memastikan bahwa titik akhir gabungan hanya menerima data yang diperlukan. Selain itu, federasi semacam ini tidak memungkinkan Anda mendapatkan pandangan global yang sebenarnya, karena tidak semua data tersedia dari satu permintaan API.
Terkait erat dengan hal ini adalah tampilan terpadu dari data yang dikumpulkan pada server Prometheus ketersediaan tinggi (HA). Model HA Prometheus secara independen mengumpulkan data dua kali, yang sangat sederhana hingga sangat sederhana. Namun, menggunakan tampilan gabungan dan penghapusan duplikat dari kedua aliran akan jauh lebih nyaman.
Tentu saja, diperlukan server Prometheus dengan ketersediaan tinggi. Di Improbable, kami melakukan pemantauan data menit demi menit dengan sangat serius, namun memiliki satu instance Prometheus per cluster adalah satu titik kegagalan. Kesalahan konfigurasi atau kegagalan perangkat keras apa pun berpotensi menyebabkan hilangnya data penting. Bahkan penerapan sederhana pun dapat menyebabkan gangguan kecil pada pengumpulan metrik karena proses mulai ulang bisa jauh lebih lama dibandingkan interval pengikisan.
Penyimpanan data historis yang andal
Penyimpanan metrik yang murah, cepat, dan berjangka panjang adalah impian kami (dimiliki oleh sebagian besar pengguna Prometheus). Di Improbable, kami terpaksa mengonfigurasi periode retensi metrik menjadi sembilan hari (untuk Prometheus 1.8). Hal ini menambah batasan yang jelas mengenai seberapa jauh kita dapat melihat ke belakang.
Prometheus 2.0 telah ditingkatkan dalam hal ini, karena jumlah deret waktu tidak lagi mempengaruhi kinerja server secara keseluruhan (lihat. ). Namun, Prometheus menyimpan data di disk lokal. Meskipun kompresi data berefisiensi tinggi dapat mengurangi penggunaan SSD lokal secara signifikan, pada akhirnya masih ada batasan jumlah data historis yang dapat disimpan.
Selain itu, di Improbable kami peduli dengan keandalan, kesederhanaan, dan biaya. Disk lokal yang besar lebih sulit dioperasikan dan dicadangkan. Biayanya lebih mahal dan memerlukan lebih banyak alat cadangan, sehingga menimbulkan kerumitan yang tidak perlu.
Pengambilan sampel yang lebih rendah
Setelah kami mulai bekerja dengan data historis, kami menyadari bahwa ada kesulitan mendasar dengan big-O yang membuat kueri semakin lambat saat kami bekerja dengan data berminggu-minggu, berbulan-bulan, dan bertahun-tahun.
Solusi standar untuk masalah ini adalah (downsampling) - mengurangi frekuensi sampling sinyal. Dengan downsampling, kami dapat “menurunkan skala” ke rentang waktu yang lebih besar dan mempertahankan jumlah sampel yang sama, sehingga kueri tetap responsif.
Downsampling data lama merupakan persyaratan yang tidak dapat dihindari dalam solusi penyimpanan jangka panjang apa pun dan berada di luar cakupan vanilla Prometheus.
Tujuan tambahan
Salah satu tujuan awal proyek Thanos adalah untuk berintegrasi secara mulus dengan instalasi Prometheus yang ada. Tujuan kedua adalah kemudahan pengoperasian dengan hambatan masuk yang minimal. Ketergantungan apa pun harus mudah dipenuhi baik bagi pengguna kecil maupun besar, yang juga berarti biaya dasar yang rendah.
Arsitektur Thanos
Setelah mencantumkan tujuan kita di bagian sebelumnya, mari kita selesaikan dan lihat bagaimana Thanos memecahkan masalah ini.
Tampilan global
Untuk mendapatkan gambaran global mengenai instance Prometheus yang ada, kita perlu menautkan satu titik masuk permintaan ke semua server. Inilah yang dilakukan komponen Thanos. . Ini diterapkan di samping setiap server Prometheus dan bertindak sebagai proxy, menyajikan data Prometheus lokal melalui gRPC Store API, memungkinkan data rangkaian waktu diambil berdasarkan tag dan rentang waktu.
Di sisi lain adalah komponen Querier tanpa kewarganegaraan yang diperluas skalanya, yang tidak lebih dari sekadar menjawab pertanyaan PromQL melalui API HTTP Prometheus standar. Querier, Sidecar, dan komponen Thanos lainnya berkomunikasi melalui .
- Querier, setelah menerima permintaan, terhubung ke server Store API yang sesuai, yaitu ke Sidecars kami dan menerima data deret waktu dari server Prometheus yang sesuai.
- Setelah itu, ia menggabungkan respons dan mengeksekusi kueri PromQL pada respons tersebut. Querier dapat menggabungkan data yang terpisah dan data duplikat dari server Prometheus HA.
Ini memecahkan sebagian besar teka-teki kami - menggabungkan data dari server Prometheus yang terisolasi ke dalam satu tampilan. Faktanya, Thanos hanya bisa digunakan untuk fitur ini. Tidak ada perubahan yang perlu dilakukan pada server Prometheus yang ada!
Umur simpan tidak terbatas!
Namun, cepat atau lambat kami ingin menyimpan data melebihi waktu retensi Prometheus normal. Kami memilih penyimpanan objek untuk menyimpan data historis. Ini tersedia secara luas di cloud mana pun serta pusat data lokal dan sangat hemat biaya. Selain itu, hampir semua penyimpanan objek tersedia melalui S3 API yang terkenal.
Prometheus menulis data dari RAM ke disk kira-kira setiap dua jam. Blok data yang disimpan berisi semua data untuk jangka waktu tertentu dan tidak dapat diubah. Ini sangat nyaman karena Thanos Sidecar cukup melihat direktori data Prometheus dan, saat blok baru tersedia, memuatnya ke dalam keranjang penyimpanan objek.
Memuat ke penyimpanan objek segera setelah menulis ke disk juga memungkinkan Anda menjaga kesederhanaan scraper (Prometheus dan Thanos Sidecar). Yang menyederhanakan dukungan, biaya dan desain sistem.
Seperti yang Anda lihat, pencadangan data sangat sederhana. Tapi bagaimana dengan menanyakan data di penyimpanan objek?
Komponen Thanos Store bertindak sebagai proxy untuk mengambil data dari objek penyimpanan. Seperti Thanos Sidecar, ia berpartisipasi dalam kelompok gosip dan mengimplementasikan Store API. Dengan cara ini, Querier yang ada dapat memperlakukannya seperti Sidecar, sebagai sumber data deret waktu lainnya - tidak diperlukan konfigurasi khusus.
Blok data deret waktu terdiri dari beberapa file besar. Memuatnya sesuai permintaan akan sangat tidak efisien, dan menyimpannya secara lokal akan memerlukan sejumlah besar memori dan ruang disk.
Sebaliknya, Store Gateway mengetahui cara menangani format penyimpanan Prometheus. Berkat penjadwal kueri yang cerdas dan hanya menyimpan bagian indeks blok yang diperlukan dalam cache, kueri kompleks dapat dikurangi ke jumlah minimum permintaan HTTP ke file penyimpanan objek. Dengan cara ini, Anda dapat mengurangi jumlah permintaan sebanyak empat hingga enam kali lipat dan mencapai waktu respons yang umumnya sulit dibedakan dari permintaan data pada SSD lokal.
Seperti yang ditunjukkan dalam diagram di atas, Thanos Querier secara signifikan mengurangi biaya per kueri data penyimpanan objek dengan memanfaatkan format penyimpanan Prometheus dan menempatkan data terkait secara berdampingan. Dengan menggunakan pendekatan ini, kita dapat menggabungkan banyak permintaan tunggal ke dalam jumlah minimum operasi massal.
Pemadatan dan downsampling
Setelah blok data deret waktu baru berhasil dimuat ke dalam penyimpanan objek, kami memperlakukannya sebagai data “historis”, yang segera tersedia melalui Store Gateway.
Namun, setelah beberapa waktu, blok dari satu sumber (Prometheus dengan Sidecar) terakumulasi dan tidak lagi menggunakan potensi pengindeksan penuh. Untuk mengatasi masalah ini, kami memperkenalkan komponen lain yang disebut Compactor. Ini hanya menerapkan mesin pemadatan lokal Prometheus ke data historis dalam penyimpanan objek dan dapat dijalankan sebagai pekerjaan batch periodik sederhana.
Berkat kompresi yang efisien, menanyakan penyimpanan dalam jangka waktu yang lama tidak menimbulkan masalah dalam hal ukuran data. Namun, potensi biaya untuk membongkar satu miliar nilai dan menjalankannya melalui pemroses kueri pasti akan mengakibatkan peningkatan waktu eksekusi kueri yang dramatis. Di sisi lain, karena terdapat ratusan titik data per piksel di layar, memvisualisasikan data pada resolusi penuh menjadi mustahil. Dengan demikian, downsampling tidak hanya mungkin dilakukan, tetapi juga tidak akan menyebabkan hilangnya akurasi secara nyata.
Untuk mengurangi sampel data, Compactor terus mengumpulkan data dengan resolusi lima menit dan satu jam. Untuk setiap potongan mentah yang dikodekan menggunakan kompresi TSDB XOR, berbagai jenis data agregat disimpan, seperti min, maks, atau jumlah untuk satu blok. Hal ini memungkinkan Querier untuk secara otomatis memilih agregat yang sesuai untuk kueri PromQL tertentu.
Tidak diperlukan konfigurasi khusus bagi pengguna untuk menggunakan data presisi rendah. Querier secara otomatis beralih antara resolusi yang berbeda dan data mentah saat pengguna memperbesar dan memperkecil. Jika diinginkan, pengguna dapat mengontrolnya secara langsung melalui parameter “langkah” dalam permintaan.
Karena biaya penyimpanan satu GB rendah, secara default Thanos menyimpan data mentah, data resolusi lima menit dan satu jam. Tidak perlu menghapus data asli.
Aturan pencatatan
Bahkan dengan Thanos, aturan pencatatan adalah bagian penting dari tumpukan pemantauan. Mereka mengurangi kompleksitas, latensi, dan biaya kueri. Mereka juga memudahkan pengguna untuk memperoleh data gabungan berdasarkan metrik. Thanos didasarkan pada instance vanilla Prometheus, jadi menyimpan aturan pencatatan dan aturan peringatan di server Prometheus yang ada dapat diterima. Namun, dalam beberapa kasus, hal ini mungkin tidak cukup:
- Peringatan dan aturan global (misalnya, peringatan ketika suatu layanan tidak berfungsi di lebih dari dua dari tiga klaster).
- Aturan untuk data di luar penyimpanan lokal.
- Keinginan untuk menyimpan semua aturan dan peringatan di satu tempat.
Untuk semua kasus ini, Thanos menyertakan komponen terpisah yang disebut Ruler, yang menghitung aturan dan peringatan melalui Kueri Thanos. Dengan menyediakan StoreAPI yang terkenal, node Query dapat mengakses metrik yang baru dihitung. Nantinya juga disimpan di penyimpanan objek dan tersedia melalui Store Gateway.
Kekuatan Thanos
Thanos cukup fleksibel untuk disesuaikan dengan kebutuhan Anda. Ini sangat berguna ketika bermigrasi dari Prometheus biasa. Mari kita rekap dengan cepat apa yang telah kita pelajari tentang komponen Thanos dengan contoh singkat. Berikut cara membawa vanilla Prometheus Anda ke dunia “penyimpanan metrik tak terbatas”:
- Tambahkan Thanos Sidecar ke server Prometheus Anda - misalnya, container sidecar di pod Kubernetes.
- Terapkan beberapa replika Thanos Querier agar dapat melihat data. Pada tahap ini mudah untuk mengatur gosip antara Scraper dan Querier. Untuk memeriksa interaksi komponen, gunakan metrik 'thanos_cluster_members'.
Dua langkah ini saja sudah cukup untuk memberikan tampilan global dan deduplikasi data yang lancar dari potensi replika Prometheus HA! Cukup sambungkan dasbor Anda ke titik akhir HTTP Querier atau gunakan UI Thanos secara langsung.
Namun, jika Anda memerlukan cadangan metrik dan penyimpanan jangka panjang, Anda perlu menyelesaikan tiga langkah lagi:
- Buat bucket AWS S3 atau GCS. Konfigurasikan Sidecar untuk menyalin data ke bucket ini. Penyimpanan data lokal kini dapat diminimalkan.
- Terapkan Store Gateway dan sambungkan ke cluster gosip Anda yang ada. Sekarang Anda dapat menanyakan data yang dicadangkan!
- Terapkan Compactor untuk meningkatkan efisiensi kueri dalam jangka waktu lama menggunakan pemadatan dan downsampling.
Jika Anda ingin tahu lebih banyak, jangan ragu untuk melihat kami и !
Hanya dalam lima langkah, kami mengubah Prometheus menjadi sistem pemantauan yang andal dengan tampilan global, waktu penyimpanan tak terbatas, dan potensi ketersediaan metrik yang tinggi.
Tarik permintaan: kami membutuhkan Anda!
telah menjadi proyek sumber terbuka sejak awal. Integrasi yang mulus dengan Prometheus dan kemampuan untuk menggunakan hanya sebagian dari Thanos menjadikannya pilihan yang sangat baik untuk menskalakan sistem pemantauan Anda dengan mudah.
Kami selalu menyambut Permintaan dan Masalah GitHub Pull. Sementara itu, jangan ragu untuk menghubungi kami melalui Masalah Github atau slackjika Anda memiliki pertanyaan atau masukan, atau ingin berbagi pengalaman Anda menggunakannya! Jika Anda menyukai apa yang kami lakukan di Improbable, jangan ragu untuk menghubungi kami - !
Sumber: www.habr.com