მონიტორინგი, როგორც სერვისი: მოდულური სისტემა მიკროსერვისის არქიტექტურისთვის

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

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

წარსული: სქემები და გეგმები

როგორ მივედით ახლანდელ მონიტორინგის სისტემამდე? ამ კითხვაზე პასუხის გასაცემად საჭიროა 2015 წ. ასე გამოიყურებოდა მაშინ:

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

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

სტანდარტი: მონიტორინგი 2.0

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

• მუდმივი ხელმისაწვდომობა;
• მეტრიკის შენახვის ინტერვალი = 10 წამი;
• მეტრიკისა და დაფების სტრუქტურირებული შენახვა;
• SLA > 99,99%
• ღონისძიების მეტრიკის შეგროვება UDP-ის საშუალებით (!).

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

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

აწმყო: მონიტორინგის კომპონენტების ურთიერთქმედების დიაგრამა

პირველ რიგში, ჩვენ ვაკვირდებით აპლიკაციებს: ჩვენს PHP კოდს, აპლიკაციებსა და მიკროსერვისებს - მოკლედ, ყველაფერს, რასაც ჩვენი დეველოპერები წერენ. ყველა აპლიკაცია აგზავნის მეტრიკას UDP-ის საშუალებით Brubeck-ის აგრეგატორში (statsd, გადაწერილი C-ში). ის ყველაზე სწრაფი აღმოჩნდა სინთეზურ ტესტებში. და ის აგზავნის უკვე გაერთიანებულ მეტრებს Graphite-ზე TCP-ის საშუალებით.

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

ჩვენ ასევე გვაქვს მეტრიკის აგრეგაცია ტექნიკის, პროგრამული უზრუნველყოფის, სისტემური მეტრიკისა და ჩვენი ძველი Munin მონიტორინგის სისტემისთვის (ის ჩვენთან მუშაობდა 2015 წლამდე). ამ ყველაფერს ვაგროვებთ C's CollectD დემონის მეშვეობით (მას აქვს ჩაშენებული სხვადასხვა დანამატების მთელი თაიგული, მას შეუძლია გამოკითხოს ჰოსტის სისტემის ყველა რესურსი, რომელზედაც ის არის დაინსტალირებული, უბრალოდ მიუთითეთ კონფიგურაციაში სად ჩაწეროს მონაცემები) და ჩაწერეთ მონაცემები გრაფიტის მეშვეობით. ის ასევე მხარს უჭერს პითონის დანამატებს და ჭურვის სკრიპტებს, ასე რომ თქვენ შეგიძლიათ დაწეროთ თქვენი საკუთარი გადაწყვეტილებები: CollectD შეაგროვებს ამ მონაცემებს ადგილობრივი ან დისტანციური ჰოსტიდან (ვარაუდით, Curl) და გაუგზავნის მას Graphite-ში.

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

Carbon-c-რელე შემდეგ აგზავნის მეტრიკას გრაფიტის კლასტერში. ჩვენ ვიყენებთ Carbon-cache-ს, გადაწერილს Go-ში, როგორც მეტრიკის ძირითად შესანახად. Go-carbon, მისი მრავალნაკადის გამო, ბევრად აღემატება Carbon-cache-ს. ის იღებს მონაცემებს და წერს დისკებზე whisper პაკეტის გამოყენებით (სტანდარტული, დაწერილი პითონში). ჩვენი საცავებიდან მონაცემების წასაკითხად, ჩვენ ვიყენებთ Graphite API-ს. ის ბევრად უფრო სწრაფია ვიდრე სტანდარტული Graphite WEB. რა დაემართება შემდეგ მონაცემებს?

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

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

ჩვენ განვათავსეთ Moira Kubernetes-ში; ის იყენებს Redis სერვერების კლასტერს, როგორც ძირითად მონაცემთა ბაზას. შედეგი იყო შეცდომების ტოლერანტული სისტემა. ის ადარებს მეტრიკის ნაკადს ტრიგერების ჩამონათვალს: თუ მასში არ არის ნახსენები, მაშინ ის ტოვებს მეტრიკას. ასე რომ, მას შეუძლია წუთში გიგაბაიტი მეტრიკის დამუშავება.

ჩვენ მას ასევე დავუმატეთ კორპორატიული LDAP, რომლის დახმარებით კორპორატიული სისტემის თითოეულ მომხმარებელს შეუძლია შექმნას შეტყობინებები საკუთარი თავისთვის არსებული (ან ახლად შექმნილი) ტრიგერების საფუძველზე. ვინაიდან Moira შეიცავს გრაფიტს, ის მხარს უჭერს მის ყველა ფუნქციას. ასე რომ, თქვენ ჯერ აიღეთ ხაზი და დააკოპირეთ იგი Grafana-ში. ნახეთ, როგორ არის ნაჩვენები მონაცემები გრაფიკებზე. შემდეგ აიღეთ იგივე ხაზი და დააკოპირეთ იგი მოირაში. თქვენ დაკიდებთ მას ლიმიტებით და იღებთ გაფრთხილებას გამოსავალზე. ამ ყველაფრის გასაკეთებლად, თქვენ არ გჭირდებათ რაიმე კონკრეტული ცოდნა. Moira-ს შეუძლია გააფრთხილოს SMS-ის, ელ.ფოსტის, Jira-ს, Slack-ის საშუალებით... ასევე მხარს უჭერს პერსონალური სკრიპტების შესრულებას. როდესაც მას ემართება ტრიგერი და მას აქვს გამოწერილი მორგებული სკრიპტი ან ორობითი, ის აწარმოებს მას და აგზავნის JSON-ს stdin-ზე ამ ბინარისთვის. შესაბამისად, თქვენმა პროგრამამ უნდა გააანალიზოს იგი. რას გააკეთებთ ამ JSON-ით, თქვენზეა დამოკიდებული. თუ გინდა გამოგზავნე Telegram-ში, თუ გინდა ჯირაში გახსენით ამოცანები, რაც გინდა.

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

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

მონიტორინგის კომპონენტები

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

გრაფიტი:

• go-carbon: github.com/lomik/go-carbon
• ჩურჩული: github.com/graphite-project/whisper
• გრაფიტი-აპი: github.com/brutasse/graphite-api

Carbon-c-რელე:

github.com/grobian/carbon-c-relay

ბრუბეკი:

github.com/github/brubeck

შეგროვებული:

შეგროვებული.org

მოირა:

github.com/moira-alert

გრაფანა:

grafana.com

Heapster:

github.com/kubernetes/heapster

სტატისტიკა

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

აგრეგატორი (ბრუბეკი)

მეტრიკის რაოდენობა: ~300/წმ
გრაფიტზე მეტრიკის გაგზავნის ინტერვალი: 30 წმ
სერვერის რესურსის გამოყენება: ~ 6% CPU (საუბარია სრულფასოვან სერვერებზე); ~ 1 გბ ოპერატიული მეხსიერება; ~3 Mbps LAN

გრაფიტი (გო-ნახშირბადი)

მეტრიკის რაოდენობა: ~ 1 / წთ
მეტრიკის განახლების ინტერვალი: 30 წმ
მეტრიკის შენახვის სქემა: 30 წთ 35d, 5წთ 90d, 10წთ 365d (გაძლევთ იმის გაგებას, თუ რა ემართება სერვისს დიდი ხნის განმავლობაში)
სერვერის რესურსის გამოყენება: ~10% CPU; ~ 20 გბ ოპერატიული მეხსიერება; ~30 Mbps LAN

მოქნილობა

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

აქ არის რეალური პრობლემის მაგალითი. მეტრიკა გრაფიტში არის ფაილი. სახელი აქვს. ფაილის სახელი = მეტრიკული სახელი. და იქ მისასვლელი გზა არსებობს. Linux-ში ფაილების სახელები შემოიფარგლება 255 სიმბოლოთი. ჩვენ გვყავს (როგორც "შიდა კლიენტები") ბიჭები მონაცემთა ბაზის განყოფილებიდან. ისინი გვეუბნებიან: ”ჩვენ გვინდა გავაკონტროლოთ ჩვენი SQL მოთხოვნები. და ისინი არ არის 255 სიმბოლო, მაგრამ თითო 8 მბ. ჩვენ გვინდა გამოვაჩინოთ ისინი Grafana-ში, ვნახოთ ამ მოთხოვნის პარამეტრები და კიდევ უკეთესი, გვსურს ვნახოთ ასეთი მოთხოვნების ზედა ნაწილი. ძალიან კარგი იქნება, თუ ის რეალურ დროში იქნება ნაჩვენები. ძალიან მაგარი იქნებოდა მათი გაფრთხილება. ”

SQL შეკითხვის მაგალითი აღებულია, როგორც მაგალითი საიტი postgrespro.ru

ჩვენ დავაყენეთ Redis სერვერი და ვიყენებთ ჩვენს Collectd დანამატებს, რომლებიც მიდიან Postgres-ში და იღებენ ყველა მონაცემს იქიდან, აგზავნიან მეტრებს Graphite-ში. მაგრამ ჩვენ ვცვლით მეტრულ სახელს ჰეშებით. ჩვენ ერთდროულად ვუგზავნით იმავე ჰეშს Redis-ს, როგორც გასაღებს, და მთელ SQL მოთხოვნას, როგორც მნიშვნელობას. ჩვენ მხოლოდ უნდა დავრწმუნდეთ, რომ გრაფანას შეუძლია რედისში წასვლა და ამ ინფორმაციის მიღება. ჩვენ ვხსნით Graphite API-ს, რადგან... ეს არის მთავარი ინტერფეისი ყველა მონიტორინგის კომპონენტის გრაფიტთან ურთიერთქმედებისთვის, და ჩვენ შევიყვანთ ახალ ფუნქციას, რომელსაც ეწოდება aliasByHash() - Grafana-დან ვიღებთ მეტრიკის სახელს და ვიყენებთ მას Redis-ის მოთხოვნაში, როგორც გასაღები, პასუხად ვიღებთ გასაღების მნიშვნელობას, რომელიც არის ჩვენი „SQL მოთხოვნა“ ამრიგად, Grafana-ში ჩვენ ვაჩვენეთ SQL მოთხოვნის ჩვენება, რომლის ჩვენება თეორიულად შეუძლებელი იყო მასზე არსებულ სტატისტიკასთან ერთად (ზარები, რიგები, total_time, ...).

შედეგები

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

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

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

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

რისკენ ვისწრაფვით?

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

1. ანომალიის დეტექტორი. ჩვენ გვინდა შევქმნათ სერვისი, რომელიც გადავა ჩვენს გრაფიტის საცავებში და შეამოწმებს თითოეულ მეტრიკას სხვადასხვა ალგორითმების გამოყენებით. უკვე არის ალგორითმები, რომელთა ნახვაც გვინდა, არის მონაცემები, ვიცით როგორ ვიმუშაოთ.
2. მეტამონაცემები. ჩვენ ბევრი სერვისი გვაქვს, ისინი დროთა განმავლობაში იცვლებიან, ისევე როგორც მათთან მომუშავე ადამიანები. დოკუმენტაციის ხელით მუდმივი შენარჩუნება არ არის ვარიანტი. სწორედ ამიტომ, ჩვენ ახლა ვანერგავთ მეტამონაცემებს ჩვენს მიკროსერვისებში. მასში მითითებულია ვინ შეიმუშავა ის, ენებზე, რომლებთანაც ის ურთიერთობს, SLA მოთხოვნებს, სად და ვის უნდა გაეგზავნოს შეტყობინებები. სერვისის განლაგებისას, სუბიექტის ყველა მონაცემი დამოუკიდებლად იქმნება. შედეგად, თქვენ მიიღებთ ორ ბმულს - ერთი ტრიგერებისკენ, მეორე კი გრაფანას დაფებზე.
3. მონიტორინგი ყველა სახლში. ჩვენ გვჯერა, რომ ყველა დეველოპერმა უნდა გამოიყენოს ასეთი სისტემა. ამ შემთხვევაში, თქვენ ყოველთვის გესმით, სად არის თქვენი ტრაფიკი, რა ხდება მას, სად ვარდება, სად არის მისი სისუსტეები. თუ, მაგალითად, რაღაც მოდის და თქვენს სერვისს ავარია, მაშინ ამის შესახებ შეიტყობთ არა მენეჯერის ზარის დროს, არამედ გაფრთხილებიდან და შეგიძლიათ დაუყოვნებლივ გახსნათ უახლესი ჟურნალები და ნახოთ რა მოხდა იქ.
4. Მაღალი დონის შესრულება. ჩვენი პროექტი მუდმივად იზრდება და დღეს ის ამუშავებს დაახლოებით 2 000 000 მეტრულ მნიშვნელობას წუთში. ერთი წლის წინ ეს მაჩვენებელი იყო 500 000. და ზრდა გრძელდება და ეს ნიშნავს, რომ გარკვეული დროის შემდეგ Graphite (ჩურჩული) დაიწყებს დისკის ქვესისტემის მძიმე დატვირთვას. როგორც უკვე ვთქვი, ეს მონიტორინგის სისტემა საკმაოდ უნივერსალურია კომპონენტების ურთიერთშემცვლელობის გამო. ვიღაც ინახავს და მუდმივად აფართოებს თავის ინფრასტრუქტურას სპეციალურად Graphite-სთვის, მაგრამ ჩვენ გადავწყვიტეთ სხვა მარშრუტის გავლა: გამოყენება clickhouse როგორც ჩვენი მეტრიკის საცავი. ეს გადასვლა თითქმის დასრულებულია და ძალიან მალე გეტყვით უფრო დეტალურად, თუ როგორ გაკეთდა ეს: რა სირთულეები იყო და როგორ გადალახეს ისინი, როგორ წარიმართა მიგრაციის პროცესი, აღვწერ სავალდებულოდ არჩეულ კომპონენტებს და მათ კონფიგურაციას.

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

წყარო: www.habr.com