Pangkalan data siri masa (TSDB) dalam Prometheus 2 ialah contoh terbaik penyelesaian kejuruteraan yang menawarkan peningkatan besar ke atas storan v2 dalam Prometheus 1 dari segi kelajuan pengumpulan data, pelaksanaan pertanyaan dan kecekapan sumber. Kami telah melaksanakan Prometheus 2 dalam Pemantauan dan Pengurusan Percona (PMM) dan saya berpeluang untuk memahami prestasi Prometheus 2 TSDB. Dalam artikel ini saya akan bercakap tentang hasil pemerhatian ini.
Purata Beban Kerja Prometheus
Bagi mereka yang biasa berurusan dengan pangkalan data tujuan umum, beban kerja Prometheus biasa agak menarik. Kadar pengumpulan data cenderung stabil: biasanya perkhidmatan yang anda pantau menghantar kira-kira bilangan metrik yang sama dan infrastruktur berubah secara perlahan.
Permintaan untuk maklumat mungkin datang dari pelbagai sumber. Sesetengah daripada mereka, seperti makluman, juga berusaha untuk mendapatkan nilai yang stabil dan boleh diramal. Lain-lain, seperti permintaan pengguna, boleh menyebabkan pecah, walaupun ini tidak berlaku untuk kebanyakan beban kerja.
Muatkan ujian
Semasa ujian, saya memberi tumpuan kepada keupayaan untuk mengumpul data. Saya menggunakan Prometheus 2.3.2 yang disusun dengan Go 1.10.1 (sebagai sebahagian daripada PMM 1.14) pada perkhidmatan Linode menggunakan skrip ini: . Untuk penjanaan beban yang paling realistik, gunakan ini Saya melancarkan beberapa nod MySQL dengan beban sebenar (Sysbench TPC-C Test), setiap satunya meniru 10 nod Linux/MySQL.
Semua ujian berikut telah dilakukan pada pelayan Linode dengan lapan teras maya dan memori 32 GB, menjalankan 20 simulasi beban memantau dua ratus contoh MySQL. Atau, dalam istilah Prometheus, 800 sasaran, 440 goresan sesaat, 380 ribu rekod sesaat dan 1,7 juta siri masa aktif.
Design
Pendekatan biasa pangkalan data tradisional, termasuk yang digunakan oleh Prometheus 1.x, adalah untuk . Jika ia tidak mencukupi untuk mengendalikan beban, anda akan mengalami latensi tinggi dan beberapa permintaan akan gagal. Penggunaan memori dalam Prometheus 2 boleh dikonfigurasikan melalui kunci storage.tsdb.min-block-duration, yang menentukan berapa lama rakaman akan disimpan dalam ingatan sebelum mengalir ke cakera (lalai ialah 2 jam). Jumlah memori yang diperlukan bergantung pada bilangan siri masa, label dan kikisan yang ditambahkan pada aliran masuk bersih. Dari segi ruang cakera, Prometheus menyasarkan untuk menggunakan 3 bait setiap rekod (sampel). Sebaliknya, keperluan memori jauh lebih tinggi.
Walaupun adalah mungkin untuk mengkonfigurasi saiz blok, ia tidak disyorkan untuk mengkonfigurasinya secara manual, jadi anda terpaksa memberikan Prometheus sebanyak memori yang diperlukan untuk beban kerja anda.
Jika ingatan tidak mencukupi untuk menyokong aliran metrik yang masuk, Prometheus akan hilang daripada ingatan atau pembunuh OOM akan mendapatkannya.
Menambah swap untuk melambatkan ranap apabila Prometheus kehabisan memori tidak benar-benar membantu, kerana menggunakan fungsi ini menyebabkan penggunaan memori yang meletup. Saya fikir ia ada kaitan dengan Go, pemungut sampahnya dan cara ia berurusan dengan swap.
Satu lagi pendekatan yang menarik ialah mengkonfigurasi blok kepala untuk disiram ke cakera pada masa tertentu, bukannya mengiranya dari permulaan proses.
Seperti yang anda boleh lihat daripada graf, siram ke cakera berlaku setiap dua jam. Jika anda menukar parameter tempoh blok min kepada satu jam, maka tetapan semula ini akan berlaku setiap jam, bermula selepas setengah jam.
Jika anda ingin menggunakan ini dan graf lain dalam pemasangan Prometheus anda, anda boleh menggunakan ini . Ia direka untuk PMM tetapi, dengan pengubahsuaian kecil, sesuai dengan mana-mana pemasangan Prometheus.
Kami mempunyai blok aktif yang dipanggil blok kepala yang disimpan dalam ingatan; blok dengan data lama boleh didapati melalui mmap(). Ini menghapuskan keperluan untuk mengkonfigurasi cache secara berasingan, tetapi juga bermakna anda perlu meninggalkan ruang yang mencukupi untuk cache sistem pengendalian jika anda ingin menanyakan data yang lebih lama daripada apa yang boleh dimuatkan oleh blok kepala.
Ini juga bermakna penggunaan memori maya Prometheus akan kelihatan agak tinggi, yang tidak perlu dibimbangkan.
Satu lagi perkara reka bentuk yang menarik ialah penggunaan WAL (tulis log ke hadapan). Seperti yang anda lihat daripada dokumentasi storan, Prometheus menggunakan WAL untuk mengelakkan ranap sistem. Mekanisme khusus untuk menjamin kemandirian data, malangnya, tidak didokumenkan dengan baik. Prometheus versi 2.3.2 mengepam WAL ke cakera setiap 10 saat dan pilihan ini tidak boleh dikonfigurasikan pengguna.
Pemadatan
Prometheus TSDB direka bentuk seperti stor LSM (Log Structured Merge): blok kepala disiram secara berkala ke cakera, manakala mekanisme pemadatan menggabungkan berbilang blok bersama-sama untuk mengelakkan mengimbas terlalu banyak blok semasa pertanyaan. Di sini anda boleh melihat bilangan blok yang saya perhatikan pada sistem ujian selepas seharian dimuatkan.
Jika anda ingin mengetahui lebih lanjut tentang kedai, anda boleh menyemak fail meta.json, yang mempunyai maklumat tentang blok yang tersedia dan cara ia wujud.
{
"ulid": "01CPZDPD1D9R019JS87TPV5MPE",
"minTime": 1536472800000,
"maxTime": 1536494400000,
"stats": {
"numSamples": 8292128378,
"numSeries": 1673622,
"numChunks": 69528220
},
"compaction": {
"level": 2,
"sources": [
"01CPYRY9MS465Y5ETM3SXFBV7X",
"01CPYZT0WRJ1JB1P0DP80VY5KJ",
"01CPZ6NR4Q3PDP3E57HEH760XS"
],
"parents": [
{
"ulid": "01CPYRY9MS465Y5ETM3SXFBV7X",
"minTime": 1536472800000,
"maxTime": 1536480000000
},
{
"ulid": "01CPYZT0WRJ1JB1P0DP80VY5KJ",
"minTime": 1536480000000,
"maxTime": 1536487200000
},
{
"ulid": "01CPZ6NR4Q3PDP3E57HEH760XS",
"minTime": 1536487200000,
"maxTime": 1536494400000
}
]
},
"version": 1
}Pemadatan dalam Prometheus terikat pada masa blok kepala disiram ke cakera. Pada ketika ini, beberapa operasi sedemikian mungkin dijalankan.
Nampaknya pemadatan tidak terhad dalam apa jua cara dan boleh menyebabkan pancang I/O cakera besar semasa pelaksanaan.
Lonjakan beban CPU
Sudah tentu, ini mempunyai kesan yang agak negatif terhadap kelajuan sistem, dan juga menimbulkan cabaran yang serius untuk storan LSM: bagaimana melakukan pemadatan untuk menyokong kadar permintaan yang tinggi tanpa menyebabkan terlalu banyak overhed?
Penggunaan memori dalam proses pemadatan juga kelihatan agak menarik.
Kita boleh melihat bagaimana, selepas pemadatan, kebanyakan memori berubah keadaan daripada Cached kepada Percuma: ini bermakna maklumat yang berpotensi berharga telah dialih keluar dari sana. Ingin tahu jika ia digunakan di sini fadvice() atau beberapa teknik pengecilan lain, atau adakah ia kerana cache telah dibebaskan daripada blok yang dimusnahkan semasa pemadatan?
Pemulihan selepas kegagalan
Pemulihan daripada kegagalan memerlukan masa, dan untuk alasan yang baik. Untuk aliran masuk sejuta rekod sesaat, saya terpaksa menunggu kira-kira 25 minit sementara pemulihan dilakukan dengan mengambil kira pemacu SSD.
level=info ts=2018-09-13T13:38:14.09650965Z caller=main.go:222 msg="Starting Prometheus" version="(version=2.3.2, branch=v2.3.2, revision=71af5e29e815795e9dd14742ee7725682fa14b7b)"
level=info ts=2018-09-13T13:38:14.096599879Z caller=main.go:223 build_context="(go=go1.10.1, user=Jenkins, date=20180725-08:58:13OURCE)"
level=info ts=2018-09-13T13:38:14.096624109Z caller=main.go:224 host_details="(Linux 4.15.0-32-generic #35-Ubuntu SMP Fri Aug 10 17:58:07 UTC 2018 x86_64 1bee9e9b78cf (none))"
level=info ts=2018-09-13T13:38:14.096641396Z caller=main.go:225 fd_limits="(soft=1048576, hard=1048576)"
level=info ts=2018-09-13T13:38:14.097715256Z caller=web.go:415 component=web msg="Start listening for connections" address=:9090
level=info ts=2018-09-13T13:38:14.097400393Z caller=main.go:533 msg="Starting TSDB ..."
level=info ts=2018-09-13T13:38:14.098718401Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536530400000 maxt=1536537600000 ulid=01CQ0FW3ME8Q5W2AN5F9CB7R0R
level=info ts=2018-09-13T13:38:14.100315658Z caller=web.go:467 component=web msg="router prefix" prefix=/prometheus
level=info ts=2018-09-13T13:38:14.101793727Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536732000000 maxt=1536753600000 ulid=01CQ78486TNX5QZTBF049PQHSM
level=info ts=2018-09-13T13:38:14.102267346Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536537600000 maxt=1536732000000 ulid=01CQ78DE7HSQK0C0F5AZ46YGF0
level=info ts=2018-09-13T13:38:14.102660295Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536775200000 maxt=1536782400000 ulid=01CQ7SAT4RM21Y0PT5GNSS146Q
level=info ts=2018-09-13T13:38:14.103075885Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536753600000 maxt=1536775200000 ulid=01CQ7SV8WJ3C2W5S3RTAHC2GHB
level=error ts=2018-09-13T14:05:18.208469169Z caller=wal.go:275 component=tsdb msg="WAL corruption detected; truncating" err="unexpected CRC32 checksum d0465484, want 0" file=/opt/prometheus/data/.prom2-data/wal/007357 pos=15504363
level=info ts=2018-09-13T14:05:19.471459777Z caller=main.go:543 msg="TSDB started"
level=info ts=2018-09-13T14:05:19.471604598Z caller=main.go:603 msg="Loading configuration file" filename=/etc/prometheus.yml
level=info ts=2018-09-13T14:05:19.499156711Z caller=main.go:629 msg="Completed loading of configuration file" filename=/etc/prometheus.yml
level=info ts=2018-09-13T14:05:19.499228186Z caller=main.go:502 msg="Server is ready to receive web requests."Masalah utama proses pemulihan ialah penggunaan memori yang tinggi. Walaupun fakta bahawa dalam keadaan biasa pelayan boleh berfungsi dengan stabil dengan jumlah memori yang sama, jika ia ranap ia mungkin tidak pulih kerana OOM. Satu-satunya penyelesaian yang saya temui ialah melumpuhkan pengumpulan data, memaparkan pelayan, biarkan ia pulih dan but semula dengan pengumpulan didayakan.
Memanaskan badan
Satu lagi tingkah laku yang perlu diingat semasa memanaskan badan ialah hubungan antara prestasi rendah dan penggunaan sumber yang tinggi sejurus selepas permulaan. Semasa beberapa, tetapi tidak semua bermula, saya memerhatikan beban serius pada CPU dan memori.
Jurang dalam penggunaan memori menunjukkan bahawa Prometheus tidak boleh mengkonfigurasi semua koleksi dari awal, dan beberapa maklumat hilang.
Saya tidak mengetahui sebab yang tepat untuk beban CPU dan memori yang tinggi. Saya mengesyaki bahawa ini disebabkan oleh penciptaan siri masa baharu dalam blok kepala dengan frekuensi tinggi.
beban CPU melonjak
Sebagai tambahan kepada pemadatan, yang menghasilkan beban I/O yang agak tinggi, saya melihat lonjakan serius dalam beban CPU setiap dua minit. Letupan lebih lama apabila aliran input tinggi dan nampaknya disebabkan oleh pemungut sampah Go, dengan sekurang-kurangnya beberapa teras dimuatkan sepenuhnya.
Lompatan ini tidak begitu ketara. Nampaknya apabila ini berlaku, titik masuk dan metrik dalaman Prometheus menjadi tidak tersedia, menyebabkan jurang data dalam tempoh masa yang sama ini.
Anda juga boleh melihat bahawa pengeksport Prometheus ditutup selama satu saat.
Kita dapat melihat korelasi dengan kutipan sampah (GC).
Kesimpulan
TSDB dalam Prometheus 2 adalah pantas, mampu mengendalikan berjuta-juta siri masa dan pada masa yang sama beribu-ribu rekod sesaat menggunakan perkakasan yang agak sederhana. Penggunaan CPU dan cakera I/O juga mengagumkan. Contoh saya menunjukkan sehingga 200 metrik sesaat bagi setiap teras yang digunakan.
Untuk merancang pengembangan, anda perlu ingat tentang jumlah memori yang mencukupi, dan ini mestilah ingatan sebenar. Jumlah memori yang digunakan yang saya perhatikan ialah kira-kira 5 GB setiap 100 rekod sesaat daripada aliran masuk, yang bersama-sama dengan cache sistem pengendalian memberikan kira-kira 000 GB memori yang diduduki.
Sudah tentu, masih banyak kerja yang perlu dilakukan untuk menjinakkan pancang I/O CPU dan cakera, dan ini tidak menghairankan memandangkan betapa TSDB Prometheus 2 muda dibandingkan dengan InnoDB, TokuDB, RocksDB, WiredTiger, tetapi semuanya mempunyai persamaan. masalah pada awal kitaran hidup mereka.
Sumber: www.habr.com