Analisis TSDB dina Prometheus 2

Analisis TSDB dina Prometheus 2

Basis data séri waktos (TSDB) dina Prometheus 2 mangrupikeun conto anu saé pikeun solusi rékayasa anu nawiskeun perbaikan utama dina panyimpenan v2 di Prometheus 1 dina hal kecepatan akumulasi data, palaksanaan query, sareng efisiensi sumberdaya. Kami ngalaksanakeun Prometheus 2 di Percona Monitoring and Management (PMM) sareng kuring ngagaduhan kasempetan pikeun ngartos kinerja Prometheus 2 TSDB. Dina artikel ieu kuring bakal ngobrol ngeunaan hasil observasi ieu.

Rata-rata Beban Prometheus

Pikeun anu biasa ngurus pangkalan data tujuan umum, beban kerja Prometheus khas cukup pikaresepeun. Laju akumulasi data condong stabil: biasana jasa anu anjeun pantau ngirimkeun jumlah métrik anu sami, sareng prasarana robah rélatif laun.
Paménta inpormasi tiasa asalna tina sababaraha sumber. Sababaraha di antarana, kayaning ngabejaan, ogé narékahan pikeun nilai stabil sarta bisa diprediksi. Anu sanésna, sapertos pamundut pangguna, tiasa nyababkeun bursts, sanaos ieu sanés kasus pikeun kalolobaan beban kerja.

Uji beban

Salila tés, kuring museurkeun kana kamampuan pikeun ngumpulkeun data. Kuring nyebarkeun Prometheus 2.3.2 disusun sareng Go 1.10.1 (salaku bagian tina PMM 1.14) dina layanan Linode nganggo naskah ieu: StackScript. Pikeun generasi beban paling realistis, ngagunakeun ieu StackScript Kuring ngaluncurkeun sababaraha titik MySQL kalayan beban nyata (Sysbench TPC-C Test), anu masing-masing ditiru 10 titik Linux/MySQL.
Sadaya tés di handap ieu dilakukeun dina server Linode sareng dalapan inti virtual sareng mémori 32 GB, ngajalankeun 20 simulasi beban ngawaskeun dua ratus instansi MySQL. Atawa, dina istilah Prometheus, 800 target, 440 scrapes per detik, 380 rébu rékaman per detik, sarta 1,7 juta runtuyan waktu aktip.

rarancang

Pendekatan dawam tina basis data tradisional, kaasup nu dipaké ku Prometheus 1.x, nyaéta pikeun wates memori. Lamun teu cukup pikeun nanganan beban, Anjeun bakal ngalaman latency tinggi jeung sababaraha requests bakal gagal. Pamakéan mémori dina Prometheus 2 tiasa dikonfigurasi ku konci storage.tsdb.min-block-duration, nu nangtukeun sabaraha lila rekaman bakal disimpen dina mémori saméméh flushing kana disk (standar nyaéta 2 jam). Jumlah mémori anu diperyogikeun bakal gumantung kana jumlah séri waktos, labél, sareng kerok anu ditambah kana aliran anu asup. Dina hal spasi disk, Prometheus boga tujuan pikeun ngagunakeun 3 bait per catetan (sampel). Di sisi anu sanés, syarat mémori langkung luhur.

Sanajan kasebut nyaéta dimungkinkeun pikeun ngonpigurasikeun ukuran block, teu dianjurkeun pikeun ngonpigurasikeun eta sacara manual, jadi Anjeun kapaksa masihan Prometheus salaku loba memori sakumaha merlukeun pikeun workload Anjeun.
Upami teu aya mémori anu cekap pikeun ngadukung aliran métrik anu asup, Prometheus bakal kaluar tina mémori atanapi pembunuh OOM bakal dugi ka éta.
Nambahkeun swap pikeun reureuh kacilakaan nalika Prometheus béak mémori teu bener mantuan, sabab ngagunakeun fungsi ieu ngabalukarkeun konsumsi memori ngabeledug. Jigana aya hubunganana sareng Go, tukang sampah sareng cara ngurus swap.
pendekatan sejen metot nyaéta pikeun ngonpigurasikeun blok sirah bisa flushed kana disk dina waktu nu tangtu, tinimbang cacah ti mimiti prosés.

Analisis TSDB dina Prometheus 2

Sakumaha anjeun tiasa tingali tina grafik, flushes ka disk lumangsung unggal dua jam. Lamun ngarobah parameter mnt-blok-durasi ka hiji jam, mangka resets ieu bakal lumangsung unggal jam, dimimitian sanggeus satengah jam.
Upami anjeun hoyong nganggo ieu sareng grafik anu sanés dina pamasangan Prometheus anjeun, anjeun tiasa nganggo ieu dasbor. Ieu dirancang pikeun PMM tapi, kalawan modifikasi minor, fits kana sagala instalasi Prometheus.
Simkuring boga blok aktif disebut blok sirah nu disimpen dina mémori; blok jeung data heubeul sadia via mmap(). Ieu ngaleungitkeun kabutuhan pikeun ngonpigurasikeun cache nyalira, tapi ogé ngandung harti yén anjeun kedah nyéépkeun rohangan anu cukup pikeun cache sistem operasi upami anjeun hoyong naroskeun data anu langkung lami tibatan anu tiasa nampung blok sirah.
Ieu ngandung harti ogé yén konsumsi mémori maya Prometheus bakal kasampak rada luhur, nu teu hal salempang ngeunaan.

Analisis TSDB dina Prometheus 2

titik design metot séjén nyaéta pamakéan WAL (nulis ahead log). Sakumaha anjeun tiasa tingali tina dokuméntasi gudang, Prometheus nganggo WAL pikeun ngahindarkeun kacilakaan. Mékanisme khusus pikeun ngajamin kasalametan data, hanjakalna, henteu didokumentasikeun. Vérsi Prometheus 2.3.2 flushes WAL ka disk unggal 10 detik sarta pilihan ieu teu pamaké configurable.

Compactions

Prometheus TSDB dirancang kawas LSM (Log Structured Merge) toko: blok sirah flushed périodik kana disk, bari mékanisme compaction ngagabungkeun sababaraha blok babarengan pikeun nyegah scanning loba teuing blok salila queries. Di dieu anjeun tiasa ningali jumlah blok anu kuring perhatikeun dina sistem uji saatos sadinten beban.

Analisis TSDB dina Prometheus 2

Lamun hayang leuwih jéntré ngeunaan toko, anjeun tiasa nalungtik meta.json file, nu boga informasi ngeunaan blok sadia tur kumaha aranjeunna sumping ka jadi.

{
       "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
}

Compactions di Prometheus dihijikeun ka waktu blok sirah flushed kana disk. Dina titik ieu, sababaraha operasi sapertos tiasa dilaksanakeun.

Analisis TSDB dina Prometheus 2

Nembongan yen compactions teu diwatesan sagala cara jeung bisa ngabalukarkeun badag disk I / O paku salila palaksanaan.

Analisis TSDB dina Prometheus 2

CPU beban paku

Analisis TSDB dina Prometheus 2

Tangtu, ieu boga dampak rada négatip on speed sistem, sarta ogé penah tangtangan serius pikeun neundeun LSM: kumaha carana ngalakukeun compaction pikeun ngarojong ongkos pamundut tinggi tanpa ngabalukarkeun teuing overhead?
Pamakéan memori dina prosés compaction ogé kasampak rada metot.

Analisis TSDB dina Prometheus 2

Urang tiasa ningali kumaha, sanggeus compaction, lolobana mémori robah kaayaan tina Cached mun Free: ieu ngandung harti yén informasi berpotensi berharga geus dihapus ti dinya. Panasaran upami dianggo di dieu fadvice() atawa sababaraha téhnik minimization séjén, atawa éta alatan cache ieu dibébaskeun tina blok ancur salila compaction?

Pamulihan saatos gagal

Pamulihan tina kagagalan butuh waktos, sareng alesan anu saé. Pikeun aliran asup sajuta rékaman per detik, kuring kedah ngantosan sakitar 25 menit nalika pamulihan dilaksanakeun kalayan nganggap SSD drive.

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 prosés pamulihan nyaéta konsumsi mémori anu luhur. Najan kanyataan yén dina kaayaan normal server tiasa dianggo stably kalawan jumlah sarua memori, lamun ngadat bisa jadi teu cageur alatan OOM. Hiji-hijina solusi anu kuring mendakan nyaéta nganonaktipkeun pangumpulan data, nyangking server, ngantepkeun éta pulih sareng reboot kalayan koléksi diaktipkeun.

Pamanasan

Paripolah anu sanés anu kedah diémutan nalika pemanasan nyaéta hubungan antara kinerja rendah sareng konsumsi sumberdaya anu luhur saatos ngamimitian. Salila sababaraha, tapi teu kabeh dimimitian, Kuring observasi beban serius dina CPU jeung memori.

Analisis TSDB dina Prometheus 2

Analisis TSDB dina Prometheus 2

Gaps dina pamakéan memori nunjukkeun yén Prometheus teu bisa ngonpigurasikeun sakabéh kumpulan ti mimiti, sarta sababaraha émbaran leungit.
Kuring henteu terang alesan pasti pikeun CPU sareng beban mémori anu luhur. Kuring curiga yén ieu téh alatan kreasi runtuyan waktu anyar dina blok sirah kalayan frékuénsi luhur.

beban CPU surges

Salian compactions, nu nyieun I / beban O cukup luhur, Kuring noticed paku serius dina beban CPU unggal dua menit. Bursts langkung panjang nalika aliran input luhur sareng sigana disababkeun ku tukang sampah Go, sareng sahenteuna sababaraha inti pinuh dimuat.

Analisis TSDB dina Prometheus 2

Analisis TSDB dina Prometheus 2

jumps ieu teu jadi hina. Katingalina nalika ieu kajantenan, titik éntri internal sareng métrik Prometheus janten teu sayogi, nyababkeun jurang data salami période waktos anu sami.

Analisis TSDB dina Prometheus 2

Anjeun oge bisa perhatikeun yén eksportir Prometheus shuts handap pikeun sadetik.

Analisis TSDB dina Prometheus 2

Urang tiasa perhatikeun korelasi sareng pengumpulan sampah (GC).

Analisis TSDB dina Prometheus 2

kacindekan

TSDB di Prometheus 2 gancang, sanggup nanganan jutaan séri waktos sareng dina waktos anu sami rébuan rékaman per detik nganggo hardware anu cukup sederhana. CPU jeung disk I / O utilization oge impressive. conto abdi némbongkeun nepi ka 200 metrics per detik per core dipaké.

Pikeun rencana ékspansi, Anjeun kudu inget ngeunaan jumlah cukup memori, sarta ieu kudu jadi memori nyata. Jumlah memori dipaké yén kuring observasi éta ngeunaan 5 GB per 100 rékaman per detik tina stream asup, nu bareng jeung sistem operasi cache masihan ngeunaan 000 GB memori nempatan.

Tangtu, aya kénéh loba karya dipigawé pikeun ngalilindeuk CPU jeung disk I / O paku, sarta ieu teu heran tempo kumaha ngora TSDB Prometheus 2 dibandingkeun InnoDB, TokuDB, RocksDB, WiredTiger, tapi aranjeunna sadayana kagungan sarupa. masalah mimiti dina siklus kahirupan maranéhanana.

sumber: www.habr.com

Tambahkeun komentar