პრომეთეს მონაცემთა შენახვის არჩევა: Thanos vs VictoriaMetrics

Სალამი ყველას. ქვემოთ მოცემულია ჩანაწერი ანგარიში Big Monitoring Meetup 4-დან.

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

ანგარიშში იქნება შედარება Thanos и VictoriaMetrics — პრომეთეს მეტრიკის გრძელვადიანი შენახვის პროექტები.

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

პრომეთეს შეზღუდვები:

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

ამ პრობლემების/გამოწვევების გადაწყვეტა?

გადაწყვეტილებებია:

• Thanos
• VictoriaMetrics
• Uber M3
• Cortex

ყველა ეს გადაწყვეტა არის პრომეთეს მიერ შეგროვებული მონაცემების დისტანციური შენახვისთვის. ისინი წყვეტენ წინა სლაიდიდან დისტანციური შენახვის პრობლემას სხვადასხვა გზით. ამ პრეზენტაციაში მე ვისაუბრებ მხოლოდ პირველ ორ გამოსავალზე: Thanos и VictoriaMetrics.

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

თანოსი იღებს მონაცემებს, რომლებიც პრომეთემ შეინახა ადგილობრივ დისკზე და აკოპირებს მას S3-ზე, GCS ან სხვა ობიექტის შესანახად.

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

Thanos მხარს უჭერს PromQL და Prometheus querying API.

თანოსი იყენებს პრომეთეს კოდს მონაცემების შესანახად.

Thanos შემუშავებულია იმავე დეველოპერების მიერ, როგორც Prometheus.

on VictoriaMetrics. აქ ლინკები, სადაც პირველად ვისაუბრეთ VictoriaMetrics.

VictoriaMetrics იღებს მონაცემებს რამდენიმე პრომეთესგან დისტანციური ჩაწერის API პრომეთეს მიერ მხარდაჭერილი პროტოკოლი.

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

VictoriaMetrics ასევე მხარს უჭერს, როგორიცაა Thanos, PromQL და Prometheus querying API.

Thanos-ისგან განსხვავებით, VictoriaMetrics-ის წყაროს კოდი იწერება ნულიდან და ოპტიმიზებულია სიჩქარისა და რესურსების მოხმარებისთვის.

VictoriaMetrics, Thanos-ისგან განსხვავებით, მასშტაბებია როგორც ვერტიკალურად, ასევე ჰორიზონტალურად. ჭამე ერთი კვანძის ვერსია, რომელიც მასშტაბებს ვერტიკალურად. შეგიძლიათ დაიწყოთ ერთი პროცესორით და 1 გბ მეხსიერებით და თანდათან გაიზარდოთ ასობით პროცესორამდე და 1 ტბ მეხსიერებამდე. VictoriaMetrics-ს შეუძლია გამოიყენოს ყველა ეს რესურსი. მისი შესრულება დაახლოებით 100-ჯერ გაიზრდება 1 ბირთვიან სისტემასთან შედარებით.

Thanos-ის ისტორია დაიწყო 2017 წლის ნოემბერში, როდესაც გამოჩნდა პირველი საჯარო ვალდებულება. მანამდე თანოსი შინაგანად იყო განვითარებული წარმოუდგენელია.io.

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

იმავე 2019 წლის ივნისში მათ გაგზავნეს განაცხადის ნომერი 256 в Cloud Native Computing Foundation.

და რამდენიმე თვის შემდეგ თანოსი მიიღეს Cloud Native Computing Foundation, რომელიც მოიცავს Prometheus, Kubernetes და სხვა პოპულარულ პროექტებს.

2018 წლის იანვარში დაიწყო VictoriaMetrics-ის განვითარება.

2018 წლის სექტემბერში საჯაროდ ვახსენე VictoriaMetrics პირველად.

2018 წლის დეკემბერში გამოქვეყნდა ერთი კვანძის ვერსია.

მაისის თვეში გამოიცა როგორც ერთკვანძოვანი, ასევე კლასტერული ვერსიების წყაროები.

2019 წლის ივნისში, ისევე როგორც თანოსმა, ჩვენ შევიტანეთ განაცხადი CNCF ფონდში ნომრით 255. თანოსის განცხადებამდე ერთი დღით ადრე მივმართეთ.

მაგრამ, სამწუხაროდ, იქ ჯერ კიდევ არ მიგვიღია. საჭიროა საზოგადოების დახმარება.

მოდით შევხედოთ ყველაზე მნიშვნელოვან სლაიდებს, რომლებიც აჩვენებს Thanos-ისა და VictoriaMetrics-ის არქიტექტურას.

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

ასევე არსებობს ისეთი კომპონენტი, როგორიცაა Thanos Store Gateway, რომელსაც შეუძლია წაიკითხოს ეს მონაცემები Object Storage-დან Thanos Query-დან შემომავალი მოთხოვნის შემთხვევაში. Thanos Query ახორციელებს PromQL და Prometheus API-ს. ანუ გარედან პრომეთეს ჰგავს. იღებს PromQL შეკითხვებს, აგზავნის მათ Thanos Store Gateway-ში, Thanos Store Gateway იღებს საჭირო მონაცემებს Object Storage-დან, აგზავნის უკან.

მაგრამ ჩვენ ვინახავთ მონაცემებს Object Storage-ში ბოლო ორი საათის გარეშე Thanos Sidecar-ის იმპლემენტაციის ფუნქციის გამო, რომელიც ვერ ატვირთავს ბოლო ორ საათს Object Storage S3-ში, რადგან პრომეთეს ჯერ არ შეუქმნია ფაილები ამ ორი საათის განმავლობაში ადგილობრივ მეხსიერებაში.

როგორ გადაწყვიტეთ ამის გარკვევა? Thanos Query, Thanos Store Gateway-ის მიმართ მოთხოვნების გარდა, პარალელურად აგზავნის მოთხოვნებს თითოეულ Thanos Sidecar-ს, რომელიც მდებარეობს პრომეთეს გვერდით.

და Thanos Sidecar, თავის მხრივ, პროქსი ითხოვს პრომეთეს და იღებს მონაცემებს ბოლო ორი საათის განმავლობაში.

ამ კომპონენტების გარდა, არის ასევე არჩევითი კომპონენტი, რომლის გარეშეც Thanos არ იმუშავებს კარგად. ეს არის Thanos Compact, რომელიც პასუხისმგებელია Object Storage-ზე მცირე ფაილების გაერთიანებაზე უფრო დიდ ფაილებად, რომლებიც აქ იყო ატვირთული Thanos Sidecars-ის მიერ. Thanos Sidecar ატვირთავს მონაცემთა ფაილებს იქ ორ საათში. ეს ფაილები, თუ ისინი არ არის გაერთიანებული უფრო დიდ ფაილებში, მაშინ მათი რაოდენობა შეიძლება მნიშვნელოვნად გაიზარდოს. რაც უფრო მეტია ასეთი ფაილი, მით მეტი მეხსიერებაა საჭირო Thanos Store Gateway-ისთვის, მით მეტი რესურსია საჭირო ქსელში მონაცემებისა და მეტამონაცემების გადასატანად. Thanos Store Gateway ხდება არაეფექტური. აქედან გამომდინარე, აუცილებელია Thanos Compact-ის გაშვება, რომელიც აერთიანებს პატარა ფაილებს უფრო დიდ ფაილებს, რათა ნაკლები იყოს ასეთი ფაილები და შეამციროს ზედნადები Thanos Store Gateway-ზე.

ასევე არსებობს ისეთი კომპონენტი, როგორიცაა Thanos Ruler. ის ახორციელებს პრომეთეს გაფრთხილების წესებს და შეუძლია შეაფასოს პრომეთეს ჩაწერის წესები, რათა დაწეროს მონაცემები Object Storage-ში. მაგრამ ამ კომპონენტის გამოყენება არ არის რეკომენდებული, რადგან... ის არასრული მონაცემების დაბრუნებას ცდილობს.

ეს არის Thanos-ის მარტივი სქემა.

ახლა მოდით შევადაროთ იგი VictoriaMetrics-ის სქემას.

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

კლასტერული ვერსია უფრო რთულია. მის შიგნით არის სამი განსხვავებული კომპონენტი: vmselect, vminsert და vmstorage. მათი სახელებიდან ნათელი უნდა იყოს, რას აკეთებს თითოეული მათგანი. Insert კომპონენტი იღებს მონაცემებს სხვადასხვა ფორმატში: Prometheus დისტანციური ჩაწერის API-დან, Influx ხაზის პროტოკოლიდან, გრაფიტის პროტოკოლიდან და OpenTSDB პროტოკოლიდან. Insert კომპონენტი იღებს მათ, აანალიზებს მათ და ანაწილებს არსებულ შენახვის კომპონენტებს შორის, სადაც მონაცემები უკვე ინახება. Select კომპონენტი, თავის მხრივ, იღებს PromQL შეკითხვებს. ის ახორციელებს PromQL, ისევე როგორც Prometheus querying API და ის შეიძლება გამოყენებულ იქნას როგორც Prometheus-ის შემცვლელი Grafana-ში ან სხვა Prometheus API კლიენტებში. Select იღებს promql მოთხოვნას, აანალიზებს მას, კითხულობს ამ მოთხოვნის შესასრულებლად აუცილებელ მონაცემებს შენახვის კვანძებიდან, ამუშავებს ამ მონაცემებს და აბრუნებს პასუხს.

მოდით შევადაროთ Thanos-ისა და VictoriaMetrics-ის ინსტალაციის სირთულე.

დავიწყოთ თანოსით. სანამ Thanos-თან მუშაობას დაიწყებდეთ, თქვენ უნდა შექმნათ bucket Object Storage-ში, როგორიცაა S3 ან GCS, რათა Thanos Sidecar-მა შეძლოს მასზე მონაცემების ჩაწერა.

შემდეგ თითოეული პრომეთესთვის თქვენ უნდა დააინსტალიროთ Thanos Sidecar. მანამდე, თქვენ უნდა გახსოვდეთ, რომ გამორთოთ მონაცემთა დატკეპნა Prometheus-ში. მონაცემთა შეკუმშვა პერიოდულად შეკუმშავს მონაცემებს ადგილობრივ პრომეთეს საცავში, რათა შეამციროს რესურსების მოხმარება.

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

აქედან გამომდინარე, Thanos რეკომენდაციას უწევს მონაცემთა შენახვის დროის შემცირებას ადგილობრივ საცავში 6-8 საათამდე, რათა შემცირდეს დიდი რაოდენობით მცირე ბლოკების ზედნადები.

Thanos Sidecar-ის ინსტალაციის შემდეგ, თქვენ უნდა დააინსტალიროთ ორი კომპონენტი თითოეული ობიექტის შენახვის თაიგულისთვის. ეს არის Thanos Compactor და Thanos Store Gateway.

ამის შემდეგ, თქვენ უნდა დააინსტალიროთ Thanos Query და დააკონფიგურიროთ ისე, რომ მას შეეძლოს დაუკავშირდეს Thanos Store Gateway-ს, რომელიც თქვენ გაქვთ, ასევე შეუძლია დაუკავშირდეს ყველა Thanos Sidecar-ს.

აქ შეიძლება იყოს მცირე პრობლემა.

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

თუ თქვენ გაქვთ მრავალი ასეთი მონაცემთა ცენტრი, მაშინ, შესაბამისად, მთელი სისტემის საიმედოობა მცირდება. ვინაიდან Thanos Query მუდმივად უნდა ინარჩუნებდეს კავშირებს Thanos Sidecar-თან, რომლებიც მდებარეობს სხვადასხვა მონაცემთა ცენტრში. ყოველი შემომავალი მოთხოვნისთვის, ის გადასცემს მოთხოვნებს ყველა Thanos Sidecar-ისკენ. თუ კავშირი შეწყდება, თქვენ მიიღებთ მონაცემთა არასრულ კრებულს, ან მიიღებთ პასუხს „კლასტერი გათიშულია“.

VictoriaMetrics-ში ყველაფერი ცოტა უფრო მარტივია. ერთი კვანძის ვერსიისთვის, თქვენ უბრალოდ უნდა გაუშვათ ერთი ორობითი და ყველაფერი მუშაობს.

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

მას შემდეგ რაც გაუშვით ერთი ორობითი ან კლასტერული ვერსია, თქვენ უბრალოდ უნდა დაამატოთ პრომეთე კონფიგურაციაში დისტანციური ჩაწერის url-ის პარამეტრიისე, რომ ლოკალური შენახვისა და დისტანციური შენახვის პარალელურად იწყებს მონაცემთა ჩაწერას. როგორც ხედავთ, ეს კონფიგურაცია ბევრად უფრო საიმედოდ უნდა შესრულდეს Thanos-ის კონფიგურაციასთან შედარებით. ჩვენ არ გვჭირდება კავშირის შენარჩუნება VictoriaMetrics-დან ყველა პრომეთესთან, რადგან თავად პრომეთე უკავშირდება VictoriaMetrics-ს და გადასცემს მონაცემებს.

განვიხილოთ Thanos-ისა და VictoriaMetrics-ის მხარდაჭერა.

Thanos-ს სჭირდება Sidecar-ის მონიტორინგი, რათა დარწმუნდეს, რომ ისინი არ შეწყვეტენ მონაცემთა ჩატვირთვას Object Storage-ში. მათ შეიძლება შეაჩერონ მონაცემების ჩამოტვირთვა ჩამოტვირთვის შეცდომების გამო, მაგალითად, თქვენი ქსელის კავშირი Object Storage-თან დროებით შეწყვეტილია, ან Object Storage დროებით მიუწვდომელია. Thanos Sidecar შეამჩნევს ამას ამ მომენტში, შეატყობინებს შეცდომის შესახებ, შეიძლება დაჯდეს და შემდეგ შეწყვიტოს მუშაობა. თუ არ აკონტროლებთ, მაშინ შეწყვეტთ მონაცემთა გადაცემას Object Storage-ში. თუ შენახვის დრო გადის (რეკომენდებულია 6-8 საათი), მაშინ დაკარგავთ მონაცემებს, რომლებიც არ აღმოჩნდა Object Storage-ში.

Thanos კომპაქტორებმა შეიძლება შეწყვიტონ მუშაობა იმის გამო რბოლა Sidecar-ით. კომპაქტორები იღებენ მონაცემებს Object Storage-დან და აერთიანებენ მას უფრო დიდ მონაცემებად. ვინაიდან კომპაქტორები არ არის სინქრონიზებული Sidecars-თან, ეს შეიძლება მოხდეს: Sidecar-ს ჯერ არ ჰქონდა დრო ბლოკის დასასრულებლად, Compactor გადაწყვეტს, რომ ეს ბლოკი მთლიანად დაიწერა. კომპაქტორი იწყებს მის კითხვას. ის არ კითხულობს ბლოკს სრულად და წყვეტს მუშაობას. Იხილეთ დეტალები აქ.

Store Gateway-მა შესაძლოა დააბრუნოს არათანმიმდევრული მონაცემები Compactor-სა და Sidecars-ს შორის რბოლების გამო. იგივე ხდება აქაც, რადგან Store Gateway არანაირად არ არის სინქრონიზებული Compactors-თან და Sidecars-თან. შესაბამისად, რასის პირობები შეიძლება მოხდეს, როდესაც Store Gateway ვერ ხედავს მონაცემთა ნაწილს ან ხედავს არასაჭირო მონაცემებს.

Query კომპონენტი Thanos-ში ნაგულისხმევად აბრუნებს ნაწილობრივ შედეგს, თუ ზოგიერთი Sidecars ან Store Gateways ამჟამად მიუწვდომელია. თქვენ მიიღებთ მონაცემების ნაწილს და არც კი იცით, რომ არ მიგიღიათ ყველა მონაცემი. სტანდარტულად ასე მუშაობს. ანალოგიურ სიტუაციაში, VictoriaMetrics აბრუნებს მონიშნულ მონაცემებს, როგორც ნაწილობრივ.

Thanos-ისგან განსხვავებით, VictoriaMetrics იშვიათად კარგავს მონაცემებს. მაშინაც კი, თუ კავშირი პრომეთიდან VictoriaMetrics-თან შეწყდება, ეს არ არის პრობლემა, რადგან პრომეთე აგრძელებს შემოსული ახალი მონაცემების ჩაწერას Write Ahead Log-ში, რომლის ზომაა 2 საათი. თუ აღადგენთ თქვენს კავშირს VictoriaMetrics-თან ორი საათის განმავლობაში, თქვენი მონაცემები არ დაიკარგება. პრომეთე შეუძლია მონაცემების დამატება VictoriaMetrics-თან კავშირის აღდგენის შემდეგ.

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

Kubernetes ავტომატურად მართავს კლასტერს, Thanos-ისგან განსხვავებით. Thanos-ის ყველა კომპონენტის ერთ Kubernetes კლასტერში მოთავსება რთულია, განსხვავებით VictoriaMetrics კლასტერის კომპონენტებისგან.

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

VictoriaMetrics ძალიან აადვილებს კლასტერის გაფართოებას. უბრალოდ დაამატეთ საჭირო კომპონენტები და განაგრძეთ მუშაობა.

Thanos-სა და VictoriaMetrics-ში არსებული პრობლემების შესახებ.

თანოსს აქვს შემდეგი ხარვეზები. პრომეთემ უნდა შეინახოს მონაცემები ბოლო ორი საათის განმავლობაში. თუ ისინი დაიკარგებიან, თქვენ მათ მთლიანად დაკარგავთ, რადგან ისინი ჯერ არ არის დაწერილი Object Storage-ში, როგორიცაა S3.

Store Gateway კომპონენტს და კომპაქტორის კომპონენტს შეიძლება დასჭირდეს დიდი მეხსიერება, რომ იმუშაოს დიდ Object Storage-თან, თუ იქ ბევრი პატარა ფაილია შენახული. რაც უფრო დიდია ფაილების რაოდენობა და ზომა, მით მეტია Store Gateway და კომპაქტორის ოპერატიული მეხსიერება მეტაინფორმაციის შესანახად. თანოსს ბევრი პრობლემა აქვს ამასთან დაკავშირებით Store Gateway-ისა და კომპაქტორის ავარია ჩაწერილი მონაცემების საშუალო მოცულობით.

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

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

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

VictoriaMetrics-ს ასევე აქვს ხარვეზები. პირველი პრობლემა არის ვარიანტი, რომელიც ზღუდავს ოპერატიული მეხსიერების რაოდენობას VictoriaMetrics ქეშისთვის. ნაგულისხმევად, ის უდრის ოპერატიული მეხსიერების 60%-ს იმ აპარატზე, სადაც გაშვებულია VictoriaMetrics, ან კუბერნეტში VictoriaMetrics pod-ის RAM-ის 60%-ს.

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

მეორე ვარიანტი. ეს არის RetentionPeriod - პერიოდი, რომელიც ნაგულისხმევად დაყენებულია 1 თვეზე. ეს არის VictoriaMetrics-ის მონაცემების შენახვის ხანგრძლივობა. ამ პერიოდის შემდეგ VictoriaMetrics წაშლის მონაცემებს.

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

მოდით შევხედოთ უნიკალურ მახასიათებლებს.

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

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

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

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

VictoriaMetrics-ის მთავარი მახასიათებელია MetricsQL. ეს არის VictoriaMetrics გაფართოებები PromQL-სთვის, რაზეც მე ვისაუბრე წინა დიდი მონიტორინგის შეხვედრაზე.

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

VictoriaMetrics-ის მონაცემები გაცილებით ნაკლებ ადგილს იკავებს თანოსთან და პრომეთესთან შედარებით.

თუ რეალურ მონაცემებს ჩაწერთ, მომხმარებლები საუბრობენ დისკზე მონაცემების ზომის 2-5-ჯერ შემცირებაზე პრომეთესთან და თანოსთან შედარებით.

VictoriaMetrics-ის კიდევ ერთი უპირატესობა ის არის, რომ ის ოპტიმიზებულია სიჩქარისთვის.

მოდით შევხედოთ ინფრასტრუქტურის ღირებულებას.

Thanos-ის ერთ-ერთი უპირატესობა ის არის, რომ ის ინახავს მონაცემებს ობიექტების საცავში, რაც შედარებით იაფია.

ობიექტების საცავში მონაცემების შენახვისას, თქვენ უნდა გადაიხადოთ მონაცემთა ჩაწერისა და წაკითხვის ოპერაციებისთვის ($10 მილიონ ოპერაციაზე). როდესაც წერთ მონაცემებს ობიექტების შესანახად, თქვენ იხდით თქვენს ჰოსტინგის ხარჯებს ინტერნეტში მონაცემების ატვირთვისთვის, თუ თქვენი კლასტერი არ არის AWS-ში, ის იქ უფასოა. როდესაც კითხულობთ მონაცემებს, იხდით $10-დან $230-მდე 1TB-ზე. ეს შეიძლება იყოს მნიშვნელოვანი, თუ ხშირად იკითხავთ ისტორიულ მონაცემებს Thanos კლასტერიდან.

Thanos კლასტერისთვის, თქვენ უნდა გადაიხადოთ სერვერებისთვის Compact, Store Gateway, Query კომპონენტები, რომლებიც საჭიროებენ დიდ მეხსიერებას და CPU დიდი რაოდენობით მონაცემებისთვის.

VictoriaMetrics-ს აქვს შემდეგი ხარჯები. თუ თქვენ ინახავთ მონაცემებს GCE HDD დისკებზე, მაშინ ის გამოდის $40 1TB. VictoriaMetrics-ისთვის საკმარისია ჩვეულებრივი HDD დისკები, რომლებიც ხუთჯერ მეტი ღირს. VictoriaMetrics ოპტიმიზებულია HDD-სთვის.

VictoriaMetrics საჭიროებს სერვერებს კომპონენტებისთვის: Single-nod ან კლასტერული კომპონენტები, რომლებიც Thanos-ის კომპონენტებისგან განსხვავებით, გაცილებით ნაკლებ პროცესორს და RAM-ს მოითხოვს - შესაბამისად, ეს უფრო იაფი იქნება.

განხორციელების მაგალითები.

თანოსს აქვს განხორციელების მაგალითი Gitlab-ში. Gitlab მუშაობს მთლიანად Thanos-ზე. მაგრამ იქ ყველაფერი ასე გლუვი არ არის. თუ მათ შეხედავთ საკითხები, მაშინ ხედავთ, რომ მათ მუდმივად აქვთ გარკვეული ოპერაციული პრობლემები Thanos-თან: არ არის საკმარისი მეხსიერება Store Gateway ან Query კომპონენტებისთვის. მათ მუდმივად უწევთ მეხსიერების რაოდენობის გაზრდა.

ამის გამო იზრდება ამ პრობლემების გადაჭრის ხარჯები.

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

VictoriaMetrics-ს აქვს საჯარო განხორციელების მაგალითები:

• wix.com ვებსაიტის შემქმნელი
• Adidas ახორციელებს VictoriaMetrics-ს და პრეზენტაციაც კი გააკეთა ბოლო PromCon 2019-ზე
• TrafficStars - სარეკლამო ქსელი
• Seznam.cz არის პოპულარული ჩეხური საძიებო სისტემა.

და მაშინ იყო უსახელო კომპანიები, რომლებსაც ახლა ვერ დავასახელებ. თანხმობა არ მიიღეს.

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

დასკვნები.

VictoriaMetrics და Thanos წყვეტენ მსგავს პრობლემებს, მაგრამ სხვადასხვა გზით:

• გლობალური შეკითხვის ხედი
• ჰორიზონტალური სკალირება
• თვითნებური შეკავება

დიდი მადლობა.

გელოდებით ჩვენთან ტელეგრამის არხი.

გამოკითხვაში მონაწილეობა შეუძლიათ მხოლოდ დარეგისტრირებულ მომხმარებლებს. Შებრძანდითგთხოვთ

რას იყენებთ პრომეთეს გრძელვადიან შესანახად?

• 35,3%თანოსი 6

• 0,0%კორტექსი 0

• 0,0%M3DB0

• 41,2%VictoriaMetrics7

• 23,5%სხვა 4

მისცა ხმა 17 მომხმარებელმა. 16-მა მომხმარებელმა თავი შეიკავა.

წყარო: www.habr.com