D'Zäitserie-Datebank (TSDB) am Prometheus 2 ass en exzellent Beispill vun enger Ingenieursléisung déi grouss Verbesserungen iwwer d'v2-Speicherung am Prometheus 1 a punkto Dateakkumulatiounsgeschwindegkeet, Ufroausféierung a Ressourceeffizienz bitt. Mir hunn Prometheus 2 an Percona Monitoring and Management (PMM) implementéiert an ech hat d'Geleeënheet d'Leeschtung vum Prometheus 2 TSDB ze verstoen. An dësem Artikel wäert ech iwwer d'Resultater vun dësen Observatiounen schwätzen.
Duerchschnëtt Prometheus Aarbechtslaascht
Fir déi, déi benotzt gi fir allgemeng Zwecker Datenbanken ze këmmeren, ass déi typesch Prometheus Aarbechtslaascht ganz interessant. Den Taux vun der Dateakkumulatioun tendéiert stabil ze sinn: normalerweis schécken d'Servicer déi Dir iwwerwaacht ongeféier déiselwecht Unzuel u Metriken, an d'Infrastruktur ännert sech relativ lues.
Ufroe fir Informatioun kënne vu verschiddene Quelle kommen. E puer vun hinnen, wéi Alarmer, striewen och no engem stabilen a prévisibele Wäert. Anerer, wéi Benotzer Ufroen, kënne Bursts verursaachen, obwuel dëst net de Fall ass fir déi meescht Aarbechtsbelaaschtungen.
Laascht Test
Wärend dem Test hunn ech mech op d'Fäegkeet konzentréiert fir Daten ze sammelen. Ech hunn de Prometheus 2.3.2 zesummegesat mat Go 1.10.1 (als Deel vum PMM 1.14) am Linode Service mat dësem Skript ofgebaut: . Fir déi realisteschst Belaaschtungsgeneratioun, benotzt dëst Ech hunn e puer MySQL Noden mat enger realer Laascht gestart (Sysbench TPC-C Test), jidderee vun deenen 10 Linux / MySQL Noden emuléiert hunn.
All déi folgend Tester goufen op engem Linode-Server mat aacht virtuelle Kären an 32 GB Gedächtnis gemaach, déi 20 Lastsimulatioune lafen déi zweehonnert MySQL Instanzen iwwerwaachen. Oder, a Prometheus Begrëffer, 800 Ziler, 440 Scrapes pro Sekonn, 380 Tausend Rekorder pro Sekonn, an 1,7 Milliounen aktiv Zäitreihe.
Design
Déi üblech Approche vun traditionellen Datenbanken, och déi vum Prometheus 1.x benotzt, ass fir . Wann et net genuch ass fir d'Laascht ze handhaben, wäert Dir héich latencies erliewen an e puer Ufroe falen. Erënnerungsverbrauch am Prometheus 2 ass konfiguréierbar iwwer Schlëssel storage.tsdb.min-block-duration, wat bestëmmt wéi laang Opzeechnungen an der Erënnerung gehale ginn ier se op d'Disk spülen (Standard ass 2 Stonnen). D'Quantitéit un Erënnerung erfuerderlech hänkt vun der Unzuel vun Zäitreihe, Etiketten a Schrauwen of, déi am Netto-Entrée Stream bäigefüügt ginn. Wat den Disk Space ugeet, zielt Prometheus fir 3 Bytes pro Rekord (Probe) ze benotzen. Op der anerer Säit sinn d'Erënnerungsfuerderunge vill méi héich.
Och wann et méiglech ass d'Blockgréisst ze konfiguréieren, ass et net recommandéiert se manuell ze konfiguréieren, sou datt Dir gezwongen sidd Prometheus sou vill Erënnerung ze ginn wéi et fir Är Aarbechtslaascht erfuerdert.
Wann et net genuch Erënnerung ass fir den erakommende Stroum vu Metriken z'ënnerstëtzen, da fällt de Prometheus aus der Erënnerung oder den OOM Killer kënnt derzou.
Swap bäizefügen fir den Crash ze verzögeren wann de Prometheus aus Erënnerung leeft, hëlleft net wierklech, well d'Benotzung vun dëser Funktioun explosive Erënnerungsverbrauch verursaacht. Ech mengen et ass eppes mam Go ze dinn, säin Dreckstéck an d'Art a Weis wéi et mam Swap handelt.
Eng aner interessant Approche ass de Kappblock ze konfiguréieren fir op eng gewëssen Zäit op Disk ze spülen, anstatt et vum Ufank vum Prozess ze zielen.
Wéi Dir aus der Grafik kënnt gesinn, geschéien Spülen op Disk all zwou Stonnen. Wann Dir de Min-Block-Dauer-Parameter op eng Stonn ännert, da ginn dës Resets all Stonn op, ab no enger hallwer Stonn.
Wann Dir dës an aner Grafiken an Ärer Prometheus Installatioun benotze wëllt, kënnt Dir dëst benotzen . Et war fir PMM entworf awer, mat klengen Ännerungen, passt an all Prometheus Installatioun.
Mir hunn en aktiven Block genannt Kappblock deen an der Erënnerung gespäichert ass; Blocks mat méi alen Donnéeën sinn verfügbar via mmap(). Dëst eliminéiert d'Noutwendegkeet fir de Cache separat ze konfiguréieren, awer heescht och datt Dir genuch Plaz fir de Betribssystem-Cache muss verloossen wann Dir Daten méi al wëllt froen wéi dat wat de Kappblock kann aménagéieren.
Dëst bedeit och datt de Prometheus virtuelle Gedächtnisverbrauch zimmlech héich ausgesäit, wat net eppes ass fir Iech Suergen ze maachen.
En aneren interessanten Designpunkt ass d'Benotzung vu WAL (Write ahead Log). Wéi Dir aus der Späicherdokumentatioun kënnt gesinn, benotzt Prometheus WAL fir Crashen ze vermeiden. Spezifesch Mechanismen fir d'Iwwerliewensfäegkeet vun Daten ze garantéieren sinn, leider, net gutt dokumentéiert. Prometheus Versioun 2.3.2 spült WAL op Disk all 10 Sekonnen an dës Optioun ass net konfiguréierbar vum Benotzer.
Compactions
Prometheus TSDB ass entworf wéi en LSM (Log Structured Merge) Store: de Kappblock gëtt periodesch op d'Disk gespullt, während e Verdichtungsmechanismus multiple Blocks kombinéiert fir ze vill Blocks während Ufroen ze scannen. Hei kënnt Dir d'Zuel vu Blocken gesinn, déi ech um Testsystem no engem Dag vun der Laascht observéiert hunn.
Wann Dir méi iwwer de Buttek wësse wëllt, kënnt Dir d'meta.json Datei ënnersichen, déi Informatioun iwwer d'Blöcke verfügbar huet a wéi se entstane sinn.
{
"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
}Verdichtungen am Prometheus sinn un d'Zäit gebonnen, wou de Kappblock op d'Disk gespullt gëtt. Zu dësem Zäitpunkt kënnen e puer esou Operatiounen duerchgefouert ginn.
Et schéngt datt Verdichtungen op kee Fall limitéiert sinn a grouss Disk I / O Spikes wärend der Ausféierung verursaache kënnen.
CPU Luede Spikes
Natierlech huet dëst en zimlech negativen Impakt op d'Geschwindegkeet vum System, a stellt och eng sérieux Erausfuerderung fir LSM-Speicherung: wéi eng Verdichtung ze maachen fir héich Ufroraten z'ënnerstëtzen ouni ze vill Overhead ze verursaachen?
D'Benotzung vun Erënnerung am Verdichtungsprozess gesäit och ganz interessant aus.
Mir kënne gesinn wéi no der Verdichtung déi meescht vun der Erënnerung den Zoustand vun Cached op Free ännert: dat heescht datt potenziell wäertvoll Informatioun vun do ewechgeholl gouf. Virwëtzeg ob et hei benotzt gëtt fadvice() oder eng aner Minimaliséierungstechnik, oder ass et well de Cache befreit gouf vu Blocken, déi während der Verdichtung zerstéiert goufen?
Erhuelung no engem Echec
Erhuelung vu Feeler brauch Zäit, a fir gudde Grond. Fir en erakommen Stream vun enger Millioun Opzeechnungen pro Sekonn, hunn ech ongeféier 25 Minuten gewaart, während d'Erhuelung duerchgefouert gouf mat der 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."Den Haaptproblem vum Erhuelungsprozess ass héich Erënnerungsverbrauch. Trotz der Tatsaach, datt an enger normaler Situatioun de Server stabil mat der selwechter Quantitéit un Erënnerung funktionéiere kann, wann et klappt, kann et net erholen wéinst OOM. Déi eenzeg Léisung, déi ech fonnt hunn, war d'Datesammlung auszeschalten, de Server opzebréngen, et ze recuperéieren an nei ze starten mat der Sammlung aktivéiert.
Erwiermung
En anert Verhalen am Kapp ze halen wärend der Erwiermung ass d'Relatioun tëscht niddereg Leeschtung an héije Ressourceverbrauch direkt nom Start. Wärend e puer, awer net all Start, hunn ech eng sérieux Belaaschtung op d'CPU an d'Erënnerung observéiert.
Lücken am Erënnerungsverbrauch weisen datt Prometheus net all Sammlunge vun Ufank un konfiguréieren, an e puer Informatioun ass verluer.
Ech hunn net déi genee Grënn fir déi héich CPU an Erënnerung Laascht erausfonnt. Ech de Verdacht datt dëst wéinst der Schafung vun neien Zäitreihe am Kappblock mat enger héijer Frequenz ass.
CPU Laascht eropgeet
Zousätzlech zu de Verdichtungen, déi eng zimlech héich I / O-Laascht kreéieren, hunn ech all zwou Minutten eescht Spikes an der CPU-Laascht gemierkt. D'Bursten si méi laang wann den Inputfloss héich ass a schénge vum Go's Gerempels ze ginn, mat op d'mannst e puer Kären déi voll gelueden sinn.
Dës Spréng sinn net sou onwichteg. Et schéngt datt wann dës geschéien, dem Prometheus säin internen Entréespunkt a Metriken net verfügbar ginn, wat Datenlücken während deene selwechte Perioden verursaacht.
Dir kënnt och bemierken datt de Prometheus Exporter fir eng Sekonn ausschalt.
Mir kënnen Korrelatiounen mat Gerempels Kollektioun (GC) Notiz.
Konklusioun
TSDB am Prometheus 2 ass séier, fäeg Millioune vun Zäitreihen ze handhaben a gläichzäiteg Dausende vu Rekorder pro Sekonn mat zimlech bescheidenen Hardware. CPU an Disk I / O Notzung ass och beandrockend. Mäi Beispill huet bis zu 200 Metriken pro Sekonn pro Kär benotzt.
Fir Expansioun ze plangen, musst Dir iwwer genuch Quantitéiten Erënnerung erënneren, an dëst muss richteg Erënnerung sinn. D'Quantitéit un Erënnerung benotzt, déi ech observéiert hunn, war ongeféier 5 GB pro 100 Opzeechnungen pro Sekonn vum erakommende Stroum, deen zesumme mam Betribssystem Cache ongeféier 000 GB besat Erënnerung huet.
Natierlech ass et nach vill Aarbecht ze maachen fir CPU an Disk I/O Spikes ze zämmen, an dëst ass net iwwerraschend wann Dir bedenkt wéi jonk TSDB Prometheus 2 mat InnoDB, TokuDB, RocksDB, WiredTiger verglach gëtt, awer si hunn all ähnlech Problemer fréi an hirem Liewenszyklus.
Source: will.com