Hai semua. Di bawah ialah transkrip .
– sistem pemantauan untuk pelbagai sistem dan perkhidmatan, dengan bantuan pentadbir sistem boleh mengumpul maklumat tentang parameter semasa sistem dan menyediakan makluman untuk menerima pemberitahuan tentang penyelewengan dalam pengendalian sistem.
Laporan itu akan merangkumi perbandingan и — projek untuk penyimpanan jangka panjang metrik Prometheus.
Pertama, saya akan memberitahu anda tentang Prometheus. Ini ialah sistem pemantauan yang mengumpul metrik daripada sasaran yang ditentukan dan menyimpannya ke storan setempat. Prometheus boleh merekodkan metrik ke storan jauh dan boleh menjana makluman dan peraturan rakaman.
Had Prometheus:
- Ia tidak mempunyai paparan pertanyaan global. Ini adalah apabila anda mempunyai beberapa contoh bebas prometheus. Mereka mengumpul metrik. Dan anda ingin bertanya di atas semua metrik ini yang dikumpulkan daripada kejadian prometheus yang berbeza. Prometheus tidak membenarkan ini.
- Dengan prometheus, prestasi terhad kepada hanya satu pelayan. Prometheus tidak membuat skala secara automatik merentas berbilang pelayan. Anda hanya boleh membahagikan sasaran anda secara manual antara berbilang Prometheus.
- Skop metrik dalam Prometheus dihadkan kepada hanya satu pelayan atas sebab yang sama bahawa ia tidak boleh menskalakan secara automatik merentas berbilang pelayan.
- Tidak begitu mudah untuk mengatur keselamatan data di Prometheus.
Penyelesaian kepada masalah/cabaran ini?
Penyelesaiannya ialah:
Semua penyelesaian ini adalah untuk penyimpanan jauh data yang dikumpul oleh Prometheus. Mereka menyelesaikan masalah penyimpanan jauh dari slaid sebelumnya dengan cara yang berbeza. Dalam pembentangan ini saya hanya akan bercakap tentang dua penyelesaian pertama: и .
Untuk pertama kalinya maklumat tentang muncul oleh . Seni bina diterangkan di sana dan bagaimana ia berfungsi.
Thanos mengambil data yang disimpan oleh Prometheus ke cakera tempatan dan menyalinnya ke S3, ke atau ke storan objek lain.
Oleh itu Thanos menyediakan pandangan pertanyaan global. Anda boleh menanyakan data yang disimpan dalam storan objek daripada berbilang kejadian Prometheus.
Thanos menyokong PromQL dan .
Thanos menggunakan kod Prometheus untuk menyimpan data.
Thanos dibangunkan oleh pembangun yang sama seperti Prometheus.
pada . Berikut , tempat yang pertama kali kita bincangkan .
VictoriaMetrics menerima data daripada beberapa prometheus protokol yang disokong oleh Prometheus.
VictoriaMetrics menyediakan paparan pertanyaan global, memandangkan berbilang kejadian Prometheus boleh menulis data kepada satu VictoriaMetrics. Sehubungan itu, anda boleh membuat pertanyaan tentang semua data ini.
VictoriaMetrics juga menyokong, seperti API pertanyaan Thanos, PromQL dan Prometheus.
Tidak seperti Thanos, kod sumber VictoriaMetrics ditulis dari awal dan dioptimumkan untuk kelajuan dan penggunaan sumber.
VictoriaMetrics, tidak seperti Thanos, menskala secara menegak dan mendatar. makan , yang berskala menegak. Anda boleh bermula dengan satu pemproses dan 1 GB memori dan secara beransur-ansur berkembang kepada ratusan pemproses dan 1 TB memori. VictoriaMetrics boleh menggunakan semua sumber ini. Prestasinya akan meningkat kira-kira 100 kali ganda berbanding sistem 1 teras.
Sejarah Thanos bermula pada November 2017, apabila komitmen awam pertama muncul. Sebelum ini, Thanos dibangunkan secara dalaman .
Pada Jun 2019 terdapat keluaran mercu tanda 0.5.0, yang mana protokol. Dia disingkirkan daripada Thanos kerana dia tidak beraksi dengan baik. Selalunya gugusan Thanos tidak berfungsi dengan betul, nod disambungkan dengan salah kerana protokol gosip. Oleh itu, kami memutuskan untuk mengeluarkannya dari sana. Saya rasa ini adalah keputusan yang tepat.
Pada Jun 2019 yang sama, mereka menghantar nombor permohonan в .
Dan selepas beberapa bulan Thanos diterima masuk , yang termasuk Prometheus, Kubernetes dan projek popular lain.
Pada Januari 2018, pembangunan VictoriaMetrics bermula.
Pada September 2018, saya menyebut VictoriaMetrics secara terbuka buat kali pertama.
Pada Disember 2018, versi Single-nod telah diterbitkan.
Pada bulan Mei 2019 sumber kedua-dua versi Single-nod dan kelompok.
Pada Jun 2019, sama seperti Thanos, kami telah mengemukakan permohonan kepada yayasan CNCF di bawah nombor . Kami memohon sehari sebelum Thanos memohon.
Tetapi, malangnya, kami masih belum diterima di sana. Bantuan komuniti diperlukan.
Mari lihat slaid paling penting yang menunjukkan seni bina Thanos dan VictoriaMetrics.
Mari kita mulakan dengan Thanos. Komponen kuning ialah komponen Prometheus. Yang lain adalah komponen Thanos. Mari kita mulakan dengan komponen yang paling penting. Thanos Sidecar ialah komponen yang dipasang di sebelah setiap Prometheus. Ia memuatkan data Prometheus dari storan tempatan ke S3 atau Storan Objek lain.
Terdapat juga komponen yang dipanggil Thanos Store Gateway, yang boleh membaca data ini daripada Storan Objek apabila permintaan masuk daripada Thanos Query. Thanos Query melaksanakan PromQL dan Prometheus API. Iaitu, dari luar ia kelihatan seperti Prometheus. Menerima pertanyaan PromQL, menghantarnya ke Thanos Store Gateway, Thanos Store Gateway mendapatkan semula data yang diperlukan daripada Object Storage, menghantarnya kembali.
Tetapi kami menyimpan data dalam Storan Objek tanpa dua jam terakhir disebabkan oleh ciri pelaksanaan Thanos Sidecar, yang tidak boleh memuat naik dua jam terakhir ke Storan Objek S3, kerana Prometheus belum lagi mencipta fail untuk dua jam ini dalam storan tempatan.
Bagaimanakah anda membuat keputusan untuk mengatasi perkara ini? Thanos Query, sebagai tambahan kepada permintaan ke Thanos Store Gateway, menghantar permintaan selari kepada setiap Thanos Sidecar, yang terletak di sebelah Prometheus.
Dan Thanos Sidecar, seterusnya, meminta proksi lebih lanjut kepada Prometheus, dan mendapatkan semula data untuk dua jam terakhir.
Sebagai tambahan kepada komponen ini, terdapat juga komponen pilihan yang tanpanya Thanos tidak akan berfungsi dengan baik. Ini ialah Thanos Compact, yang bertanggungjawab untuk menggabungkan fail kecil pada Storan Objek ke dalam fail yang lebih besar yang telah dimuat naik di sini oleh Thanos Sidecars. Thanos Sidecar memuat naik fail data di sana dalam masa dua jam. Fail ini, jika ia tidak digabungkan menjadi fail yang lebih besar, maka bilangannya boleh berkembang dengan sangat ketara. Lebih banyak fail sedemikian, lebih banyak memori diperlukan untuk Thanos Store Gateway, lebih banyak sumber diperlukan untuk memindahkan data melalui rangkaian dan metadata. Gerbang Kedai Thanos menjadi tidak berkesan. Oleh itu, adalah perlu untuk menjalankan Thanos Compact, yang menggabungkan fail kecil kepada yang lebih besar, supaya terdapat lebih sedikit fail sedemikian dan untuk mengurangkan overhed pada Gerbang Kedai Thanos.
Terdapat juga komponen seperti Thanos Ruler. Ia melaksanakan peraturan amaran Prometheus dan boleh menilai peraturan rakaman Prometheus untuk menulis semula data ke Storan Objek. Tetapi komponen ini tidak disyorkan untuk digunakan, kerana... Dia .
Ini adalah skema mudah Thanos.
Sekarang mari kita bandingkan dengan skim VictoriaMetrics.
VictoriaMetrics mempunyai 2 versi: versi nod tunggal dan kelompok. Nod tunggal berjalan pada satu komputer. Nod tunggal tidak mempunyai komponen ini, hanya satu binari. Perduaan pada slaid ini kelihatan seperti segi empat sama ini. Semua yang ada di dalam petak ialah kandungan fail binari untuk versi Single-nod. Anda tidak perlu tahu tentang dia. Anda hanya menjalankan binari dan semuanya berfungsi untuk kami.
Versi kluster lebih rumit. Di dalamnya terdapat tiga komponen berbeza: vmselect, vminsert dan vmstorage. Dari nama mereka harus jelas apa yang mereka lakukan. Komponen Sisipan menerima data dalam format yang berbeza: daripada API tulis jauh Prometheus, protokol talian Influx, protokol Grafit dan protokol OpenTSDB. Komponen Sisipan menerimanya, menghuraikannya dan mengedarkannya antara komponen storan sedia ada, di mana data telah disimpan. Komponen Select pula menerima pertanyaan PromQL. Dia melaksanakan , serta API pertanyaan Prometheus, dan ia boleh digunakan sebagai pengganti Prometheus dalam Grafana atau klien API Prometheus yang lain. Select menerima permintaan promql, menghuraikannya, membaca data yang diperlukan untuk melaksanakan permintaan ini daripada nod storan, memproses data ini dan mengembalikan respons.
Mari kita bandingkan kerumitan memasang Thanos dan VictoriaMetrics.
Mari kita mulakan dengan Thanos. Sebelum anda mula bekerja dengan Thanos, anda perlu membuat baldi dalam Storan Objek, seperti S3 atau GCS, supaya Thanos Sidecar boleh menulis data kepadanya.
Kemudian untuk setiap Prometheus anda perlu memasang Thanos Sidecar. Sebelum ini, anda perlu ingat untuk melumpuhkan pemadatan data dalam Prometheus. Pemadatan data secara berkala memampatkan data dalam storan Prometheus tempatan untuk mengurangkan penggunaan sumber.
Apabila anda memasang Thanos Sidecar pada Prometheus anda, anda mesti melumpuhkan pemadatan data ini kerana Thanos Sidecar tidak berfungsi dengan betul dengan pemadatan data didayakan. Ini bermakna Prometheus anda mula menyimpan data dalam blok dua jam dan berhenti menggabungkan blok tersebut menjadi blok yang lebih besar. Sehubungan itu, jika anda membuat pertanyaan yang melebihi tempoh dua jam yang lalu, maka pertanyaan itu tidak akan berfungsi secekap yang boleh berfungsi jika pemadatan data didayakan.
Oleh itu, Thanos mengesyorkan mengurangkan masa pengekalan data dalam storan tempatan kepada 6-8 jam untuk mengurangkan overhed sejumlah besar blok kecil.
Setelah anda memasang Thanos Sidecar, anda mesti memasang dua komponen untuk setiap Baldi Penyimpanan Objek. Ini ialah Thanos Compactor dan Thanos Store Gateway.
Selepas itu, anda perlu memasang Thanos Query dan mengkonfigurasikannya supaya ia boleh menyambung ke semua Gerbang Kedai Thanos yang anda miliki, dan juga boleh menyambung ke semua Thanos Sidecars.
Mungkin ada sedikit masalah di sini.
Anda perlu mengkonfigurasi sambungan yang boleh dipercayai dan selamat daripada Thanos Query kepada komponen ini. Dan jika Prometheus anda terletak di pusat data yang berbeza, atau dalam VPC yang berbeza, maka sambungan kepada mereka dari luar adalah dilarang. Tetapi untuk Thanos Query berfungsi, anda perlu mengkonfigurasi sambungan di sana, dan anda perlu memikirkan caranya.
Jika anda mempunyai banyak pusat data sedemikian, maka, dengan itu, kebolehpercayaan keseluruhan sistem berkurangan. Memandangkan Thanos Query mesti sentiasa mengekalkan sambungan ke semua Thanos Sidecars yang terletak di pusat data yang berbeza. Untuk setiap permintaan yang masuk, ia akan mengarahkan permintaan kepada semua Thanos Sidecars. Jika sambungan terputus, anda sama ada akan menerima set data yang tidak lengkap atau anda akan menerima respons "kluster telah turun".
Dalam VictoriaMetrics semuanya lebih ringkas. Untuk versi Single-nod, anda hanya perlu menjalankan satu binari dan semuanya berfungsi.
Dalam versi kluster, sudah cukup untuk menjalankan ketiga-tiga jenis komponen di atas dalam sebarang kuantiti yang anda perlukan, atau gunakan untuk mengautomasikan pelancaran komponen dalam Kubernetes. Kami juga merancang untuk membuat pengendali Kubernetes. Carta Helm tidak merangkumi beberapa kes dan membolehkan anda menembak diri sendiri. Sebagai contoh, ia membolehkan anda mengurangkan bilangan nod storan, yang akan membawa kepada kehilangan data.
Selepas anda melancarkan satu versi binari atau berkelompok, anda hanya perlu menambah Prometheus pada konfigurasi supaya ia mula menulis data selari dengan storan tempatan dan storan jauh. Seperti yang anda lihat, konfigurasi ini sepatutnya berprestasi lebih pasti berbanding dengan konfigurasi Thanos. Kami tidak perlu mengekalkan sambungan daripada VictoriaMetrics kepada semua Prometheus, kerana Prometheus sendiri menyambung ke VictoriaMetrics dan menghantar data.
Mari kita pertimbangkan sokongan Thanos dan VictoriaMetrics.
Thanos perlu memantau Sidecar untuk memastikan mereka tidak berhenti memuatkan data ke dalam Storan Objek. Mereka mungkin menghentikan muat turun data ini kerana ralat muat turun, contohnya sambungan rangkaian anda ke Storan Objek terganggu buat sementara waktu atau Storan Objek tidak tersedia buat sementara waktu. Thanos Sidecar akan menyedari perkara ini pada masa ini, melaporkan ralat, mungkin ranap dan kemudian berhenti berfungsi. Jika anda tidak memantaunya, maka anda akan berhenti memindahkan data ke Storan Objek. Jika masa pengekalan berlalu (6-8 jam disyorkan), maka anda akan kehilangan data yang tidak berada dalam Storan Objek.
Pemadat Thanos mungkin berhenti berfungsi kerana . Pemadat mengambil data daripada Storan Objek dan menggabungkannya menjadi kepingan data yang lebih besar. Memandangkan pemadat tidak disegerakkan dengan Sidecars, ini boleh berlaku: Sidecar belum mempunyai masa untuk melengkapkan blok, Compactor memutuskan bahawa blok ini telah ditulis sepenuhnya. Compactor mula membacanya. Ia tidak membaca blok sepenuhnya dan berhenti berfungsi. Lihat butiran .
Gerbang Kedai mungkin mengembalikan data yang tidak konsisten disebabkan perlumbaan antara Compactor dan Sidecars. Perkara yang sama di sini, kerana Gerbang Kedai tidak disegerakkan dengan Compactors dan Sidecars dalam apa jua cara. Sehubungan itu, keadaan perlumbaan mungkin berlaku apabila Gerbang Stor tidak melihat sebahagian daripada data atau melihat data yang tidak diperlukan.
Komponen Pertanyaan dalam Thanos secara lalai mengembalikan hasil separa jika beberapa Sidecar atau Gerbang Kedai tidak tersedia pada masa ini. Anda akan menerima sebahagian daripada data, dan anda tidak akan tahu bahawa anda tidak menerima semua data. Ini adalah cara ia berfungsi secara lalai. Dalam situasi yang sama, VictoriaMetrics mengembalikan data yang ditanda sebagai separa.
Tidak seperti Thanos, VictoriaMetrics jarang kehilangan data. Walaupun sambungan daripada Prometheus ke VictoriaMetrics terganggu, ini tidak menjadi masalah, kerana Prometheus terus merekodkan data baharu yang masuk dalam Log Tulis Hadapan, yang saiznya ialah 2 jam. Jika anda memulihkan sambungan anda ke VictoriaMetrics dalam masa dua jam, data anda tidak akan hilang. Prometheus .
Tidak seperti Thanos, yang menulis data ke storan objek hanya selepas dua jam, Prometheus secara automatik mereplikasi data menggunakan protokol tulis jauh ke storan jauh, seperti VictoriaMetrics. Anda tidak takut kehilangan storan tempatan di Prometheus. Jika dia tiba-tiba kehilangan storan tempatan, maka dalam kes yang paling teruk anda akan kehilangan detik terakhir data yang tidak mempunyai masa untuk direkodkan dalam storan jauh.
Kubernetes menguruskan kluster secara automatik, tidak seperti Thanos. Sukar untuk meletakkan semua komponen Thanos ke dalam satu gugusan Kubernetes, tidak seperti komponen gugusan VictoriaMetrics.
VictoriaMetrics mempunyai kemas kini yang sangat mudah kepada versi baharu. Hentikan sahaja VictoriaMetrics, kemas kini binari dan lancarkannya. Apabila dihentikan melalui isyarat SIGINT, semua binari VictoriaMetrics melakukan penutupan yang anggun. Mereka menyimpan data yang diperlukan dengan betul, menutup sambungan masuk dengan betul supaya tidak kehilangan apa-apa. Jadi anda tidak akan kehilangan apa-apa apabila menaik taraf.
VictoriaMetrics menjadikannya sangat mudah untuk mengembangkan kelompok. Hanya tambah komponen yang diperlukan dan teruskan bekerja.
Mengenai perangkap di Thanos dan VictoriaMetrics.
Thanos mempunyai perangkap berikut. Prometheus mesti menyimpan data selama dua jam terakhir. Jika ia tersesat, anda akan kehilangannya sepenuhnya kerana ia belum lagi ditulis ke Storan Objek seperti S3.
Komponen Store Gateway dan komponen pemadat boleh memerlukan banyak memori untuk berfungsi dengan Storan Objek yang besar jika terdapat banyak fail kecil yang disimpan di sana. Lebih besar bilangan dan saiz fail, lebih banyak Gerbang Simpan dan RAM pemadat diperlukan untuk menyimpan maklumat meta. Thanos mempunyai banyak isu mengenai fakta itu .
Thanos diiklankan untuk skala tanpa had dengan jumlah Prometheus yang anda miliki. Ini sebenarnya tidak benar. Memandangkan semua permintaan melalui komponen Pertanyaan, yang mesti meninjau semua komponen Store Gateway dan semua komponen Sidecar secara serentak, tarik data dari sana dan kemudian praprosesnya. Jelas sekali, kelajuan permintaan dihadkan oleh pautan lemah yang paling perlahan, Gerbang Kedai yang paling perlahan atau Sidecar yang paling perlahan.
Komponen ini mungkin dimuatkan secara tidak sekata. Contohnya, anda mempunyai Prometheus, yang mengumpul berjuta-juta metrik sesaat. Dan terdapat Prometheus, yang mengumpul beribu-ribu metrik sesaat. Prometheus, yang mengumpul berjuta-juta metrik sesaat, meletakkan beban yang lebih tinggi pada pelayan yang dijalankannya. Oleh itu, Sidecar berfungsi lebih perlahan di sana. Dan secara umum semuanya berfungsi dengan perlahan di sana. Dan komponen Pertanyaan akan menarik data dari sana dengan perlahan. Oleh itu, prestasi keseluruhan kluster anda akan dihadkan oleh Sidecar yang perlahan ini.
Secara lalai, Thanos memberikan data separa jika beberapa Sidecar dan sama ada Gerbang Kedai tidak tersedia. Contohnya, jika Sidecars anda tersebar di seluruh dunia dalam pusat data yang berbeza, maka kemungkinan kegagalan sambungan dan ketidaktersediaan komponen meningkat dengan ketara. Oleh itu, dalam kebanyakan kes anda akan menerima data separa tanpa mengetahuinya.
VictoriaMetrics juga mempunyai perangkap. Perangkap pertama ialah pilihan yang mengehadkan jumlah RAM yang digunakan untuk cache VictoriaMetrics. Secara lalai, ia bersamaan dengan 60% daripada RAM pada mesin tempat VictoriaMetrics sedang berjalan atau 60% daripada RAM pod VictoriaMetrics dalam Kubernetes.
Jika anda salah menukar nilai ini, anda boleh merosakkan prestasi VictoriaMetrics. Contohnya, jika anda menetapkan nilai terlalu rendah, data mungkin tidak lagi dimuatkan ke dalam cache VictoriaMetrics. Oleh sebab itu, dia perlu melakukan kerja tambahan dan memuatkan pemproses dan cakera. Jika anda membuat pilihan ini terlalu besar, ia akan meningkatkan, pertama sekali, kemungkinan bahawa VictoriaMetrics akan ranap dengan ralat memori, dan, kedua, ia akan membawa kepada fakta bahawa akan terdapat sedikit RAM yang tinggal dalam memori sistem pengendalian untuk cache fail. Dan VictoriaMetrics bergantung pada cache fail untuk prestasi. Jika ia tidak mencukupi, beban pada cakera boleh meningkat dengan ketara. Oleh itu, nasihat: jangan ubah parameter melainkan benar-benar perlu.
Pilihan kedua. Ini ialah retentionPeriod - tempoh yang ditetapkan kepada 1 bulan secara lalai. Ini ialah tempoh masa VictoriaMetrics menyimpan data. Selepas tempoh ini, VictoriaMetrics memadamkan data.
Ramai orang menjalankan VictoriaMetrics tanpa parameter ini dan merekodkan data selama sebulan. Dan kemudian mereka bertanya: mengapa data untuk bulan sebelumnya hilang? Kerana tempoh pengekalan lalai ialah 1 bulan. Oleh itu, anda perlu mengetahui dan menetapkan RetentionPeriod yang betul.
Mari kita lihat ciri uniknya.
Thanos mempunyai ciri yang dipanggil downsampling: selang 5 minit dan setiap jam, yang selalunya . Jika anda google dan melihat isu mereka di github, terdapat banyak isu yang berkaitan dengan pensampelan rendah ini, yang kadangkala tidak berfungsi dengan betul, atau tidak berfungsi seperti yang diharapkan oleh pengguna.
Thanos mempunyai penyahduplikasian data untuk pasangan Prometheus HA. Apabila dua Prometheus mengumpul metrik yang sama daripada sasaran yang sama dan Thanos menyimpannya dalam Storan Objek. Thanos boleh menyahduplikasi data ini dengan betul, tidak seperti VictoriaMetrics.
Thanos mempunyai komponen amaran yang terdapat dalam skema Thanos. Tetapi dia .
Thanos mempunyai kelebihan iaitu Thanos dan Prometheus berkongsi kod yang sama. Thanos dan Prometheus dibangunkan oleh pembangun yang sama. Dengan penambahbaikan kepada Thanos atau Prometheus, pihak lain menang.
Ciri utama VictoriaMetrics ialah MetricsQL. Ini adalah sambungan VictoriaMetrics untuk PromQL, yang saya bincangkan pada metup pemantauan besar sebelumnya.
VictoriaMetrics menyokong pemuatan data menggunakan banyak protokol yang berbeza. VictoriaMetrics bukan sahaja boleh menerima data daripada Prometheus, tetapi juga melalui protokol Influx, OpenTSDB dan Graphite.
Data VictoriaMetrics mengambil lebih sedikit ruang berbanding Thanos dan Prometheus.
Jika anda merekod data sebenar, pengguna bercakap tentang pengurangan 2-5 kali ganda dalam saiz data pada cakera berbanding Prometheus dan Thanos.
Satu lagi kelebihan VictoriaMetrics ialah ia dioptimumkan untuk kelajuan.
Mari kita lihat kos infrastruktur.
Salah satu kelebihan Thanos ialah ia menyimpan data dalam storan objek, yang agak murah.
Apabila menyimpan data dalam storan objek, anda mesti membayar untuk operasi menulis dan membaca data ($10 setiap juta operasi). Apabila anda menulis data ke storan objek, anda membayar kos pengehosan anda untuk memuat naik data ke Internet; jika kluster anda tiada dalam AWS, ia adalah percuma di sana. Apabila anda membaca data, anda membayar antara $10 dan $230 setiap 1TB. Ini boleh menjadi penting jika anda kerap menanyakan data sejarah daripada gugusan Thanos.
Untuk kluster Thanos, anda perlu membayar untuk pelayan untuk Compact, Store Gateway, komponen Pertanyaan yang memerlukan banyak memori dan CPU untuk jumlah data yang besar.
VictoriaMetrics mempunyai perbelanjaan berikut. Jika anda menyimpan data pada pemacu HDD GCE, ia akan menjadi $40 untuk 1TB. Untuk VictoriaMetrics, pemacu HDD biasa adalah mencukupi; tiada SSD, yang berharga lima kali lebih tinggi, diperlukan. VictoriaMetrics dioptimumkan untuk HDD.
VictoriaMetrics memerlukan pelayan untuk komponen: sama ada Single-nod atau komponen berkelompok, yang, tidak seperti komponen Thanos, memerlukan lebih sedikit CPU dan RAM - dan dengan itu akan menjadi lebih murah.
Contoh pelaksanaan.
Thanos mempunyai contoh pelaksanaan dalam Gitlab. Gitlab berjalan sepenuhnya pada Thanos. Tetapi tidak semuanya begitu lancar di sana. Jika anda melihat mereka , maka anda boleh melihat bahawa mereka sentiasa mempunyai beberapa : Tiada memori yang mencukupi untuk Gerbang Kedai atau komponen Pertanyaan. Mereka sentiasa perlu meningkatkan jumlah ingatan.
Disebabkan ini, kos untuk menyelesaikan masalah ini meningkat.
Pelaksanaan kedua, yang mungkin lebih berjaya, ialah syarikat Improbable, yang mula membangunkan Thanos. Mereka menerbitkan kod sumber Thanos. Improbable ialah syarikat yang membangunkan enjin permainan.
VictoriaMetrics mempunyai contoh pelaksanaan awam:
- wix.com pembina laman web
- Adidas sedang melaksanakan VictoriaMetrics dan juga membuat pembentangan pada PromCon 2019 yang lalu
- TrafficStars - rangkaian iklan
- Seznam.cz ialah enjin carian Czech yang popular.
Dan kemudian ada syarikat tanpa nama yang saya tidak boleh namakan sekarang. Mereka tidak bersetuju.
- Satu pembangun permainan utama. Lebih besar daripada im Improbable.
- Pembangun perisian grafik utama.
- Bank Rusia yang besar.
- Pengeluar turbin angin Eropah yang telah berjaya menguji VictoriaMetrics. Pengilang ini sedang melaksanakan VictoriaMetrics untuk memantau data yang dikumpul daripada turbin angin pada kadar 50 sampel sesaat setiap sensor. Setiap turbin angin mempunyai beberapa ratus sensor. Mereka mempunyai beberapa ratus turbin angin.
- Syarikat penerbangan Rusia yang ingin melaksanakan VictoriaMetrics, tetapi masih tidak boleh. Kami berada di peringkat kontrak dengan mereka.
Kesimpulan.
VictoriaMetrics dan Thanos menyelesaikan masalah yang sama, tetapi dengan cara yang berbeza:
- Paparan pertanyaan global
- penskalaan mendatar
- pengekalan sewenang-wenangnya
Terima kasih.
Kami sedang menunggu anda di kami .
Hanya pengguna berdaftar boleh mengambil bahagian dalam tinjauan. , Sama-sama.
Apakah yang anda gunakan sebagai simpanan jangka panjang untuk Prometheus?
35,3% Thanos6
0,0% Korteks0
0,0% M3DB0
41,2% VictoriaMetrics7
23,5% lain4
17 pengguna mengundi. 16 pengguna berpantang.
Sumber: www.habr.com
