TSDB ანალიზი პრომეთე 2-ში

დროის სერიების მონაცემთა ბაზა (TSDB) Prometheus 2-ში არის საინჟინრო გადაწყვეტის შესანიშნავი მაგალითი, რომელიც გვთავაზობს მნიშვნელოვან გაუმჯობესებას v2 საცავთან შედარებით Prometheus 1-ში მონაცემთა დაგროვების სიჩქარის, შეკითხვის შესრულებისა და რესურსების ეფექტურობის თვალსაზრისით. ჩვენ ვახორციელებდით Prometheus 2-ს Percona Monitoring and Management-ში (PMM) და მე მქონდა შესაძლებლობა გამეგო Prometheus 2 TSDB-ის შესრულება. ამ სტატიაში მე ვისაუბრებ ამ დაკვირვების შედეგებზე.

პრომეთეს საშუალო დატვირთვა

მათთვის, ვინც გამოიყენება ზოგადი დანიშნულების მონაცემთა ბაზებთან, ტიპიური პრომეთეს დატვირთვა საკმაოდ საინტერესოა. მონაცემთა დაგროვების ტემპი სტაბილურია: ჩვეულებრივ, სერვისები, რომლებსაც თქვენ აკვირდებით, აგზავნიან დაახლოებით იგივე რაოდენობის მეტრებს და ინფრასტრუქტურა იცვლება შედარებით ნელა.
ინფორმაციის მოთხოვნა შეიძლება სხვადასხვა წყაროდან მოდიოდეს. ზოგიერთი მათგანი, როგორიცაა გაფრთხილებები, ასევე ისწრაფვის სტაბილური და პროგნოზირებადი მნიშვნელობისკენ. სხვებმა, როგორიცაა მომხმარებლის მოთხოვნები, შეიძლება გამოიწვიოს აფეთქებები, თუმცა ეს ასე არ არის სამუშაო დატვირთვის უმეტესობისთვის.

დატვირთვის ტესტი

ტესტირების დროს ყურადღება გავამახვილე მონაცემების დაგროვების უნარზე. მე განვათავსე Prometheus 2.3.2, რომელიც შედგენილია Go 1.10.1-ით (როგორც PMM 1.14-ის ნაწილი) Linode სერვისზე ამ სკრიპტის გამოყენებით: StackScript. ყველაზე რეალისტური დატვირთვის გენერირებისთვის, ამის გამოყენებით StackScript მე გავუშვი რამდენიმე MySQL კვანძი რეალური დატვირთვით (Sysbench TPC-C Test), რომელთაგან თითოეული ემულირებულია 10 Linux/MySQL კვანძზე.
ყველა შემდეგი ტესტი ჩატარდა Linode სერვერზე რვა ვირტუალური ბირთვით და 32 გბ მეხსიერებით, აწარმოებდა 20 დატვირთვის სიმულაციას ორასი MySQL ინსტანციის მონიტორინგზე. ან პრომეთეს თვალსაზრისით, 800 სამიზნე, 440 სკრაპი წამში, 380 ათასი ჩანაწერი წამში და 1,7 მილიონი აქტიური დროის სერია.

დიზაინი

ტრადიციული მონაცემთა ბაზების ჩვეულებრივი მიდგომა, მათ შორის პრომეთე 1.x-ის მიერ გამოყენებული, არის მეხსიერების ლიმიტი. თუ ეს არ არის საკმარისი დატვირთვის გატარება, თქვენ განიცდით მაღალ შეფერხებებს და ზოგიერთი მოთხოვნა წარუმატებელი იქნება. მეხსიერების გამოყენება Prometheus 2-ში კონფიგურირებადია გასაღების საშუალებით storage.tsdb.min-block-duration, რომელიც განსაზღვრავს რამდენ ხანს შეინახება ჩანაწერები მეხსიერებაში დისკზე ჩასვლამდე (ნაგულისხმევი არის 2 საათი). საჭირო მეხსიერების რაოდენობა დამოკიდებული იქნება წმინდა შემომავალ ნაკადში დამატებული დროის სერიების, ეტიკეტებისა და ნაკაწრების რაოდენობაზე. დისკის სივრცის თვალსაზრისით, პრომეთე მიზნად ისახავს გამოიყენოს 3 ბაიტი თითო ჩანაწერზე (ნიმუში). მეორეს მხრივ, მეხსიერების მოთხოვნები გაცილებით მაღალია.

მიუხედავად იმისა, რომ შესაძლებელია ბლოკის ზომის კონფიგურაცია, არ არის რეკომენდირებული მისი ხელით კონფიგურაცია, ამიტომ იძულებული ხართ მისცეთ პრომეთეს იმდენი მეხსიერება, რამდენიც მას სჭირდება თქვენი დატვირთვისთვის.
თუ არ არის საკმარისი მეხსიერება მეტრიკის შემომავალი ნაკადის მხარდასაჭერად, პრომეთე ამოვარდება მეხსიერებიდან ან OOM მკვლელი მიიღებს მას.
სვოპის დამატება ავარიის დაყოვნებისთვის, როდესაც პრომეთეს მეხსიერება ამოიწურება, ნამდვილად არ დაგვეხმარება, რადგან ამ ფუნქციის გამოყენება იწვევს მეხსიერების ფეთქებად მოხმარებას. მე ვფიქრობ, რომ ეს რაღაც კავშირშია Go-სთან, მის ნაგვის შემგროვებელთან და მის გაცვლასთან.
კიდევ ერთი საინტერესო მიდგომა არის სათავე ბლოკის კონფიგურაცია, რათა დისკზე გადაიწუროს გარკვეულ დროს, იმის ნაცვლად, რომ დათვალოთ იგი პროცესის დაწყებიდან.

როგორც გრაფიკიდან ხედავთ, დისკზე გამორთვა ხდება ყოველ ორ საათში ერთხელ. თუ შეცვლით მინ-ბლოკის ხანგრძლივობის პარამეტრს ერთ საათზე, მაშინ ეს გადატვირთვები მოხდება ყოველ საათში, ნახევარი საათის შემდეგ.
თუ გსურთ გამოიყენოთ ეს და სხვა გრაფიკები თქვენს პრომეთეს ინსტალაციაში, შეგიძლიათ გამოიყენოთ ეს დაფა. იგი შექმნილია PMM-ისთვის, მაგრამ მცირე ცვლილებებით ჯდება პრომეთეს ნებისმიერ ინსტალაციაში.
ჩვენ გვაქვს აქტიური ბლოკი სახელწოდებით head block, რომელიც ინახება მეხსიერებაში; ბლოკები ძველი მონაცემებით ხელმისაწვდომია მეშვეობით mmap(). ეს გამორიცხავს ქეშის ცალკე კონფიგურაციის აუცილებლობას, მაგრამ ასევე ნიშნავს, რომ თქვენ უნდა დატოვოთ საკმარისი ადგილი ოპერაციული სისტემის ქეშისთვის, თუ გსურთ მოიძიოთ უფრო ძველი მონაცემები, ვიდრე თავდაპირველი ბლოკი იტევს.
ეს ასევე ნიშნავს, რომ პრომეთეს ვირტუალური მეხსიერების მოხმარება საკმაოდ მაღალი იქნება, რაც არ არის სანერვიულო.

დიზაინის კიდევ ერთი საინტერესო წერტილი არის WAL-ის გამოყენება (წინასწარ ჩაწერე ჟურნალი). როგორც შენახვის დოკუმენტაციიდან ხედავთ, პრომეთე იყენებს WAL-ს ავარიების თავიდან ასაცილებლად. მონაცემთა გადარჩენის გარანტიის სპეციფიკური მექანიზმები, სამწუხაროდ, კარგად არ არის დოკუმენტირებული. Prometheus-ის ვერსია 2.3.2 ყოველ 10 წამში ათავსებს WAL-ს დისკზე და ეს პარამეტრი არ არის კონფიგურირებადი მომხმარებლისთვის.

სატკეპნები

Prometheus TSDB შექმნილია როგორც LSM (Log Structured Merge) მაღაზია: სათავე ბლოკი პერიოდულად ირეცხება დისკზე, ხოლო დატკეპნის მექანიზმი აერთიანებს მრავალ ბლოკს ერთად, რათა თავიდან აიცილოს ზედმეტი ბლოკების სკანირება შეკითხვის დროს. აქ შეგიძლიათ იხილოთ ბლოკების რაოდენობა, რომელიც მე დავაკვირდი ტესტის სისტემაზე დატვირთვის დღის შემდეგ.

თუ გსურთ გაიგოთ მეტი მაღაზიის შესახებ, შეგიძლიათ შეისწავლოთ meta.json ფაილი, რომელიც შეიცავს ინფორმაციას ხელმისაწვდომი ბლოკების შესახებ და როგორ გაჩნდა ისინი.

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

პრომეთეს შეკუმშვა უკავშირდება იმ დროს, როდესაც თავსაბურავი დისკზე ჩამოირეცხება. ამ ეტაპზე შეიძლება ჩატარდეს რამდენიმე ასეთი ოპერაცია.

როგორც ჩანს, შეკუმშვა არანაირად არ არის შეზღუდული და შეიძლება გამოიწვიოს დისკის I/O დიდი მწვერვალები შესრულების დროს.

CPU დატვირთვის მწვერვალები

რა თქმა უნდა, ეს საკმაოდ უარყოფით გავლენას ახდენს სისტემის სიჩქარეზე და ასევე წარმოადგენს სერიოზულ გამოწვევას LSM შენახვისთვის: როგორ გავაკეთოთ დატკეპნა მაღალი მოთხოვნის განაკვეთების მხარდასაჭერად ზედმეტი ზედმეტი ხარჯების გარეშე?
მეხსიერების გამოყენება დატკეპნის პროცესში ასევე საკმაოდ საინტერესო გამოიყურება.

ჩვენ ვხედავთ, თუ როგორ, დატკეპნის შემდეგ, მეხსიერების უმეტესობა ცვლის მდგომარეობას ქეშიდან თავისუფალზე: ეს ნიშნავს, რომ პოტენციურად ღირებული ინფორმაცია ამოღებულია იქიდან. საინტერესოა, გამოიყენება თუ არა აქ fadvice() ან მინიმიზაციის სხვა ტექნიკა, ან იმიტომ, რომ ქეში გათავისუფლდა დატკეპნის დროს განადგურებული ბლოკებისგან?

აღდგენა წარუმატებლობის შემდეგ

წარუმატებლობისგან აღდგენას დრო სჭირდება და კარგი მიზეზის გამო. წამში მილიონი ჩანაწერის შემომავალი ნაკადისთვის მომიწია 25 წუთი ლოდინი, სანამ აღდგენა განხორციელდა 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."

აღდგენის პროცესის მთავარი პრობლემა მეხსიერების მაღალი მოხმარებაა. იმისდა მიუხედავად, რომ ნორმალურ ვითარებაში სერვერს შეუძლია სტაბილურად იმუშაოს იმავე რაოდენობის მეხსიერებით, თუ ის ავარიულია, ის შეიძლება ვერ აღდგეს OOM-ის გამო. ერთადერთი გამოსავალი, რომელიც ვიპოვე, იყო მონაცემთა შეგროვების გამორთვა, სერვერის ამუშავება, მისი აღდგენა და გადატვირთვა ჩართული კოლექციით.

Გათბობა

კიდევ ერთი ქცევა, რომელიც უნდა გვახსოვდეს გახურების დროს, არის კავშირი დაბალ შესრულებასა და რესურსების მაღალ მოხმარებას შორის დაწყებისთანავე. ზოგიერთი, მაგრამ არა ყველა დაწყების დროს, მე დავაკვირდი სერიოზულ დატვირთვას CPU-ზე და მეხსიერებაზე.

მეხსიერების გამოყენების ხარვეზები მიუთითებს იმაზე, რომ პრომეთეს თავიდანვე არ შეუძლია ყველა კოლექციის კონფიგურაცია და გარკვეული ინფორმაცია იკარგება.
მე არ გავარკვიე მაღალი CPU და მეხსიერების დატვირთვის ზუსტი მიზეზები. მე ეჭვი მაქვს, რომ ეს გამოწვეულია ახალი დროის სერიების შექმნით სათავე ბლოკში მაღალი სიხშირით.

CPU დატვირთვა იზრდება

გარდა შეკუმშვისა, რომელიც ქმნის საკმაოდ მაღალ I/O დატვირთვას, ყოველ ორ წუთში ერთხელ შევამჩნიე CPU დატვირთვის სერიოზული მწვერვალები. აფეთქებები უფრო გრძელია, როდესაც შეყვანის ნაკადი მაღალია და, როგორც ჩანს, გამოწვეულია Go-ს ნაგვის შემგროვებლის მიერ, მინიმუმ რამდენიმე ბირთვი სრულად დატვირთული.

ეს ნახტომები არც ისე უმნიშვნელოა. როგორც ჩანს, როდესაც ეს ხდება, პრომეთეს შიდა შესვლის წერტილი და მეტრიკა მიუწვდომელია, რაც იწვევს მონაცემთა ხარვეზებს დროის იმავე პერიოდებში.

თქვენ ასევე შეგიძლიათ შეამჩნიოთ, რომ პრომეთეს ექსპორტიორი ერთი წამით ითიშება.

ჩვენ შეგვიძლია შევამჩნიოთ კორელაცია ნაგვის შეგროვებასთან (GC).

დასკვნა

TSDB პრომეთე 2-ში არის სწრაფი, რომელსაც შეუძლია მილიონობით დროის სერია და ამავე დროს ათასობით ჩანაწერი წამში საკმაოდ მოკრძალებული აპარატურის გამოყენებით. CPU და დისკის I/O გამოყენება ასევე შთამბეჭდავია. ჩემმა მაგალითმა აჩვენა 200-მდე მეტრიკა წამში გამოყენებული ბირთვზე.

გაფართოების დასაგეგმად, თქვენ უნდა გახსოვდეთ საკმარისი რაოდენობის მეხსიერება და ეს უნდა იყოს რეალური მეხსიერება. გამოყენებული მეხსიერების რაოდენობა, რომელიც მე დავაკვირდი, იყო დაახლოებით 5 GB შემომავალი ნაკადის 100 ჩანაწერზე წამში, რომელიც ოპერაციული სისტემის ქეშთან ერთად იძლეოდა დაახლოებით 000 GB დაკავებულ მეხსიერებას.

რა თქმა უნდა, ჯერ კიდევ ბევრი სამუშაოა გასაკეთებელი CPU და დისკის I/O მწვერვალების შესამცირებლად და ეს გასაკვირი არ არის, თუ გავითვალისწინებთ რამდენად ახალგაზრდა TSDB Prometheus 2 შედარებით InnoDB, TokuDB, RocksDB, WiredTiger, მაგრამ მათ ყველას ჰქონდათ მსგავსი. პრობლემები მათი ცხოვრების ციკლის დასაწყისში.

წყარო: www.habr.com