კიდევ ერთი მონიტორინგის სისტემა

16 მოდემი, 4 ფიჭური ოპერატორი = გამავალი სიჩქარე 933.45 მბიტ/წმ

შესავალი

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

პროექტის შესახებ

საკმაოდ კონკრეტული პროდუქტი გვაქვს. ჩვენ ვაწარმოებთ ყოვლისმომცველ გადაწყვეტას მონაცემთა გადაცემის არხების გამტარუნარიანობისა და შეცდომების ტოლერანტობის შეჯამებისთვის. ეს არის მაშინ, როდესაც არის რამდენიმე არხი, ვთქვათ Operator1 (40Mbit/s) + Operator2 (30Mbit/s)+ რაღაც სხვა (5 Mbit/s), შედეგი არის ერთი სტაბილური და სწრაფი არხი, რომლის სიჩქარეც დაახლოებით იქნება. ეს: (40+ 30+5)x0.92=75×0.92=69 მბიტი/წმ.

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

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

პრობლემის შესახებ განცხადება

მონიტორინგის სისტემა უზრუნველყოფს ორი ფუნდამენტურად განსხვავებული კლასის მეტრიკას: რეალურ დროში მეტრიკა და ყველა სხვა. მონიტორინგის სისტემას მხოლოდ შემდეგი მოთხოვნები ჰქონდა:

1. რეალურ დროში მეტრიკის მაღალი სიხშირის სინქრონული შეძენა და მათი გადატანა კომუნიკაციის მართვის სისტემაში დაუყოვნებლად.
   მაღალი სიხშირე და სხვადასხვა მეტრიკის სინქრონიზაცია არ არის მხოლოდ მნიშვნელოვანი, ის სასიცოცხლოდ მნიშვნელოვანია მონაცემთა გადაცემის არხების ენტროპიის გასაანალიზებლად. თუ მონაცემთა გადაცემის ერთ არხში საშუალო დაყოვნება არის 30 მილიწამი, მაშინ დარჩენილ მეტრებს შორის მხოლოდ ერთი მილიწამის სინქრონიზაციის შეცდომა გამოიწვევს მიღებული არხის სიჩქარის დეგრადაციას დაახლოებით 5%-ით. თუ 1 არხზე ვადებს 4 მილიწამით გამოვრიცხავთ, სიჩქარის დეგრადაცია შეიძლება ადვილად დაეცეს 30%-მდე. გარდა ამისა, არხებში ენტროპია ძალიან სწრაფად იცვლება, ასე რომ, თუ მას 0.5 მილიწამში ერთხელ გავზომავთ, სწრაფ არხებზე მცირე დაგვიანებით მივიღებთ მაღალი სიჩქარის დეგრადაციას. რა თქმა უნდა, ასეთი სიზუსტე არ არის საჭირო ყველა მეტრიკისთვის და არა ყველა პირობებში. როდესაც არხზე შეფერხება 500 მილიწამია და ჩვენ ვმუშაობთ ასეთებთან, მაშინ 1 მილიწამის შეცდომა თითქმის არ იქნება შესამჩნევი. ასევე, სიცოცხლის მხარდაჭერის სისტემის მეტრიკებისთვის, ჩვენ გვაქვს საკმარისი გამოკითხვისა და სინქრონიზაციის სიხშირე 2 წამის განმავლობაში, მაგრამ თავად მონიტორინგის სისტემას უნდა შეეძლოს იმუშაოს ულტრა მაღალი კენჭისყრის მაჩვენებლებით და მეტრიკის ულტრა ზუსტი სინქრონიზაცია.
2. რესურსის მინიმალური მოხმარება და ერთი დასტა.
   ბოლო მოწყობილობა შეიძლება იყოს ან მძლავრი საბორტო კომპლექსი, რომელსაც შეუძლია გააანალიზოს სიტუაცია გზაზე ან ჩაატაროს ადამიანების ბიომეტრიული ჩაწერა, ან პალმის ზომის ერთბორტ კომპიუტერი, რომელსაც სპეცრაზმის ჯარისკაცი ატარებს ჯავშნის ქვეშ, ვიდეოს გადასაცემად. რეალურ დროში ცუდი კომუნიკაციის პირობებში. მიუხედავად ასეთი მრავალფეროვანი არქიტექტურისა და გამოთვლითი სიმძლავრისა, ჩვენ გვსურს გვქონდეს იგივე პროგრამული დასტა.
3. ქოლგის არქიტექტურა
   მეტრიკა უნდა იყოს შეგროვებული და აგრეგირებული ბოლო მოწყობილობაზე, ადგილობრივად შენახული და ვიზუალიზაცია რეალურ დროში და რეტროსპექტულად. თუ არის კავშირი, გადაიტანეთ მონაცემები ცენტრალური მონიტორინგის სისტემაში. როდესაც კავშირი არ არის, გაგზავნის რიგი უნდა დაგროვდეს და არ მოიხმაროს ოპერატიული მეხსიერება.
4. API მომხმარებლის მონიტორინგის სისტემაში ინტეგრაციისთვის, რადგან არავის სჭირდება ბევრი მონიტორინგის სისტემა. მომხმარებელმა უნდა შეაგროვოს მონაცემები ნებისმიერი მოწყობილობიდან და ქსელიდან ერთ მონიტორინგში.

Რა მოხდა

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

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

ზოგიერთი ძირითადი მეტრიკის ვიზუალიზაცია

არქიტექტურა

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

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

1. მეტრიკის რეგისტრაცია.
   თითოეული მეტრიკა ემსახურება საკუთარი ძაფით და სინქრონიზებულია არხებზე. ჩვენ შევძელით სინქრონიზაციის სიზუსტის მიღწევა 10 ნანოწამამდე.
2. მეტრიკის შენახვა
   ჩვენ ვირჩევდით დროის სერიებისთვის საკუთარი მეხსიერების დაწერას ან უკვე ხელმისაწვდომი რაღაცის გამოყენებას შორის. მონაცემთა ბაზა საჭიროა რეტროსპექტული მონაცემებისთვის, რომლებიც ექვემდებარება შემდგომ ვიზუალიზაციას, ანუ ის არ შეიცავს მონაცემებს არხზე ყოველ 0.5 მილიწამში ან შეცდომის წაკითხვის შესახებ სატრანსპორტო ქსელში, მაგრამ არის სიჩქარე თითოეულ ინტერფეისზე ყოველ 500 მილიწამში. გარდა პლატფორმაზე მაღალი მოთხოვნებისა და რესურსების დაბალი მოხმარებისა, ჩვენთვის ძალზე მნიშვნელოვანია დამუშავება. მონაცემები არის სადაც ის ინახება. ეს დაზოგავს უზარმაზარ გამოთვლით რესურსებს. ჩვენ ამ პროექტში 2016 წლიდან ვიყენებთ Tarantool DBMS-ს და ჯერჯერობით ჰორიზონტზე მის შემცვლელს ვერ ვხედავთ. მოქნილი, რესურსების ოპტიმალური მოხმარებით, ადეკვატურ ტექნიკურ მხარდაჭერაზე მეტი. Tarantool ასევე ახორციელებს GIS მოდულს. რა თქმა უნდა, ის არ არის ისეთივე ძლიერი, როგორც PostGIS, მაგრამ საკმარისია ჩვენი ამოცანების შესანახად მდებარეობის ზოგიერთი მეტრიკის შესანახად (ტრანსპორტისთვის შესაბამისი).
3. მეტრიკის ვიზუალიზაცია
   აქ ყველაფერი შედარებით მარტივია. ჩვენ ვიღებთ მონაცემებს საწყობიდან და ვაჩვენებთ რეალურ დროში ან რეტროსპექტულად.
4. მონაცემთა სინქრონიზაცია ცენტრალური მონიტორინგის სისტემასთან.
   ცენტრალური მონიტორინგის სისტემა იღებს მონაცემებს ყველა მოწყობილობიდან, ინახავს მას მითითებული ისტორიით და აგზავნის კლიენტის მონიტორინგის სისტემაში API-ს საშუალებით. კლასიკური მონიტორინგის სისტემებისგან განსხვავებით, რომლებშიც „თავი“ დადის და აგროვებს მონაცემებს, ჩვენ გვაქვს საპირისპირო სქემა. მოწყობილობები თავად აგზავნიან მონაცემებს, როდესაც არის კავშირი. ეს ძალიან მნიშვნელოვანი პუნქტია, რადგან ის საშუალებას გაძლევთ მიიღოთ მონაცემები მოწყობილობიდან იმ პერიოდისთვის, რომლის დროსაც ის არ იყო ხელმისაწვდომი და არ ჩატვირთოთ არხები და რესურსები, სანამ მოწყობილობა მიუწვდომელია. ჩვენ ვიყენებთ Influx მონიტორინგის სერვერს, როგორც ცენტრალური მონიტორინგის სისტემას. ანალოგებისგან განსხვავებით, მას შეუძლია რეტროსპექტული მონაცემების იმპორტი (ანუ დროის შტამპით განსხვავებული მეტრიკის მიღების მომენტიდან). ეს სტანდარტული სტეკი ასევე შეირჩა, რადგან მას აქვს მზა API ინტეგრაციები თითქმის ნებისმიერი მომხმარებლის მონიტორინგის სისტემასთან.
5. მონაცემთა სინქრონიზაცია ცენტრალური მოწყობილობის მართვის სისტემასთან.
   მოწყობილობის მართვის სისტემა ახორციელებს Zero Touch Provisioning-ს (პროგრამული უზრუნველყოფის განახლება, კონფიგურაცია და ა.შ.) და, მონიტორინგის სისტემისგან განსხვავებით, იღებს მხოლოდ პრობლემებს თითო მოწყობილობაზე. ეს არის ტრიგერები ბორტ ტექნიკის დამკვირვებელი სერვისების ფუნქციონირებისთვის და სიცოცხლის მხარდაჭერის სისტემების ყველა მეტრიკა: CPU და SSD ტემპერატურა, CPU დატვირთვა, თავისუფალი ადგილი და SMART ჯანმრთელობა დისკებზე. ქვესისტემის საცავი ასევე აგებულია Tarantool-ზე. ეს გვაძლევს მნიშვნელოვან სიჩქარეს ათასობით მოწყობილობაში დროის სერიების აგრეგაციაში და ასევე მთლიანად წყვეტს ამ მოწყობილობებთან მონაცემების სინქრონიზაციის საკითხს. Tarantool-ს აქვს შესანიშნავი რიგის და გარანტირებული მიწოდების სისტემა. ჩვენ მივიღეთ ეს მნიშვნელოვანი ფუნქცია ყუთიდან, შესანიშნავია!

ქსელის მართვის სისტემა

რა არის შემდეგი

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

1. InfluxDB კარგავს მონაცემებს ელექტროენერგიის დაკარგვისას. როგორც წესი, კლიენტი ოპერატიულად აგროვებს ყველაფერს, რაც მოდის მოწყობილობიდან და თავად მონაცემთა ბაზა არ შეიცავს 5 წუთზე უფრო ძველ მონაცემებს, მაგრამ მომავალში ეს შეიძლება გახდეს ტკივილი.
2. Grafana-ს არაერთი პრობლემა აქვს მონაცემთა აგრეგაციასთან და მისი ჩვენების სინქრონიზაციასთან დაკავშირებით. ყველაზე გავრცელებული პრობლემაა, როდესაც მონაცემთა ბაზა შეიცავს დროის სერიას 2 წამის ინტერვალით, რომელიც იწყება, ვთქვათ, 00:00:00 საათიდან, ხოლო Grafana იწყებს მონაცემების აგრეგაციას +1 წამიდან. შედეგად, მომხმარებელი ხედავს ცეკვის გრაფიკს.
3. კოდის გადაჭარბებული რაოდენობა API ინტეგრაციისთვის მესამე მხარის მონიტორინგის სისტემებთან. ის შეიძლება გაკეთდეს ბევრად უფრო კომპაქტური და რა თქმა უნდა გადაიწეროს Go-ში)

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

დასკვნა

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

თუ ვინმეს გაქვთ შეკითხვები ამ სტატიის ფარგლებს გარეთ, შეგიძლიათ მომწეროთ a.rodin @ qedr.com

წყარო: www.habr.com