Terjemahan artikel disediakan khusus untuk pelajar kursus tersebut .
ialah pembangun perisian, fanatik Go, dan penyelesai masalah. Beliau juga merupakan penyelenggara Prometheus dan pengasas bersama instrumentasi Kubernetes SIG. Pada masa lalu, beliau adalah seorang jurutera pengeluaran di SoundCloud dan mengetuai pasukan pemantauan di CoreOS. Pada masa ini bekerja di Google.
- Jurutera Infrastruktur di Improbable. Dia berminat dengan teknologi baru dan masalah sistem teragih. Beliau mempunyai pengalaman pengaturcaraan peringkat rendah di Intel, pengalaman penyumbang di Mesos, dan pengalaman pengeluaran SRE bertaraf dunia di Improbable. Berdedikasi untuk menambah baik dunia perkhidmatan mikro. Tiga kegemarannya: Golang, sumber terbuka dan bola tampar.
Melihat kepada produk utama kami SpatialOS, anda boleh meneka bahawa Improbable memerlukan infrastruktur awan berskala global yang sangat dinamik dengan berpuluh-puluh gugusan Kubernetes. Kami adalah antara yang pertama menggunakan sistem pemantauan . Prometheus mampu menjejak berjuta-juta metrik dalam masa nyata dan dilengkapi dengan bahasa pertanyaan yang berkuasa yang membolehkan anda mengekstrak maklumat yang anda perlukan.
Kesederhanaan dan kebolehpercayaan Prometheus adalah salah satu kelebihan utamanya. Walau bagaimanapun, apabila kami melepasi skala tertentu, kami menghadapi beberapa kelemahan. Untuk menyelesaikan masalah ini kami telah membangunkan ialah projek sumber terbuka yang dicipta oleh Improbable untuk mengubah kluster Prometheus sedia ada dengan lancar kepada sistem pemantauan tunggal dengan storan data sejarah tanpa had. Thanos tersedia di Github .
Matlamat kami dengan Thanos
Pada skala tertentu, timbul masalah yang di luar kemampuan vanila Prometheus. Bagaimana untuk menyimpan petabyte data sejarah dengan andal dan ekonomik? Bolehkah ini dilakukan tanpa menjejaskan masa tindak balas? Adakah mungkin untuk mengakses semua metrik yang terletak pada pelayan Prometheus yang berbeza dengan satu permintaan API? Adakah terdapat cara untuk menggabungkan data replika yang dikumpul menggunakan Prometheus HA?
Untuk menangani isu ini, kami mencipta Thanos. Bahagian berikut menerangkan cara kami menangani isu ini dan menerangkan matlamat kami.
Menyoal data daripada berbilang kejadian Prometheus (pertanyaan global)
Prometheus menawarkan pendekatan berfungsi untuk sharding. Malah satu pelayan Prometheus menyediakan skalabiliti yang mencukupi untuk membebaskan pengguna daripada kerumitan sharding mendatar dalam hampir semua kes penggunaan.
Walaupun ini adalah model penggunaan yang hebat, selalunya perlu untuk mengakses data pada pelayan Prometheus yang berbeza melalui satu API atau UI - paparan global. Sudah tentu, adalah mungkin untuk memaparkan berbilang pertanyaan dalam satu panel Grafana, tetapi setiap pertanyaan hanya boleh dilaksanakan pada satu pelayan Prometheus. Sebaliknya, dengan Thanos anda boleh bertanya dan mengagregat data daripada berbilang pelayan Prometheus kerana semuanya boleh diakses dari satu titik akhir.
Sebelum ini, untuk mendapatkan pandangan global dalam Improbable, kami menyusun contoh Prometheus kami ke dalam pelbagai peringkat . Ini bermakna mencipta satu pelayan meta Prometheus yang mengumpulkan beberapa metrik daripada setiap pelayan daun.
Pendekatan ini terbukti bermasalah. Ini telah menghasilkan konfigurasi yang lebih kompleks, penambahan titik potensi kegagalan tambahan dan penggunaan peraturan yang kompleks untuk memastikan titik akhir bersekutu hanya menerima data yang diperlukannya. Di samping itu, persekutuan jenis ini tidak membenarkan anda mendapatkan pandangan global yang sebenar, kerana tidak semua data tersedia daripada satu permintaan API.
Berkait rapat dengan ini ialah pandangan bersatu data yang dikumpul pada pelayan Prometheus ketersediaan tinggi (HA). Model HA Prometheus secara bebas mengumpul data dua kali, yang sangat mudah ia tidak boleh menjadi lebih mudah. Walau bagaimanapun, menggunakan paparan gabungan dan penduaan kedua-dua aliran akan menjadi lebih mudah.
Sudah tentu, terdapat keperluan untuk pelayan Prometheus yang sangat tersedia. Di Improbable, kami mengambil pemantauan data minit demi minit dengan sangat serius, tetapi mempunyai satu contoh Prometheus bagi setiap kluster adalah satu titik kegagalan. Sebarang ralat konfigurasi atau kegagalan perkakasan berpotensi menyebabkan kehilangan data penting. Malah penggunaan mudah boleh menyebabkan gangguan kecil dalam pengumpulan metrik kerana permulaan semula boleh menjadi lebih lama daripada selang pengikisan.
Penyimpanan data sejarah yang boleh dipercayai
Storan metrik yang murah, pantas dan jangka panjang adalah impian kami (dikongsi oleh kebanyakan pengguna Prometheus). Dalam Improbable, kami terpaksa mengkonfigurasi tempoh pengekalan metrik kepada sembilan hari (untuk Prometheus 1.8). Ini menambah had yang jelas kepada sejauh mana kita boleh melihat ke belakang.
Prometheus 2.0 telah bertambah baik dalam hal ini, kerana bilangan siri masa tidak lagi mempengaruhi prestasi keseluruhan pelayan (lihat. ). Walau bagaimanapun, Prometheus menyimpan data pada cakera tempatan. Walaupun pemampatan data berkecekapan tinggi boleh mengurangkan penggunaan SSD tempatan dengan ketara, pada akhirnya masih terdapat had kepada jumlah data sejarah yang boleh disimpan.
Selain itu, di Improbable kami mementingkan kebolehpercayaan, kesederhanaan dan kos. Cakera tempatan yang besar lebih sukar untuk dikendalikan dan disandarkan. Kosnya lebih tinggi dan memerlukan lebih banyak alat sandaran, mengakibatkan kerumitan yang tidak perlu.
Pensampelan rendah
Sebaik sahaja kami mula bekerja dengan data sejarah, kami menyedari bahawa terdapat kesukaran asas dengan big-O yang menjadikan pertanyaan lebih perlahan dan lebih perlahan semasa kami bekerja dengan minggu, bulan dan tahun data.
Penyelesaian standard untuk masalah ini ialah (downsampling) - mengurangkan kekerapan pensampelan isyarat. Dengan pensampelan rendah, kami boleh "mengurangkan" kepada julat masa yang lebih besar dan mengekalkan bilangan sampel yang sama, memastikan pertanyaan responsif.
Penurunan data lama adalah keperluan yang tidak dapat dielakkan bagi sebarang penyelesaian penyimpanan jangka panjang dan berada di luar skop vanilla Prometheus.
Matlamat tambahan
Salah satu matlamat asal projek Thanos adalah untuk menyepadukan dengan lancar dengan mana-mana pemasangan Prometheus sedia ada. Matlamat kedua ialah kemudahan operasi dengan halangan minimum untuk masuk. Sebarang kebergantungan harus berpuas hati dengan mudah untuk pengguna kecil dan besar, yang juga bermakna kos asas yang rendah.
seni bina Thanos
Selepas menyenaraikan matlamat kami dalam bahagian sebelumnya, mari kita selesaikannya dan lihat bagaimana Thanos menyelesaikan masalah ini.
Pandangan global
Untuk mendapatkan pandangan global di atas contoh Prometheus sedia ada, kami perlu memautkan satu titik masuk permintaan ke semua pelayan. Inilah yang dilakukan oleh komponen Thanos. . Ia digunakan di sebelah setiap pelayan Prometheus dan bertindak sebagai proksi, menyampaikan data Prometheus tempatan melalui API Gedung gRPC, membenarkan data siri masa diambil mengikut teg dan julat masa.
Di sisi lain ialah komponen Querier tanpa kewarganegaraan skala-keluar, yang tidak sekadar menjawab pertanyaan PromQL melalui API HTTP Prometheus standard. Querier, Sidecar dan komponen Thanos lain berkomunikasi melalui .
- Querier, apabila menerima permintaan, menyambung ke pelayan API Gedung yang sepadan, iaitu, ke Sidecars kami dan menerima data siri masa daripada pelayan Prometheus yang sepadan.
- Selepas itu, ia menggabungkan respons dan melaksanakan pertanyaan PromQL pada mereka. Querier boleh menggabungkan kedua-dua data terputus-putus dan data pendua daripada pelayan Prometheus HA.
Ini menyelesaikan sebahagian besar teka-teki kami - menggabungkan data daripada pelayan Prometheus terpencil ke dalam satu paparan. Malah, Thanos hanya boleh digunakan untuk ciri ini. Tiada perubahan perlu dibuat pada pelayan Prometheus sedia ada!
Jangka hayat tanpa had!
Walau bagaimanapun, lambat laun kami akan mahu menyimpan data melebihi masa pengekalan Prometheus biasa. Kami memilih storan objek untuk menyimpan data sejarah. Ia tersedia secara meluas di mana-mana awan serta pusat data di premis dan sangat menjimatkan kos. Di samping itu, hampir semua storan objek tersedia melalui API S3 yang terkenal.
Prometheus menulis data dari RAM ke cakera kira-kira setiap dua jam. Blok data yang disimpan mengandungi semua data untuk tempoh masa yang tetap dan tidak boleh diubah. Ini sangat mudah kerana Thanos Sidecar hanya boleh melihat direktori data Prometheus dan, apabila blok baharu tersedia, memuatkannya ke dalam baldi storan objek.
Memuatkan ke dalam storan objek serta-merta selepas menulis ke cakera juga membolehkan anda mengekalkan kesederhanaan pengikis (Prometheus dan Thanos Sidecar). Yang memudahkan sokongan, kos dan reka bentuk sistem.
Seperti yang anda lihat, sandaran data adalah sangat mudah. Tetapi bagaimana pula dengan pertanyaan data dalam storan objek?
Komponen Kedai Thanos bertindak sebagai proksi untuk mendapatkan semula data daripada storan objek. Seperti Thanos Sidecar, ia mengambil bahagian dalam kelompok gosip dan melaksanakan Store API. Dengan cara ini, Querier sedia ada boleh menganggapnya seperti Sidecar, sebagai satu lagi sumber data siri masa - tiada konfigurasi khas diperlukan.
Blok data siri masa terdiri daripada beberapa fail besar. Memuatkannya atas permintaan akan menjadi agak tidak cekap, dan menyimpannya secara tempatan memerlukan sejumlah besar memori dan ruang cakera.
Sebaliknya, Store Gateway tahu cara mengendalikan format storan Prometheus. Terima kasih kepada penjadual pertanyaan pintar dan caching hanya bahagian indeks yang diperlukan bagi blok, adalah mungkin untuk mengurangkan pertanyaan kompleks kepada bilangan minimum permintaan HTTP untuk objek storan fail. Dengan cara ini, anda boleh mengurangkan bilangan permintaan sebanyak empat hingga enam urutan magnitud dan mencapai masa tindak balas yang biasanya sukar untuk dibezakan daripada permintaan kepada data pada SSD tempatan.
Seperti yang ditunjukkan dalam rajah di atas, Thanos Querier mengurangkan kos setiap pertanyaan data storan objek dengan ketara dengan memanfaatkan format storan Prometheus dan meletakkan data berkaitan bersebelahan. Menggunakan pendekatan ini, kami boleh menggabungkan banyak permintaan tunggal ke dalam bilangan minimum operasi pukal.
Pemadatan dan pensampelan rendah
Setelah blok data siri masa baharu berjaya dimuatkan ke dalam storan objek, kami menganggapnya sebagai data "sejarah", yang tersedia serta-merta melalui Gerbang Gedung.
Walau bagaimanapun, selepas beberapa lama, sekatan daripada satu sumber (Prometheus dengan Sidecar) terkumpul dan tidak lagi menggunakan potensi pengindeksan penuh. Untuk menyelesaikan masalah ini, kami memperkenalkan komponen lain yang dipanggil Compactor. Ia hanya menggunakan enjin pemadatan tempatan Prometheus kepada data sejarah dalam storan objek dan boleh dijalankan sebagai kerja kelompok berkala yang mudah.
Terima kasih kepada pemampatan yang cekap, menanyakan storan dalam tempoh masa yang lama tidak menimbulkan masalah dari segi saiz data. Walau bagaimanapun, potensi kos untuk membongkar satu bilion nilai dan menjalankannya melalui pemproses pertanyaan pasti akan mengakibatkan peningkatan dramatik dalam masa pelaksanaan pertanyaan. Sebaliknya, memandangkan terdapat beratus-ratus titik data setiap piksel pada skrin, menjadi mustahil untuk memvisualisasikan data pada resolusi penuh. Oleh itu, pensampelan rendah bukan sahaja mungkin, tetapi juga tidak akan membawa kepada kehilangan ketepatan yang ketara.
Untuk mengurangkan sampel data, Compactor mengagregatkan data secara berterusan pada resolusi lima minit dan satu jam. Untuk setiap bahagian mentah yang dikodkan menggunakan pemampatan TSDB XOR, jenis data agregat yang berbeza disimpan, seperti min, maks atau jumlah untuk satu blok. Ini membolehkan Querier memilih agregat secara automatik yang sesuai untuk pertanyaan PromQL tertentu.
Tiada konfigurasi khas diperlukan untuk pengguna menggunakan data ketepatan yang dikurangkan. Querier bertukar secara automatik antara resolusi yang berbeza dan data mentah apabila pengguna mengezum masuk dan keluar. Jika dikehendaki, pengguna boleh mengawal ini secara langsung melalui parameter "langkah" dalam permintaan.
Memandangkan kos menyimpan satu GB adalah rendah, secara lalai Thanos menyimpan data mentah, data resolusi lima minit dan satu jam. Tidak perlu memadam data asal.
Peraturan rakaman
Walaupun dengan Thanos, peraturan rakaman adalah bahagian penting dalam timbunan pemantauan. Mereka mengurangkan kerumitan, kependaman dan kos pertanyaan. Ia juga memudahkan pengguna mendapatkan data agregat mengikut metrik. Thanos adalah berdasarkan contoh vanila Prometheus, jadi ia boleh diterima dengan sempurna untuk menyimpan peraturan rakaman dan peraturan amaran pada pelayan Prometheus sedia ada. Walau bagaimanapun, dalam beberapa kes ini mungkin tidak mencukupi:
- Amaran dan peraturan global (contohnya, amaran apabila perkhidmatan tidak berfungsi pada lebih daripada dua daripada tiga kelompok).
- Peraturan untuk data di luar storan tempatan.
- Keinginan untuk menyimpan semua peraturan dan makluman di satu tempat.
Untuk semua kes ini, Thanos menyertakan komponen berasingan yang dipanggil Ruler, yang mengira peraturan dan makluman melalui Pertanyaan Thanos. Dengan menyediakan StoreAPI yang terkenal, nod Pertanyaan boleh mengakses metrik yang baru dikira. Kemudian mereka juga disimpan dalam storan objek dan disediakan melalui Gerbang Kedai.
Kuasa Thanos
Thanos cukup fleksibel untuk disesuaikan mengikut keperluan anda. Ini amat berguna apabila berhijrah dari Prometheus biasa. Mari kita imbas semula dengan cepat perkara yang telah kita pelajari tentang komponen Thanos dengan contoh pantas. Berikut ialah cara untuk membawa Prometheus vanila anda ke dalam dunia "storan metrik tanpa had":
- Tambahkan Thanos Sidecar pada pelayan Prometheus anda - contohnya, bekas kereta sampingan dalam pod Kubernetes.
- Gunakan berbilang replika Thanos Querier untuk dapat melihat data. Pada peringkat ini adalah mudah untuk menyediakan gosip antara Scraper dan Querier. Untuk menyemak interaksi komponen, gunakan metrik 'thanos_cluster_members'.
Hanya dua langkah ini sudah cukup untuk memberikan paparan global dan penyahduplikasian data yang lancar daripada replika Prometheus HA yang berpotensi! Hanya sambungkan papan pemuka anda ke titik akhir HTTP Querier atau gunakan UI Thanos secara langsung.
Walau bagaimanapun, jika anda memerlukan sandaran metrik dan storan jangka panjang, anda perlu melengkapkan tiga langkah lagi:
- Buat baldi AWS S3 atau GCS. Konfigurasikan Sidecar untuk menyalin data ke baldi ini. Storan data tempatan kini boleh diminimumkan.
- Gunakan Gerbang Kedai dan sambungkannya ke kelompok gosip sedia ada anda. Kini anda boleh menanyakan data yang disandarkan!
- Gunakan Compactor untuk meningkatkan kecekapan pertanyaan dalam jangka masa yang panjang menggunakan pemadatan dan pensampelan turun.
Jika anda ingin mengetahui lebih lanjut, jangan teragak-agak untuk melihat kami ΠΈ !
Hanya dalam lima langkah, kami menjadikan Prometheus sebagai sistem pemantauan yang boleh dipercayai dengan paparan global, masa penyimpanan tanpa had dan potensi ketersediaan metrik yang tinggi.
Permintaan tarik: kami memerlukan anda!
telah menjadi projek sumber terbuka sejak awal lagi. Penyepaduan yang lancar dengan Prometheus dan keupayaan untuk menggunakan hanya sebahagian daripada Thanos menjadikannya pilihan yang sangat baik untuk menskalakan sistem pemantauan anda dengan mudah.
Kami sentiasa mengalu-alukan Permintaan dan Isu Tarik GitHub. Sementara itu, sila hubungi kami melalui Isu Github atau slackjika anda mempunyai soalan atau maklum balas, atau ingin berkongsi pengalaman anda menggunakannya! Jika anda menyukai apa yang kami lakukan di Improbable, jangan teragak-agak untuk menghubungi kami - !
Sumber: www.habr.com