VictoriaMetrics და პირადი ღრუბლოვანი მონიტორინგი. პაველ კოლობაევი

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

მე მქვია კოლობაევი პაველი. DevOps, SRE, LeroyMerlin, ყველაფერი კოდის მსგავსია - ეს ყველაფერი ჩვენზეა: ჩემზე და LeroyMerlin-ის სხვა თანამშრომლებზე.

https://bit.ly/3jf1fIK

არსებობს ღრუბელი, რომელიც დაფუძნებულია OpenStack-ზე. ტექნიკურ რადართან არის პატარა ბმული.

ის აგებულია Kubernetes-ის აპარატურაზე, ისევე როგორც ყველა დაკავშირებულ სერვისზე OpenStack-ისთვის და ლოგინგისთვის.

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

ჩვენ დაგვჭირდება ყველა მონაცემის გადატანა Kubernetes კლასტერის გარეთ, რადგან თუ რამე მოხდება, უნდა გავიგოთ რა და სად.

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

მაგრამ აქ არის მცირე პრობლემები. ჩვენს შემთხვევაში პრობლემები მაშინ დაიწყო, როცა 250 000 მეტრიკა გვქონდა და როცა 400 000 მეტრი იყო, მივხვდით, რომ ასე ვერ ვიმუშავებდით. ჩვენ გავზარდეთ scrape_timeout 25 წამამდე.

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

ყველასთვის ცნობილია გრაფიკები, რომლებსაც ვიღებთ, როდესაც ზოგიერთი მონაცემი აკლია. გრაფიკები დაშლილია და ამით არ ვართ კმაყოფილი.

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

მაგალითად, უბრალოდ აიღეთ ისინი და დაჭერით სახელით. ეს ასევე შეიძლება გამოყენებულ იქნას, მაგრამ ჩვენ გადავწყვიტეთ გადავიდეთ.

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

პირველი ვარიანტი არის ის, რომ ჩვენ გვინდა ფედერაციის მექანიზმის მიტოვება, რადგან ის ძალიან ნელია.

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

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

მეორე ნაკლი არის მეხსიერების მოხმარება. დიახ, მესმის, რომ ბევრი იტყვის, რომ 2020 წელს რამდენიმე გიგაბაიტი მეხსიერება ღირს პენი, მაგრამ მაინც.

ახლა ჩვენ გვაქვს dev და prod გარემო. დეველოპმენტში ეს არის დაახლოებით 9 გიგაბაიტი 350 მეტრისთვის. პროდუქტში არის 000 გიგაბაიტი და 14-ზე ცოტა მეტი მეტრიკა. ამავდროულად, ჩვენი შეკავების დრო მხოლოდ 780 წუთია. Ეს არის ცუდი. ახლა კი აგიხსნით რატომ.

ჩვენ ვაკეთებთ გამოთვლას, ანუ მილიონნახევარი მეტრიკით და უკვე ახლოს ვართ მათთან, დიზაინის ეტაპზე ვიღებთ 35-37 გიგაბაიტიან მეხსიერებას. მაგრამ უკვე 4 მილიონი მეტრიკა მოითხოვს დაახლოებით 90 გიგაბაიტ მეხსიერებას. ანუ, ის გამოითვალა პრომეთეს დეველოპერების მიერ მოწოდებული ფორმულით. ჩვენ შევხედეთ კორელაციას და მივხვდით, რომ არ გვინდოდა სერვერზე ორი მილიონის გადახდა მხოლოდ მონიტორინგისთვის.

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

დისკზე, აქ ყველაფერი არც ისე ცუდია, მაგრამ მინდა გავაუმჯობესო. 15 დღეში სულ 120 გიგაბაიტი მივიღეთ, საიდანაც 100 არის შეკუმშული, 20 არაკომპრესირებული, მაგრამ ყოველთვის ნაკლები გვინდა.

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

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

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

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

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

ნაკლოვანებები თანმიმდევრობით იმ ფორმით, რომელშიც ჩვენ დავწერეთ ისინი:

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

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

ჩვენ დავადგინეთ საკუთარი თავისთვის საჭირო დამატებითი მოთხოვნები. ეს:

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

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

რატომ? იმიტომ რომ:

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

მოდით გავაკეთოთ პირველი შედარება. ჩვენ ვიღებთ იგივე პრომეთეს კლასტერის შიგნით, გარე პრომეთე მიდის მასში. დამატება RemoteWrite VictoriaMetrics-ის საშუალებით.

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

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

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

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

ჩვენ ასევე ვზოგავთ მეხსიერების რესურსის მოხმარებას. ტესტირების დროს ჩვენ გვყავდა პრომეთე განლაგებული ვირტუალურ მანქანაზე - 8 ბირთვი, 24 გიგაბაიტი. პრომეთე თითქმის ყველაფერს ჭამს. ის დაეცა OOM Killer-ზე. ამავდროულად, მასში მხოლოდ 900 000 აქტიური მეტრიკა იყო ჩასმული. ეს არის დაახლოებით 25-000 მეტრი წამში.

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

CPU ბევრად უკეთესი გახდა პრომეთესთან შედარებით. აქ პრომეთე მოიხმარს 2,5 ბირთვს, ხოლო VictoriaMetrics მხოლოდ 0,25 ბირთვს. დასაწყისში - 0,5 ბირთვი. როგორც შერწყმა, ის აღწევს ერთ ბირთვს, მაგრამ ეს უკიდურესად იშვიათია.

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

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

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

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

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

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

პირველ გამეორებებში ჩვენ გამოვცადეთ VictoriaMetrics Single Node. შემდეგ გადავდივართ VictoriaMetrics კლასტერის ვერსიაზე.

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

VictoriaMetrics Cluster Version-ის ძირითადი კომპონენტებია vmstsorage. მათი რიცხვი შეიძლება იყოს N. ჩვენს შემთხვევაში ჯერჯერობით 2 მათგანია.

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

Vminsert მხარს უჭერს OpenTSDB, Graphite, InfluxDB და RemoteWrite პროტოკოლებს Prometheus-ისგან.

ასევე არის vmselect. მისი მთავარი ამოცანაა გადავიდეს vmstorage-ში, მიიღოს მონაცემები მათგან, ამ მონაცემების დუბლიკატი და კლიენტისთვის მიცემა.

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

კიდევ ერთი შესანიშნავი სერვისი არის vmalert, რომელიც საშუალებას გაძლევთ გამოიყენოთ VictoriaMetrics როგორც backend, მიიღოთ დამუშავებული მონაცემები vminsert-დან და გაგზავნოთ vmselect-ზე. ის თავად ამუშავებს შეტყობინებებს, ასევე წესებს. გაფრთხილების შემთხვევაში, ჩვენ ვიღებთ გაფრთხილებას alertmanager-ის მეშვეობით.

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

ასევე არის vmbackup, vmrestore. ეს არის, არსებითად, ყველა მონაცემის აღდგენა და სარეზერვო ასლი. შეუძლია S3, GCS, ფაილი.

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

აქვე გავაკეთებ დათქმას, რომ როდესაც VictoriaMetrics Single Node-დან VictoriaMetrics Cluster Version-ზე გადავედით, ისევ იგივე მოხმარებული რესურსებით დავრჩით, ანუ მთავარია მეხსიერება. დაახლოებით ასე განაწილდა ჩვენი მონაცემები, ანუ რესურსების მოხმარება.

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

მთელ კლასტერს აქვს N შესვლის წერტილი, რაც ნიშნავს, რომ პრომეთეს შეუძლია მონაცემების დამატება HAPROXY-ის საშუალებით. აქ გვაქვს ეს შესვლის წერტილი. და ამ შესვლის წერტილის მეშვეობით შეგიძლიათ შეხვიდეთ Grafana-დან.

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

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

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

ჩვენ ვასრულებთ ჩვენს სიას HA განხორციელებით.

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

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

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

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

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

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

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

ჩვენ გამოვიყენებთ VictoriaMetrics-ს სახლში, რადგან ის ძალიან მოგვწონდა. ეს იყო და რაც გახდა.

https://t.me/VictoriaMetrics_ru1

რამდენიმე QR კოდი VictoriaMetrics ჩეთისთვის, ჩემი კონტაქტებისთვის, LeroyMerlin ტექნიკური რადარისთვის.

წყარო: www.habr.com