Სალამი ყველას! Მისი ბოლო სტატია მე დავწერე მიკროსერვისის არქიტექტურისთვის მოდულური მონიტორინგის სისტემის ორგანიზების შესახებ. არაფერი დგას, ჩვენი პროექტი მუდმივად იზრდება და ასევე იზრდება შენახული მეტრიკის რაოდენობა. როგორ მოვაწყვეთ Graphite+Whisper–დან Graphite+ClickHouse–ზე გადასვლა მაღალი დატვირთვის პირობებში, წაიკითხეთ მისგან მოლოდინებისა და მიგრაციის შედეგების შესახებ.

სანამ გეტყვით, როგორ მოვაწყვეთ გადასვლა Graphite+Whisper-ში მეტრიკის შენახვიდან Graphite+ClickHouse-ზე, მინდა მოგაწოდოთ ინფორმაცია ასეთი გადაწყვეტილების მიღების მიზეზებისა და Whisper-ის უარყოფითი მხარეების შესახებ, რომლითაც დიდი ხნის განმავლობაში ვცხოვრობდით.

გრაფიტის + ჩურჩულის პრობლემები

1. დიდი დატვირთვა დისკის ქვესისტემაზე

გადასვლის დროს ჩვენთან წუთში დაახლოებით 1.5 მილიონი მეტრიკა შემოდიოდა. ასეთი ნაკადით, სერვერებზე დისკის გამოყენება იყო ~30%. ზოგადად, ეს სავსებით მისაღები იყო - ყველაფერი სტაბილურად მუშაობდა, სწრაფად იწერებოდა, სწრაფად იკითხებოდა... სანამ ერთ-ერთმა დეველოპერულმა ჯგუფმა არ გამოუშვა ახალი ფუნქცია და არ დაიწყო ჩვენთვის წუთში 10 მილიონი მეტრიკის გაგზავნა. სწორედ მაშინ გამკაცრდა დისკის ქვესისტემა და ჩვენ ვნახეთ 100%-იანი გამოყენება. პრობლემა სწრაფად მოგვარდა, მაგრამ ნარჩენები დარჩა.

2. რეპლიკაციისა და თანმიმდევრულობის ნაკლებობა

დიდი ალბათობით, ისევე როგორც ყველა, ვინც იყენებს/გამოიყენა Graphite+Whisper-ს, ჩვენ დავასხათ მეტრიკის იგივე ნაკადი ერთდროულად რამდენიმე Graphite სერვერზე, რათა შეგვექმნა შეცდომის ტოლერანტობა. და ამაში განსაკუთრებული პრობლემები არ ყოფილა - იმ მომენტამდე, როდესაც ერთ-ერთი სერვერი რაიმე მიზეზით გაფუჭდა. ზოგჯერ ჩვენ ვახერხებდით დაშლილი სერვერის საკმარისად სწრაფად აყვანას და carbon-c-relay ახერხებდა მეტრიკის ჩატვირთვას მისი ქეშიდან, მაგრამ ზოგჯერ არა. და შემდეგ იყო ხვრელი მეტრიკაში, რომელიც ჩვენ შევავსეთ rsync-ით. პროცედურა საკმაოდ გრძელი იყო. ერთადერთი გადარჩენის მადლი ის იყო, რომ ეს ძალიან იშვიათად ხდებოდა. ჩვენ ასევე პერიოდულად ვიღებდით მეტრიკების შემთხვევით კომპლექტს და ვადარებდით მათ იმავე ტიპის სხვა კვანძებს კლასტერის მეზობელ კვანძებზე. შემთხვევების დაახლოებით 5% -ში რამდენიმე მნიშვნელობა იყო განსხვავებული, რაც ჩვენ ძალიან არ გვახარებდა.

3. დიდი ნაკვალევი

მას შემდეგ, რაც Graphite-ში ვწერთ არა მხოლოდ ინფრასტრუქტურას, არამედ ბიზნეს მეტრიკას (და ახლაც Kubernetes-ის მეტრიკა), საკმაოდ ხშირად ვიღებთ სიტუაციას, როდესაც მეტრიკა შეიცავს მხოლოდ რამდენიმე მნიშვნელობას და .wsp ფაილი იქმნება ყველა შეკავების გათვალისწინებით. პერიოდი და იკავებს წინასწარ გამოყოფილ ადგილს, რაც ჩვენთვის იყო ~2MB. პრობლემას კიდევ უფრო ამძიმებს ის ფაქტი, რომ დროთა განმავლობაში უამრავი მსგავსი ფაილი ჩნდება და მათზე მოხსენებების აგებისას ცარიელი პუნქტების წაკითხვას დიდი დრო და რესურსი სჭირდება.

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

ყოველივე ზემოთქმულის გათვალისწინებით (წინარის გათვალისწინებით მუხლი), ისევე როგორც მიღებული მეტრიკის რაოდენობის მუდმივი ზრდა, ყველა მეტრიკის გადატანის სურვილი 30 წამის შენახვის ინტერვალში. (საჭიროების შემთხვევაში 10 წამამდე), გადავწყვიტეთ გამოგვეცადა Graphite+ClickHouse, როგორც Whisper-ის პერსპექტიული ალტერნატივა.

Graphite+ClickHouse. მოლოდინი

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

მე მინდა მივიღო შემდეგი:

• დისკის ქვესისტემის გამოყენების შემცირება 30%-დან 5%-მდე;
• შეამცირეთ დაკავებული სივრცის რაოდენობა 1TB-დან 100GB-მდე;
• შეეძლოს სერვერზე წუთში 100 მილიონი მეტრიკის მიღება;
• მონაცემთა რეპლიკაცია და შეცდომების ტოლერანტობა გარეთ ყუთში;
• არ იჯდეთ ამ პროექტზე ერთი წელი და გააკეთეთ გადასვლა გონივრულ ვადებში;
• გადართვა შეფერხების გარეშე.

საკმაოდ ამბიციური, არა?

Graphite+ClickHouse. კომპონენტები

Graphite პროტოკოლით მონაცემების მისაღებად და შემდგომ ClickHouse-ში ჩასაწერად, მე შევარჩიე carbon-clickhouse (გოლანგი).

ClickHouse-ის უახლესი გამოშვება, სტაბილური ვერსია 1.1.54253, არჩეულ იქნა მონაცემთა ბაზად დროის სერიების შესანახად. მასთან მუშაობისას იყო პრობლემები: შეცდომების მთამ ჩაასხა ჟურნალებში და ბოლომდე გაურკვეველი იყო, რა უნდა გაეკეთებინა მათთან. დისკუსიაში რომან ლომონოსოვი (carbon-clickhouse-ის, graphite-clickhouse-ის და მრავალი, მრავალი სხვა ავტორი) აირჩიეს უფროსი გამოშვება 1.1.54236. შეცდომები გაქრა - ყველაფერმა დაიწყო მუშაობა ხმაურით.

არჩეულია ClickHouse-დან მონაცემების წასაკითხად გრაფიტ-კლიკჰაუსი (გოლანგი). როგორც API გრაფიტისთვის - კარბონაპი (გოლანგი). ClickHouse გამოიყენებოდა ცხრილებს შორის რეპლიკაციის ორგანიზებისთვის ზოოპარკი. მარშრუტიზაციის მეტრიკებისთვის, ჩვენ დავტოვეთ ჩვენი საყვარელი ნახშირბად-c-რელე (C) (იხილეთ წინა სტატია).

Graphite+ClickHouse. მაგიდის სტრუქტურა

„გრაფიტი“ არის მონაცემთა ბაზა, რომელიც ჩვენ შევქმენით ცხრილების მონიტორინგისთვის.

"graphite.metrics" - ცხრილი ReplicatedReplacingMergeTree ძრავით (გამეორებული MergeTree-ის ჩანაცვლება). ეს ცხრილი ინახავს მეტრიკის სახელებს და მათკენ მიმავალ ბილიკებს.

CREATE TABLE graphite.metrics ( Date Date, Level UInt32, Path String, Deleted UInt8, Version UInt32 ) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/replicator/graphite.metrics', ‘r1’, Date, (Level, Path), 8192, Version);

„graphite.data“ - ცხრილი ReplicateGraphiteMergeTree ძრავით (გამეორებული GraphiteMergeTree). ეს ცხრილი ინახავს მეტრულ მნიშვნელობებს.

CREATE TABLE graphite.data ( Path String, Value Float64, Time UInt32, Date Date, Timestamp UInt32 ) ENGINE = ReplicatedGraphiteMergeTree('/clickhouse/tables/replicator/graphite.data', 'r1', Date, (Path, Time), 8192, 'graphite_rollup')

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

CREATE MATERIALIZED VIEW graphite.date_metrics ( Path String,  Level UInt32,  Date Date) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/replicator/graphite.date_metrics', 'r1', Date, (Level, Path, Date), 8192) AS SELECT toUInt32(length(splitByChar('.', Path))) AS Level, Date, Path FROM graphite.data

„graphite.data_stat“ - ცხრილი, რომელიც შევსებულია მდგომარეობის მიხედვით, ReplicatedAggregatingMergeTree ძრავით (განმეორებული Aggregating MergeTree). ეს ცხრილი აღრიცხავს შემომავალი მეტრიკის რაოდენობას, დაყოფილია 4 ბუდე დონეზე.

CREATE MATERIALIZED VIEW graphite.data_stat ( Date Date,  Prefix String,  Timestamp UInt32,  Count AggregateFunction(count)) ENGINE = ReplicatedAggregatingMergeTree('/clickhouse/tables/replicator/graphite.data_stat', 'r1', Date, (Timestamp, Prefix), 8192) AS SELECT toStartOfMonth(now()) AS Date, replaceRegexpOne(Path, '^([^.]+.[^.]+.[^.]+).*$', '1') AS Prefix, toUInt32(toStartOfMinute(toDateTime(Timestamp))) AS Timestamp, countState() AS Count FROM graphite.data  GROUP BY Timestamp, Prefix

Graphite+ClickHouse. კომპონენტების ურთიერთქმედების დიაგრამა

Graphite+ClickHouse. Მიგრაციის თარიღი

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

• Carbon-c-relay-ს დაემატა წესი, რომ გაიგზავნოს მეტრიკის დამატებითი ნაკადი ClickHouse ცხრილების რეპლიკაციაში მონაწილე ერთ-ერთი სერვერის carbon-clickhouse-ში.

• ჩვენ დავწერეთ პატარა სკრიპტი პითონში, რომელიც whisper-dump ბიბლიოთეკის გამოყენებით კითხულობდა ყველა .wsp ფაილს ჩვენი საცავიდან და ეს მონაცემები გაუგზავნა ზემოთ აღწერილ carbon-clickhouse-ში 24 თემაში. Carbon-clickhouse-ში მიღებული მეტრიკული მნიშვნელობების რაოდენობამ მიაღწია 125 მილიონ/წთ-ს, ხოლო ClickHouse-ს ოფლიც კი არ მოსცილებია.

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

• ბალანსერის პარამეტრებში წაკითხვის დატვირთვის გადასართავად, ჩვენ შევცვალეთ ბოლო წერტილები graphite-api-დან (API ინტერფეისი Graphite+Whisper-ისთვის) კარბონაპიზე.

Graphite+ClickHouse. შედეგები

• შემცირდა დისკის ქვესისტემის უტილიზაცია 30%-დან 1%-მდე;

  

• შემცირდა დაკავებული სივრცის რაოდენობა 1 ტბ-დან 300 გბ-მდე;
• ჩვენ გვაქვს შესაძლებლობა მივიღოთ 125 მილიონი მეტრიკა წუთში სერვერზე (პიკი მიგრაციის დროს);
• გადაიტანა ყველა მეტრიკა ოცდაათი წამის შენახვის ინტერვალში;
• მიღებული მონაცემების რეპლიკაცია და შეცდომის ტოლერანტობა;
• ჩართულია შეფერხების გარეშე;
• დაახლოებით 7 კვირა დასჭირდა ყველაფრის დასრულებას.

Graphite+ClickHouse. პრობლემები

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

1. ClickHouse ყოველთვის არ კითხულობს კონფიგურაციებს, ზოგჯერ საჭიროა მისი გადატვირთვა. მაგალითად, ClickHouse-ის კონფიგურაციის zookeeper კლასტერის აღწერის შემთხვევაში, ის არ გამოიყენებოდა clickhouse-სერვერის გადატვირთვამდე.
2. ClickHouse-ის დიდი მოთხოვნები არ გასულა, ასე რომ, graphite-clickhouse-ში ჩვენი ClickHouse კავშირის სტრიქონი ასე გამოიყურება:

   url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"

3. ClickHouse საკმაოდ ხშირად ავრცელებს სტაბილური გამოშვებების ახალ ვერსიებს; ისინი შეიძლება შეიცავდეს სიურპრიზებს: იყავით ფრთხილად.
4. დინამიურად შექმნილი კონტეინერები კუბერნეტებში აგზავნიან მეტრიკის დიდ რაოდენობას მოკლე და შემთხვევითი სიცოცხლის ხანგრძლივობით. ასეთი მეტრიკებისთვის ბევრი ქულა არ არის და სივრცის პრობლემა არ არის. მაგრამ მოთხოვნების შექმნისას, ClickHouse აირჩევს იგივე მეტრიკის უზარმაზარ რაოდენობას "მეტრიკის" ცხრილიდან. შემთხვევების 90%-ში მათ შესახებ მონაცემები ფანჯრის მიღმა არ არის (24 საათი). მაგრამ დრო იხარჯება ამ მონაცემების "მონაცემთა" ცხრილის ძიებაში და საბოლოოდ ეშვება ვადამდე. ამ პრობლემის გადასაჭრელად, ჩვენ დავიწყეთ ცალკე ხედვის შენარჩუნება იმ მეტრიკის შესახებ, რომელიც დღის განმავლობაში შეგვხვდა. ამრიგად, დინამიურად შექმნილი კონტეინერებისთვის მოხსენებების (გრაფების) აგებისას ჩვენ ვკითხულობთ მხოლოდ იმ მეტრებს, რომლებიც შეგვხვდა მოცემულ ფანჯარაში და არა მთელი დროის განმავლობაში, რამაც მნიშვნელოვნად დააჩქარა მათზე მოხსენებების აგება. ზემოთ აღწერილი ხსნარისთვის მე შევაგროვე გრაფიტის დაწკაპუნების სახლი (ჩანგალი), რომელიც მოიცავს date_metrics ცხრილთან მუშაობის განხორციელებას.

Graphite+ClickHouse. ტეგები

1.1.0 ვერსიით Graphite გახდა ოფიციალური მხარდაჭერის ტეგები. და ჩვენ აქტიურად ვფიქრობთ რა და როგორ გავაკეთოთ ამ ინიციატივის მხარდასაჭერად graphite+clickhouse stack-ში.

Graphite+ClickHouse. ანომალიის დეტექტორი

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

გამოიწერეთ, დააჭირეთ ზემოთ ისარს და იყავით ბედნიერი!

წყარო: www.habr.com