დააბრუნეთ დაკარგული სკუტერი, ან ერთი IoT მონიტორინგის ამბავი

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

თავდაპირველად პროექტს ეწოდა Road-to-Barcelona, ​​მოგვიანებით გახდა Road-to-Berlin (აქედან გამომდინარე R2B ეკრანის სურათებში) და ბოლოს მას ეწოდა xRide.

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

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

მომხმარებელმა ტელეფონზე დააინსტალირა iOS ან Android აპლიკაცია, მიუახლოვდა მისთვის მოსაწონ სკუტერს, რის შემდეგაც ტელეფონმა და სკუტერმა დაამყარეს peer-to-peer კავშირი, გაცვალეს ETH და მომხმარებელს შეეძლო მგზავრობის დაწყება სკუტერის ჩართვით. ტელეფონი. მოგზაურობის დასასრულს ასევე შესაძლებელი იყო მგზავრობის გადახდა Ethereum-ის გამოყენებით მომხმარებლის საფულედან ტელეფონით.

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

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

და შემდეგ, ერთ დღეს, ბონში, დილით ადრე, ჩვენს დამხმარე ჯგუფს (ადგილზე მდებარე სკუტერების მუშა მდგომარეობაში შესანარჩუნებლად) გააფრთხილეს: ერთ-ერთი სკუტერი უკვალოდ გაუჩინარდა.

როგორ მოვძებნო და დავაბრუნო?

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

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

მაშ, რისი მონიტორინგი გვინდოდა ჩვენს პროექტში?

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

გარდა ამისა, მსურს ვაკონტროლო ჩვენი IT ინფრასტრუქტურის მდგომარეობა - მონაცემთა ბაზები, სერვისები და ყველაფერი, რაც მათ მუშაობისთვის სჭირდება. ასევე საჭირო იყო „ჭკვიანი დამტენების“ სტატუსის მონიტორინგი, თუ ისინი გაფუჭდა ან ამოიწურა ბატარეები.

სკუტერები

რა იყო ჩვენი სკუტერები და რისი ცოდნა გვინდოდა მათ შესახებ?

პირველი და ყველაზე მნიშვნელოვანი არის GPS კოორდინატები, რადგან მათი წყალობით ჩვენ შეგვიძლია გავიგოთ სად არიან და სად მოძრაობენ.

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

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

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

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

აპარატურა

რა იყო ჩვენი "რკინის" ნაწილი?

უმოკლეს დროში და სწრაფი პროტოტიპის საჭიროების გათვალისწინებით, ჩვენ შევარჩიეთ კომპონენტების დანერგვისა და შერჩევის ყველაზე მარტივი ვარიანტი - Raspberry Pi.
თავად Rpi-ს გარდა, ჩვენ გვქონდა მორგებული დაფა (რომელიც ჩვენ თვითონ შევიმუშავეთ და შევუკვეთეთ ჩინეთიდან საბოლოო გადაწყვეტის აწყობის პროცესის დასაჩქარებლად) და კომპონენტების ნაკრები - რელე (სკუტერის ჩართვის/გამორთვისთვის), ბატარეის დამტენის მკითხველი, მოდემი, ანტენები. ეს ყველაფერი კომპაქტურად იყო შეფუთული სპეციალურ „xRide ყუთში“.

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

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

დოკერი? უბრალო ლინუქსი? და განლაგება

მოდი დავუბრუნდეთ მონიტორინგს, ასე რომ ჟოლო - რა გვაქვს?

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

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

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

მეორე მიზეზი იყო ჩვენი ერთ-ერთი პარტნიორი ბიბლიოთეკა Node.js-ზე (sic!) - სისტემის ერთადერთი კომპონენტი, რომელიც არ იყო დაწერილი Go/C/C++-ში.

ბიბლიოთეკის ავტორებს არ ჰქონდათ დრო, რომ წარმოედგინათ სამუშაო ვერსია რომელიმე „მშობლიურ“ ენაზე.

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

ჩვენ მივხვდით, რომ ჩვენც რომ გვინდოდეს, Docker-ის გამოყენება ჩვენთვის ძალიან დიდი ხარჯი იქნებოდა. არჩევანი გაკეთდა მშობლიური OS- ის სასარგებლოდ და უშუალოდ მის ქვეშ მუშაობდა.

OS

შედეგად, ჩვენ კვლავ ავირჩიეთ უმარტივესი ვარიანტი, როგორც OS და გამოვიყენეთ Raspbian (Debian build Pi-სთვის).

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

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

განლაგება

მაშინვე გაჩნდა კითხვა მოწყობილობებისთვის განახლებების მიწოდების მექანიზმის (OTA) დანერგვის აუცილებლობის შესახებ - როგორც ჩვენი აგენტის/აპლიკაციის განახლებები, ასევე თავად OS/firmware-ის განახლებები (რადგან აგენტის ახალ ვერსიებს შეიძლება დასჭირდეს ბირთვის განახლებები. ან სისტემის კომპონენტები, ბიბლიოთეკები და ა.შ.) .

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

შედარებით მარტივი, ძირითადად განახლებაზე/ორ ჩატვირთვაზე ორიენტირებული კომუნალური პროგრამებიდან, როგორიცაა swupd/SWUpdate/OSTree, სრულფასოვან პლატფორმებამდე, როგორიცაა Mender და Balena.

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

ძალიან ბალენა გამოირიცხა იმის გამო, რომ ის რეალურად იყენებს იგივე Docker-ს თავის balenaEngine-ში.

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

ამიტომ, საბოლოოდ არჩევანი დაეცა მენდერი. Mender არის სრული პლატფორმა firmware-ის აწყობის, მიწოდებისა და ინსტალაციისთვის.

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

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

შეუძლებელია

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

მათი არსი იმაში მდგომარეობდა, რომ ჩვენ უბრალოდ ვუკავშირდებოდით მასპინძელიდან (CI სერვერი) ssh-ის საშუალებით ჩვენს ჟოლოს და ვავრცელებდით მათ განახლებებს.

თავიდანვე ყველაფერი მარტივი იყო - მოწყობილობებთან ერთ ქსელში უნდა იყო, ჩასხმა Wi-Fi-ით ხდებოდა.

ოფისში უბრალოდ ათეული სატესტო ჟოლო იყო დაკავშირებული იმავე ქსელთან, თითოეულ მოწყობილობას ჰქონდა სტატიკური IP მისამართი, რომელიც ასევე მითითებულია Ansible Inventory-ში.

ეს იყო Ansible, რომელმაც მიაწოდა ჩვენი მონიტორინგის აგენტი ბოლო მოწყობილობებს

3G / LTE

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

იმის გამო, რომ სკუტერები, როგორც გესმით, არ ჯდებიან ერთ Wi-Fi როუტერთან დაკავშირებული, მუდმივად ელიან განახლებებს ქსელში.

სინამდვილეში, სკუტერებს საერთოდ არ შეუძლიათ რაიმე კავშირი ჰქონდეთ გარდა მობილური 3G/LTE (და მაშინაც კი, არა ყოველთვის).

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

მაგრამ ყველაზე მნიშვნელოვანი ის არის, რომ 3G/LTE ქსელში ჩვენ არ შეგვიძლია უბრალოდ დავეყრდნოთ ქსელს მინიჭებულ სტატიკურ IP-ს.

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

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

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

VPN

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

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

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

ღრუბლოვანი რესურსები

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

მოცემული

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

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

საბოლოო სურათი ასე გამოიყურებოდა

დასტის შერჩევა

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

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

არსებობს მონიტორინგის გადაწყვეტილებების უზარმაზარი მრავალფეროვნება, დაწყებული სრულფასოვანი სისტემებით, როგორიცაა Nagios, icinga ან ზბაქსი და დამთავრებული ფლოტის მართვის მზა გადაწყვეტილებებით.

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

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

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

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

(B)ELK?

პირველი გამოსავალი, რომელიც რეალურად განიხილებოდა, იყო კარგად ცნობილი ELK სტეკი.
ფაქტობრივად, მას უნდა ეწოდოს BELK, რადგან ეს ყველაფერი იწყება Beats-ით - https://www.elastic.co/what-is/elk-stack

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

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

ვიზუალიზაციისთვის შეგიძლიათ გამოიყენოთ Grafan.

ფაქტობრივად, ახალ ELK სტეკს შეუძლია დამოუკიდებლად შეაგროვოს მეტრიკა (მეტრული ბიტი) და Kibana-საც შეუძლია მათი ჩვენება.

მაგრამ მაინც, ELK თავდაპირველად გაიზარდა ჟურნალებიდან და ჯერჯერობით მეტრიკის ფუნქციონირებას აქვს მრავალი სერიოზული ნაკლი:

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

ზოგადად, ELK-ში მეტრიკა მძიმეა და ჯერ არ არის ისეთი მოსახერხებელი, როგორც სხვა გადაწყვეტილებებში, რომელთაგან ახლა ბევრად მეტია, ვიდრე უბრალოდ პრომეთე: TSDB, Victoria Metrics, Cortex და ა.შ. და ა.შ. რა თქმა უნდა, მე ნამდვილად მსურს დაუყოვნებლივ მქონდეს სრულფასოვანი ყველა ერთში გადაწყვეტა, მაგრამ metricbeat-ის შემთხვევაში ძალიან ბევრი კომპრომისი იყო.

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

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

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

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

ლოკი - გრაფანა - პრომეთე

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

სამწუხაროდ, პროექტის გაყიდვების პილოტის დაწყების დროს (19 წლის სექტემბერი-ოქტომბერი) Loki ჯერ კიდევ ბეტა ვერსიაში იყო 0.3-0.4 და განვითარების დაწყების მომენტში იგი ვერ განიხილებოდა როგორც საწარმოო გადაწყვეტა. საერთოდ.

მე ჯერ არ მაქვს Loki-ს სერიოზულ პროექტებში რეალურად გამოყენების გამოცდილება, მაგრამ შემიძლია ვთქვა, რომ Promtail (მორების შეგროვების აგენტი) მშვენივრად მუშაობს როგორც შიშველი მეტალისთვის, ასევე კუბერნეტების პოდებისთვის.

დააჭირე

ELK სტეკის ყველაზე ღირსეულ (ერთადერთ?) სრულფასოვან ალტერნატივას ახლა შეიძლება ეწოდოს მხოლოდ TICK სტეკი - Telegraf, InfluxDB, Chronograf, Kapacitor.

ქვემოთ უფრო დეტალურად აღვწერ ყველა კომპონენტს, მაგრამ ზოგადი იდეა ასეთია:

• Telegraf - მეტრიკის შეგროვების აგენტი
• InfluxDB - მეტრიკის მონაცემთა ბაზა
• Capacitor - რეალურ დროში მეტრიკის პროცესორი გაფრთხილებისთვის
• ქრონოგრაფი - ვებ პანელი ვიზუალიზაციისთვის

InfluxDB-სთვის, Kapacitor-ისთვის და Chronograf-ისთვის არის ოფიციალური საჭის სქემები, რომლებიც ჩვენ გამოვიყენეთ მათ განსათავსებლად.

უნდა აღინიშნოს, რომ Influx 2.0-ის უახლეს ვერსიაში (ბეტა), Kapacitor და Chronograf გახდა InfluxDB-ის ნაწილი და ცალ-ცალკე აღარ არსებობს.

ტელეგრაფი

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

მას შეუძლია ყველაფრის დიდი მოცულობის მონიტორინგი, დან nginx დან
სერვერი minecraft.

მას აქვს რამდენიმე მაგარი უპირატესობა:

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

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

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

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

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

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

InfluxDB

InfluxDB არის TICK სტეკის მთავარი ბირთვი, კერძოდ, დროის სერიების მონაცემთა ბაზა მეტრიკებისთვის.
მეტრიკის გარდა, Influx-ს შეუძლია ჟურნალების შენახვაც, თუმცა, არსებითად, მისთვის ჟურნალები იგივე მეტრიკაა, მხოლოდ ჩვეულებრივი რიცხვითი ინდიკატორების ნაცვლად, მთავარი ფუნქცია ხორციელდება ჟურნალის ტექსტის ხაზით.

InfluxDB ასევე იწერება Go-ში და, როგორც ჩანს, ბევრად უფრო სწრაფად მუშაობს ELK-თან შედარებით ჩვენს (არა ყველაზე მძლავრ) კლასტერზე.

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

ნაკლოვანებები - $$$ თუ სკალირება?

TICK სტეკს მხოლოდ ერთი ნაკლი აქვს, რაც ჩვენ აღმოვაჩინეთ - ის ძვირფასო. უფრო მეტიც.

რა აქვს ფასიან ვერსიას, რაც არ აქვს უფასო ვერსიას?

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

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

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

სამწუხაროა, მაგრამ ორივე მათგანი, როგორც ჩანს, მიტოვებული - არ არის ახალი ვალდებულებები, ვფიქრობ, რომ საქმე არის Influx 2.0-ის ახალი ვერსიის მალე მოსალოდნელი გამოშვება, რომელშიც ბევრი რამ განსხვავებული იქნება (არ არსებობს ინფორმაცია ამის შესახებ მასში ჯერ კიდევ მასშტაბირება).

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

გარდა ამისა გაზიარება არ არის მხარდაჭერილი, ეს ნიშნავს დამატებით ხარჯებს დუბლიკატი მეტრიკებისთვის (როგორც დამუშავება, ასევე შენახვა), რომელიც შეიძლება არ დაგჭირდეთ, მაგრამ მათი გამიჯვნის საშუალება არ არსებობს.

ვიქტორია მეტრიქსი?

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

არსებობს უამრავი დროის სერიების მონაცემთა ბაზა, მაგრამ ყველაზე პერსპექტიული არის Victoria Metrics, მას აქვს მრავალი უპირატესობა:

• სწრაფი და მარტივი, ყოველ შემთხვევაში, შედეგების მიხედვით ეტალონები
• არის კლასტერული ვერსია, რომლის შესახებაც ახლა კარგი მიმოხილვებიც არის
  • მას შეუძლია ნატეხი
• მხარს უჭერს InfluxDB პროტოკოლს

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

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

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

ცხადია, იმავე მიზეზით, VM ვერ ინახავს ჟურნალებს, როგორც ამას Influx აკეთებს.

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

ბაზის შერჩევა

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

ამ არჩევანის რამდენიმე ძირითადი მიზეზი იყო:

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

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

ამიტომ, გადავწყვიტეთ, რომ ამ პროექტისთვის ერთი Influx კვანძი საკმარისი იქნებოდა ჩვენთვის სკალირების საჭიროების გარეშე (იხილეთ დასკვნები ბოლოს).

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

კაპაციტორი

Kapacitor არის TICK სტეკის ნაწილი, სერვისი, რომელსაც შეუძლია აკონტროლოს მეტრიკა, რომელიც შედის მონაცემთა ბაზაში რეალურ დროში და შეასრულოს სხვადასხვა მოქმედებები წესების საფუძველზე.

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

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

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

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

Influx 2.0-ში Kapacitor გახდა DB-ის ნაწილი

ქრონოგრაფი

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

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

თუმცა, Grafana მაინც სრულიად უნივერსალური ინსტრუმენტია, ხოლო Chronograf ძირითადად განკუთვნილია Influx-თან გამოსაყენებლად.

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

შესაძლოა Chronograf-თან მუშაობის მთავარი მოხერხებულობა არის ის, რომ თქვენ შეგიძლიათ ნახოთ თქვენი InfluxDB-ის შიდა ნაწილი Explore-ის მეშვეობით.

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

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

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

თავად დაფები, გარდა სასიამოვნო ვიზუალური სტილისა, რეალურად არაფრით განსხვავდება Grafana-სა და Kibana-ს დაფებისგან:

ასე გამოიყურება შეკითხვის ფანჯარა:

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

და რა თქმა უნდა, ქრონოგრაფი რაც შეიძლება მოსახერხებელია ჟურნალების სანახავად. ეს ასე გამოიყურება:

ნაგულისხმევად, Influx ჟურნალები მორგებულია syslog-ის გამოსაყენებლად და, შესაბამისად, მათ აქვთ მნიშვნელოვანი პარამეტრი - სიმძიმე.

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

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

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

ჩვენ ეს ცოტა ხნით ჩავრთეთ, მაგრამ პილოტის მომზადების პროცესში აღმოჩნდა, რომ საკმაოდ ბევრ შეცდომებს ვიღებდით (მათ შორის, სისტემურ შეცდომებს, როგორიცაა LTE ქსელის მიუწვდომლობა), რამაც Slack არხსაც „სპამი“ გაუკეთა. ბევრი, უპრობლემოდ, დიდი სარგებელი.

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

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

ავთენტიფიკაცია

ასევე აღსანიშნავია, რომ Chronograf მხარს უჭერს OAuth და OIDC, როგორც ავტორიზაცია.

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

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

"ადმინი"

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

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

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

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

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

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

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

სხვათა შორის, ჩვენ სკუტერებს დავარქვით The Simpsons-ის პერსონაჟების სახელები - იმდენად მოსახერხებელი იყო მათი ერთმანეთისგან გარჩევა.

და ზოგადად ეს უფრო სახალისო იყო. გამუდმებით ისმოდა ფრაზები „ბიჭებო, სმითერსი მოკვდა!“

სიმებიანი მეტრიკა

მნიშვნელოვანია, რომ InfluxDB საშუალებას გაძლევთ შეინახოთ არა მხოლოდ რიცხვითი მნიშვნელობები, როგორც ეს Victoria Metrics-ის შემთხვევაშია.

როგორც ჩანს, ეს არც ისე მნიშვნელოვანია - ბოლოს და ბოლოს, ჟურნალების გარდა, ნებისმიერი მეტრიკის შენახვა შესაძლებელია რიცხვების სახით (უბრალოდ დაამატეთ რუქები ცნობილი მდგომარეობებისთვის - ერთგვარი შეჯამება)?

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

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

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

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

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

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

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

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

ეს ძალიან სასარგებლო იყო ჩვენთვის, როდესაც ვეძებდით სკუტერს (იხილეთ დასკვნები ბოლოს).

ინფრასტრუქტურის მონიტორინგი

გარდა თავად სკუტერებისა, ჩვენ ასევე გვჭირდებოდა მთელი ჩვენი (საკმაოდ ვრცელი) ინფრასტრუქტურის მონიტორინგი.

ძალიან ზოგადი არქიტექტურა ასე გამოიყურებოდა:

თუ ჩვენ გამოვყოფთ სუფთა მონიტორინგის დასტას, ის ასე გამოიყურება:

ის, რაც ჩვენ გვინდა შევამოწმოთ ღრუბელში არის:

• მონაცემთა ბაზები
• კლავიატურა
• მიკროსერვისები

ვინაიდან ყველა ჩვენი ღრუბლოვანი სერვისი მდებარეობს Kubernetes-ში, კარგი იქნებოდა ინფორმაციის შეგროვება მისი მდგომარეობის შესახებ.

საბედნიეროდ, Telegraf-ს შეუძლია შეაგროვოს უზარმაზარი რაოდენობის მეტრიკა Kubernetes კლასტერის მდგომარეობის შესახებ და Chronograf დაუყოვნებლივ გთავაზობთ ამისთვის მშვენიერ დაფებს.

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

Kubernetes-ში პოდების თვალყურის დევნების ორი გზა არსებობს: DaemonSet და Sidecar.
ორივე მეთოდი დეტალურად არის აღწერილი ამ ბლოგის პოსტში.

ჩვენ გამოვიყენეთ Telegraf Sidecar და, მეტრიკის გარდა, შევაგროვეთ პოდ ჟურნალები.

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

მონიტორინგს???

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

მიუხედავად იმისა, რომ Telegraf-ს შეუძლია ადვილად გამოაგზავნოს საკუთარი მეტრიკა ან შეაგროვოს მეტრიკა InfluxDB მონაცემთა ბაზიდან იმავე Influx-ში ან სადმე სხვაგან გასაგზავნად.

დასკვნები

რა დასკვნები გამოვიტანეთ პილოტის შედეგებიდან?

როგორ შეგიძლია მონიტორინგი?

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

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

მოქმედება

უფასო ვერსიაში TICK სტეკის მთავარი პრობლემა არის სკალირების შესაძლებლობების ნაკლებობა. ჩვენთვის ეს პრობლემა არ იყო.

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

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

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

ტრაფიკის უმეტესი ნაწილი მოხმარდა ჟურნალებს; თავად მეტრიკა, თუნდაც 10 წამიანი ინტერვალით, პრაქტიკულად არ ხარჯავდა მას.

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

ზოგიერთ შემთხვევაში, თუ ჟურნალების ნახვა ჯერ კიდევ საჭირო იყო, ჩვენ უბრალოდ ვუკავშირდებოდით WireGuard-ის მეშვეობით VPN-ის საშუალებით.

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

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

TICK - იდეალურია მცირე და საშუალო პროექტებისთვის

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

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

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

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

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

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

ამ შემთხვევაში, დღეს მე გირჩევდით ვიხილოთ მეტრიკის შეგროვება Victoria Metrics-ის და ჟურნალების მეშვეობით Loki-ს გამოყენებით.

მართალია, კიდევ ერთხელ გავაკეთებ დათქმას, რომ Loki/Grafana გაცილებით ნაკლებად მოსახერხებელია (მეტი მრავალფეროვნების გამო), ვიდრე მზა TICK, მაგრამ ისინი უფასოა.

მნიშვნელოვანია: აქ აღწერილი ყველა ინფორმაცია შესაბამისია Influx 1.8 ვერსიისთვის, ამ მომენტში Influx 2.0 გამოვა.

მიუხედავად იმისა, რომ მე არ მქონია შანსი გამომეცადა საბრძოლო პირობებში და მიჭირს დასკვნების გაკეთება გაუმჯობესების შესახებ, ინტერფეისი ნამდვილად კიდევ უკეთესი გახდა, არქიტექტურა გამარტივდა (კაპაციტორის და ქრონოგრაფის გარეშე).
გამოჩნდა შაბლონები ("მკვლელის ფუნქცია" - შეგიძლიათ თვალი ადევნოთ მოთამაშეებს Fortnite-ში და მიიღოთ შეტყობინებები, როდესაც თქვენი საყვარელი მოთამაშე მოიგებს თამაშს). მაგრამ, სამწუხაროდ, ამ დროისთვის, ვერსია 2-ს არ აქვს ის გასაღები, რისთვისაც ჩვენ ავირჩიეთ პირველი ვერსია - არ არის ჟურნალის კოლექცია.

ეს ფუნქცია ასევე გამოჩნდება Influx 2.0-ში, მაგრამ ჩვენ ვერ ვიპოვეთ ვადები, თუნდაც სავარაუდო.

როგორ არ შევქმნათ IoT პლატფორმები (ახლა)

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

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

ჩვენ სრულიად კმაყოფილი ვართ საბოლოო შედეგით და პლატფორმით, რომელიც დაფუძნებულია Ansible + TICK + WireGuard-ზე, რომელიც ჩვენ თვითონ შევიკრიბეთ. მაგრამ დღეს გირჩევთ, უფრო ახლოს გადახედოთ Balena-ს, სანამ თავად შეეცდებით შექმნათ თქვენი საკუთარი IoT პლატფორმა.

იმის გამო, რომ საბოლოო ჯამში მას შეუძლია გააკეთოს ყველაფერი, რაც ჩვენ გავაკეთეთ და OpenBalena არის უფასო და ღია წყარო.

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

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

ჰეი, რაც შეეხება დაკარგული სკუტერს?

ასე რომ, სკუტერი „რალფი“ უკვალოდ გაქრა.

ჩვენ მაშინვე გავეშურეთ რუკის დასათვალიერებლად ჩვენს „ადმინისტრაციულ პანელში“, GPS მეტრიკის მონაცემებით InfluxDB-დან.

მონიტორინგის მონაცემების წყალობით, ჩვენ ადვილად დავადგინეთ, რომ სკუტერმა გასული დღის 21:00 საათზე დატოვა ავტოსადგომი, გაიარა დაახლოებით ნახევარი საათი რაღაც ზონამდე და დილის 5 საათამდე იყო გაჩერებული რომელიმე გერმანული სახლის გვერდით.

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

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

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

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

წყარო: www.habr.com