🏫 👩🏽‍🤝‍👨🏻 🏸 Thanos - Prometheus Terukur 🧐 🍃 👩🏿‍🤝‍👩🏼

Terjemahan artikel ini disiapkan khusus untuk siswa dari kursus "DevOps Practices and Tools" .

(Fabian Reinartz) — , Go . Prometheus Kubernetes SIG instrumentation. production- SoundCloud CoreOS. Google.

(Bartek Plotka) — Improbable. . Intel, Mesos production- SRE Improbable. . : Golang, open source .

Melihat produk SpatialOS andalan kami, Anda dapat menebak bahwa Improbable membutuhkan infrastruktur cloud global yang sangat dinamis dengan puluhan cluster Kubernetes. Kami adalah salah satu yang pertama menggunakan sistem pemantauan Prometheus . Prometheus mampu melacak jutaan metrik secara waktu nyata dan dilengkapi dengan bahasa permintaan yang kuat untuk mengambil informasi yang diperlukan.

Kesederhanaan dan keandalan Prometheus adalah salah satu keunggulan utamanya. Namun, setelah melewati skala tertentu, kami mengalami beberapa kekurangan. Untuk mengatasi masalah ini, kami mengembangkan Thanos- Sebuah proyek open source yang dibuat oleh Improbable untuk mentransformasi cluster Prometheus yang ada menjadi sistem pemantauan tunggal dengan repositori data historis yang tidak terbatas. Thanos tersedia di github di sini .

Ikuti terus berita terbaru dari Improbable.

Tujuan kami dengan Thanos

Pada skala tertentu, masalah muncul yang melampaui kemampuan Prometheus vanila. Bagaimana cara menyimpan petabytes data historis secara andal dan ekonomis? Bisakah ini dilakukan tanpa mengurangi waktu respons terhadap permintaan? Apakah mungkin untuk mengakses semua metrik yang terletak di server Prometheus yang berbeda dengan satu permintaan API? Apakah mungkin untuk menggabungkan data replikasi yang dikumpulkan menggunakan Prometheus HA?

Untuk mengatasi masalah ini, kami menciptakan Thanos. Bagian berikut menjelaskan bagaimana kami mendekati masalah ini dan menjelaskan tujuan yang kami kejar.

Meminta data dari beberapa instance Prometheus (permintaan global)

Prometheus menawarkan pendekatan fungsional untuk sharding. Bahkan satu server Prometheus menyediakan skalabilitas yang cukup untuk membebaskan pengguna dari kesulitan sharding horizontal di hampir semua kasus penggunaan.

Meskipun ini adalah model penyebaran yang sangat baik, seringkali diperlukan untuk mengakses data pada server Prometheus yang berbeda melalui satu API atau UI - tampilan global. Tentu saja, dimungkinkan untuk menampilkan beberapa permintaan dalam satu panel Grafana, tetapi setiap permintaan hanya dapat dijalankan pada satu server Prometheus. Di sisi lain, dengan Thanos, Anda dapat meminta dan mengumpulkan data dari beberapa server Prometheus, karena semuanya dapat diakses dari satu titik akhir.

Sebelumnya, untuk mendapatkan pandangan global tentang Improbable, kami mengatur instance Prometheus kami menjadi multi-levelFederasi Hirarkis . Ini berarti membuat satu server meta Prometheus yang mengumpulkan sebagian dari metrik dari setiap server daun,

yang terbukti bermasalah, menyulitkan konfigurasi, menambahkan titik potensi kegagalan tambahan dan menerapkan aturan kompleks untuk memberikan titik akhir federasi dengan data yang tepat. Selain itu, federasi semacam ini tidak memungkinkan Anda untuk mendapatkan tampilan global yang nyata, karena tidak semua data dapat diakses dari satu permintaan API.

Terkait erat dengan ini adalah presentasi tunggal data yang dikumpulkan pada server ketersediaan tinggi (HA) Prometheus. Model Prometheus HA secara independen mengumpulkan data dua kali, yang sangat sederhana sehingga tidak bisa lebih sederhana. Namun, menggunakan representasi gabungan dan deduplikasi dari kedua utas akan jauh lebih nyaman.

Tentu saja, ada kebutuhan untuk server Prometheus yang sangat tersedia. Di Improbable, kami benar-benar serius memantau data setiap menit, tetapi memiliki satu instance Prometheus per cluster adalah satu titik kegagalan. Kesalahan konfigurasi atau kegagalan perangkat keras berpotensi menyebabkan hilangnya data penting. Bahkan penerapan sederhana dapat menyebabkan gangguan kecil dalam pengumpulan metrik, karena memulai ulang bisa secara signifikan lebih lama dari interval goresan.

Penyimpanan data historis yang andal

Penyimpanan metrik murah, cepat, dan jangka panjang adalah impian kami (dibagikan oleh sebagian besar pengguna Prometheus). Dalam Improbable, kami dipaksa untuk mengatur periode penyimpanan untuk metrik menjadi sembilan hari (untuk Prometheus 1.8). Ini menambah batasan yang jelas untuk seberapa jauh kita bisa melihat ke belakang.

Prometheus 2.0 lebih baik dalam hal ini, karena jumlah deret waktu tidak lagi memengaruhi kinerja server secara keseluruhan (lihat KubeCon keynote tentang Prometheus 2 ). Namun, Prometheus menyimpan data pada drive lokal. Meskipun kompresi data yang sangat efisien dapat secara signifikan mengurangi penggunaan SSD lokal, masih ada batasan pada jumlah data historis yang disimpan.

Di Improbable, kami juga memperhatikan keandalan, kesederhanaan, dan biaya. Drive lokal yang besar lebih sulit dioperasikan dan dicadangkan. Mereka lebih mahal dan membutuhkan lebih banyak alat cadangan, yang mengarah pada kompleksitas yang tidak perlu.

Downsampling

Segera setelah kami mulai bekerja dengan data historis, kami menyadari bahwa ada kesulitan mendasar dengan O-big yang membuat permintaan menjadi lebih lambat dan lebih lambat jika kami bekerja dengan data selama berminggu-minggu, berbulan-bulan dan bertahun-tahun.

Solusi standar untuk masalah ini adalah downsampling - downsampling sinyal. Dengan downsampling, kami dapat "menurunkan" rentang waktu yang lebih besar dan mempertahankan jumlah sampel yang sama, yang memungkinkan kami mempertahankan responsif terhadap permintaan.

Downsampling data lama merupakan persyaratan yang tak terhindarkan dari solusi penyimpanan jangka panjang dan melampaui vanilla Prometheus.

Tujuan tambahan

Salah satu tujuan awal proyek Thanos adalah untuk berintegrasi mulus dengan instalasi Prometheus yang ada. Tujuan kedua adalah operasi sederhana dengan penghalang masuk minimum. Setiap dependensi harus mudah dipenuhi untuk pengguna kecil dan besar, yang juga menyiratkan biaya dasar yang rendah.

Arsitektur Thanos

Setelah sasaran kami didaftar di bagian sebelumnya, mari kita kerjakan dan lihat bagaimana Thanos memecahkan masalah ini.

Pandangan global

Untuk mendapatkan tampilan global di atas instance Prometheus yang ada, kita perlu mengaitkan satu titik masuk permintaan dengan semua server. Inilah yang dilakukan komponen Thanos Sidecar . Itu ditempatkan di sebelah setiap server Prometheus dan bertindak sebagai proxy, melayani data Prometheus lokal melalui antarmuka gRPC Store, memungkinkan Anda untuk memilih data seri waktu berdasarkan label dan rentang waktu.

Di sisi lain, ada komponen Querier scalable yang dapat dinegaskan secara horizontal yang sedikit lebih dari sekadar menanggapi permintaan PromQL melalui API HTTP Prometheus standar. Komponen Querier, Sidecar, dan Thanos lainnya berkomunikasi melalui protokol gosip .

Saat menerima permintaan, Querier terhubung ke server API Store yang sesuai, yaitu, untuk Sidecar kami, dan menerima data deret waktu dari server Prometheus yang sesuai.
Setelah itu, menggabungkan jawaban dan melakukan permintaan PromQL pada mereka. Querier dapat menggabungkan data terpisah dan duplikat data dari server Prometheus HA.

Ini memecahkan sebagian besar teka-teki kami - menggabungkan data dari server Prometheus yang terisolasi menjadi satu tampilan. Bahkan, Thanos hanya bisa digunakan untuk kesempatan ini. Server Prometheus yang ada tidak perlu melakukan perubahan apa pun!

Umur simpan tidak terbatas!

Namun, cepat atau lambat kami ingin menyimpan data yang melampaui waktu penyimpanan normal Prometheus. Untuk menyimpan data historis, kami telah memilih penyimpanan objek. Ini tersedia secara luas di cloud apa pun, serta di pusat data lokal dan sangat ekonomis. Selain itu, hampir semua penyimpanan objek dapat diakses 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 periode waktu yang tetap dan tidak dapat diubah. Ini sangat nyaman, karena Thanos Sidecar dapat dengan mudah melihat katalog data Prometheus dan, ketika blok baru muncul, masukkan mereka ke dalam ember penyimpanan objek.

Mengunduh ke penyimpanan objek segera setelah menulis ke disk juga memungkinkan Anda menjaga kesederhanaan "pengikis" (Prometheus dan Thanos Sidecar). Yang menyederhanakan dukungan, biaya, dan desain sistem.

Seperti yang Anda lihat, mencadangkan data sangat sederhana. Tapi bagaimana dengan menanyakan data dalam penyimpanan objek?

Komponen Thanos Store bertindak sebagai proksi untuk mengambil data dari penyimpanan objek. Seperti Thanos Sidecar, ia berpartisipasi dalam cluster gosip dan mengimplementasikan API Store. Dengan demikian, Querier yang ada dapat menganggapnya sebagai Sidecar, sebagai sumber data deret waktu lain - tidak diperlukan konfigurasi khusus.

Blok data deret waktu terdiri dari beberapa file besar. Mengunduhnya sesuai permintaan akan sangat tidak efisien, dan caching lokal membutuhkan memori dan ruang disk yang besar.

Sebagai gantinya, Store Gateway tahu bagaimana menangani format penyimpanan Prometheus. Berkat perencana kueri yang pintar dan caching hanya bagian indeks yang diperlukan dari blok, menjadi mungkin untuk mengurangi kueri kompleks ke jumlah minimum permintaan HTTP ke file penyimpanan objek. Dengan demikian, adalah mungkin untuk mengurangi jumlah permintaan sebanyak empat hingga enam urutan besarnya dan mencapai waktu tanggapan yang umumnya sulit dibedakan dari permintaan data pada SSD lokal.

Seperti ditunjukkan pada diagram di atas, Thanos Querier secara signifikan mengurangi biaya permintaan data tunggal dalam penyimpanan objek dengan menggunakan format penyimpanan Prometheus dan menempatkan data terkait secara berdampingan. Dengan menggunakan pendekatan ini, kami dapat menggabungkan banyak permintaan tunggal ke dalam jumlah minimum operasi massal.

Pemadatan dan downsampling

Setelah blok data deret waktu baru berhasil dimuat ke penyimpanan objek, kami menganggapnya sebagai data "historis" yang segera tersedia melalui Store Gateway.

Namun, setelah beberapa saat, blok dari satu sumber (Prometheus dengan Sidecar) menumpuk dan tidak lagi menggunakan potensi pengindeksan penuh. Untuk mengatasi masalah ini, kami memperkenalkan komponen lain yang disebut Compactor. Ini hanya berlaku mekanisme pemadatan Prometheus lokal untuk data historis di toko objek dan dapat dijalankan sebagai pekerjaan batch periodik sederhana.

Berkat kompresi yang efisien, meminta repositori dalam periode waktu yang lama tidak menimbulkan masalah dalam hal ukuran data. Namun, potensi biaya membongkar satu miliar nilai dan menjalankannya melalui pemroses kueri pasti akan mengarah pada peningkatan tajam dalam waktu eksekusi kueri. Di sisi lain, karena ada ratusan titik data per piksel layar, menjadi tidak mungkin untuk bahkan memvisualisasikan data dalam resolusi penuh. Dengan demikian, downsampling tidak hanya mungkin, tetapi tidak akan menyebabkan hilangnya akurasi yang nyata.

Untuk downsampling data, Compactor terus mengumpulkan data dengan resolusi lima menit dan satu jam. Untuk setiap fragmen mentah yang dikodekan menggunakan kompresi TSDB XOR, berbagai jenis data agregat disimpan, seperti min, maks, atau jumlah untuk satu blok. Ini memungkinkan Querier untuk secara otomatis memilih agregat yang sesuai untuk kueri PromQL yang diberikan.

Untuk menggunakan data dengan akurasi yang lebih rendah, pengguna tidak memerlukan konfigurasi khusus. Querier secara otomatis beralih antara resolusi dan data mentah yang berbeda saat pengguna memperbesar dan memperkecil. Jika diinginkan, pengguna dapat mengontrol ini secara langsung melalui parameter "langkah" dalam permintaan.

Karena biaya penyimpanan satu GB kecil, secara default Thanos menyimpan data asli, data dengan resolusi lima menit dan satu jam. Tidak perlu menghapus data asli.

Aturan perekaman

Bahkan dengan aturan perekaman Thanos adalah bagian penting dari tumpukan pemantauan. Mereka mengurangi kompleksitas, latensi dan biaya permintaan. Mereka juga nyaman bagi pengguna untuk mendapatkan data metrik gabungan. Thanos didasarkan pada instance vanilla dari Prometheus, sehingga sangat dapat diterima untuk menyimpan aturan rekaman dan mengingatkan aturan pada server Prometheus yang ada. Namun, dalam beberapa kasus ini mungkin tidak cukup:

Lansiran dan aturan global (misalnya, lansiran ketika layanan tidak dapat digunakan di lebih dari dua dari tiga kluster).
Aturan untuk data di luar penyimpanan lokal.
Keinginan untuk menjaga semua aturan dan waspada 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 Kueri dapat mengakses metrik yang baru dihitung. Kemudian, mereka juga disimpan dalam penyimpanan objek dan tersedia melalui Store Gateway.

Kekuatan Thanos

Thanos cukup fleksibel untuk disesuaikan dengan kebutuhan Anda. Ini sangat berguna saat bermigrasi dari Prometheus sederhana. Mari kita lihat apa yang kita pelajari tentang komponen-komponen Thanos. Inilah cara mentransfer vanilla Prometheus Anda ke dunia "penyimpanan metrik tanpa batas":

Tambahkan Thanos Sidecar ke server Prometheus Anda - misalnya, wadah yang berdekatan di pod Kubernetes.
Perluas beberapa replika Thanos Querier untuk melihat data. Pada titik ini, mudah untuk membuat gosip antara Scraper dan Querier. Gunakan metrik 'thanos_cluster_members' untuk menguji interaksi komponen.

Hanya dua langkah ini yang cukup untuk memberikan pandangan global dan deduplikasi data yang sempurna dari replika Prometheus HA yang potensial! Cukup sambungkan dasbor Anda ke titik akhir HTTP Querier atau gunakan antarmuka UI Thanos secara langsung.

Namun, jika Anda harus mencadangkan metrik dan penyimpanan jangka panjang, Anda harus melakukan tiga langkah lagi:

Buat Bucket AWS S3 atau GCS. Konfigurasikan Sidecar untuk menyalin data ke bucket ini. Sekarang Anda dapat meminimalkan penyimpanan data lokal.
Perluas Store Gateway dan sambungkan ke kluster gosip yang ada. Sekarang Anda dapat mengirim permintaan data dalam cadangan!
Menyebarkan Compactor untuk meningkatkan kinerja kueri dalam jangka waktu lama menggunakan kompaksi dan downsampling.

Jika Anda ingin tahu lebih banyak, jangan ragu untuk melihat contoh kubernet manifes kami dan memulai !

Hanya dalam lima langkah, kami telah mengubah Prometheus menjadi sistem pemantauan yang andal dengan tampilan global, waktu penyimpanan tanpa batas, dan potensi ketersediaan metrik yang tinggi.

Permintaan tarik: kami membutuhkan Anda!

Thanos adalah proyek open source sejak awal. Integrasi yang sempurna dengan Prometheus dan kemampuan untuk menggunakan hanya sebagian dari Thanos menjadikannya pilihan yang sangat baik untuk meningkatkan skala sistem pemantauan tanpa upaya ekstra.

Kami selalu menyambut Permintaan dan Masalah Tarik GitHub. Pada saat yang sama, jangan ragu untuk menghubungi kami melalui Masalah Github atau mengendur Improbable-eng #thanos jika Anda memiliki pertanyaan atau umpan balik, atau ingin berbagi pengalaman Anda! Jika Anda menyukai apa yang kami lakukan di Improbable, jangan ragu untuk menghubungi kami - kami selalu memiliki lowongan !

Pelajari lebih lanjut tentang kursus.

Thanos - Prometheus Terukur