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

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

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

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

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

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

დიზაინი

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

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

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

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

დატკეპნები

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

თუ გსურთ მეტი გაიგოთ საცავის შესახებ, შეგიძლიათ იხილოთ 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
}

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

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

პროცესორის დატვირთვის პიკები

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

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

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

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

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-ის გამო. ერთადერთი გამოსავალი, რაც ვიპოვე, იყო მონაცემთა შეგროვების გამორთვა, სერვერის აწევა, აღდგენის მიცემა და გადატვირთვა ჩართული შეგროვებით.

Გათბობა

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

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

პროცესორის დატვირთვის პიკები

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

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

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

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

დასკვნა

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

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

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

წყარო: www.habr.com