SNMP-მონიტორინგი Odoo 19-ში: ზღვარი გადაჭარბებულია, ტიკეტი გახსნილია
სერვერები, სვიჩები, UPS-სისტემები, ტემპერატურის სენსორები სერვერულ ოთახში: თითქმის ყველაფერი, რაც ქსელშია ჩართული, SNMP-ზე საუბრობს და თავისი მდგომარეობის შესახებ ინფორმაციის მოწოდება შეუძლია. კითხვა მხოლოდ ისაა, ვინ უსმენს – და რა ხდება, როცა რომელიმე მნიშვნელობა ნორმიდან გადახრის.
ინფრასტრუქტურისთვის, რომელსაც ჩვენი მომხმარებლებისთვის ვემსახურებით, ეს ჯაჭვი ახლა ერთ ადგილას გავაერთიანეთ: ჩვენი Odoo 19 მოწყობილობებს ამოწმებს, მნიშვნელობებს ზღვრებს ადარებს და როცა ზღვარს მიაღწევს, Helpdesk-ში ტიკეტს ხსნის – იმ მომხმარებელთან, ვისაც მოწყობილობა ეკუთვნის. არა ცალკეული მონიტორინგის სისტემა, რომელიც ელფოსტით წერს Helpdesk-ში, არამედ იგივე სისტემა, სადაც მომხმარებელი, მოწყობილობა და ტიკეტი ისედაც ერთმანეთთან არის დაკავშირებული.
მოდული საკუთარი საქმიანობისთვის შევქმენით. ეს არ არის საზოგადოებისთვის გამოქვეყნება, როგორც ჩვენი მოდულები საბანკო ამონაწერებისა და ელექტრონული ინვოისებისთვის, არამედ ჩვენი შიდა მომსახურების პლატფორმის ნაწილია – ისევე, როგორც ტრექინგი, რომლის შესახებაც ბოლოს გაცნობეთ.
გაზომილი მნიშვნელობიდან ტიკეტამდე
პროცესი შეგნებულად მარტივად არის შენარჩუნებული:
- მოწყობილობა იქმნება მისამართითა და წვდომის მონაცემებით (SNMP v1, v2c ან v3 ავთენტიფიკაციითა და დაშიფვრით). შენახვისას Odoo იღებს სისტემის აღწერას, სისტემის სახელსა და Uptime-ს – ყველაზე გულწრფელი დადასტურება იმისა, რომ მისამართი და წვდომის მონაცემები სწორია.
- მოწყობილობაზე განისაზღვრება მონაცემთა წერტილები: OID, ერთეული, მომხმარებლის მიკუთვნება.
- განრიგი ამოწმებს ყველა აქტიურ მონაცემთა წერტილს. თითო მოწყობილობაზე ერთხელ ხდება დაკავშირება და არა თითო მონაცემთა წერტილზე – ოცი OID-ის შემთხვევაში სვიჩზე ეს არის სხვაობა ერთ და ოც სესიას შორის.
- თითოეულ მონაცემთა წერტილს შეუძლია ზღვრების მონიტორინგი: ზედა ზღვარი, ქვედა ზღვარი ან ორივე.
- თუ ზღვარი გადაჭარბდება, იქმნება Helpdesk-ტიკეტი.
ერთი ტიკეტი თითო ინციდენტზე და არა თითო გაზომვაზე
განგაშის ლოგიკის ყველაზე მნიშვნელოვანი წერტილი: მხოლოდ მდგომარეობის შეცვლა ითვლება. ვინც ყოველ გაზომვაზე ტიკეტს ქმნის, ერთი ღამის შემდეგ, გაჭედილი ან მოცახცახე სენსორის გამო, სამასი ტიკეტი ექნება – ეს არ არის განგაში, ეს არის დაბურვა.
ამიტომ მოდული თითო მონაცემთა წერტილზე იმახსოვრებს, არის თუ არა ის მდგომარეობაში „ნორმა“ ან „განგაში“. ზღვრის პირველად გადაჭარბებისას მდგომარეობა იცვლება, შეტყობინება ხვდება მოწყობილობის Chatter-ში და იხსნება ტიკეტი – დაზარალებული მომხმარებლით, როგორც პარტნიორით, მონაცემთა წერტილით, მოწყობილობით, გაზომილი მნიშვნელობითა და დარღვეული ზღვრით ტექსტში. სანამ მნიშვნელობა ზღვრის გარეთ რჩება, სხვა არაფერი ხდება: ტიკეტი ღიაა, ჩვენი ტექნიკოსები ინფორმირებულები არიან.
როცა მნიშვნელობა ნორმალურ დიაპაზონში ბრუნდება, მოდული იმავე ტიკეტში წერს განგაშის მოხსნას და წყვეტს კავშირს. ტიკეტი დაიხურება თუ არა შემდეგ, კვლავ ადამიანი წყვეტს – მნიშვნელობა, რომელიც ზღვარს ცოტა ხნით ქვემოთ ჩამოდის, ჯერ არ ნიშნავს, რომ მიზეზი აღმოფხვრილია.
ზღვრები მოწმდება ყოველ გაზომვაზე, იმისგან დამოუკიდებლად, ინახება თუ არა მნიშვნელობა. მუდმივად ძალიან მაღალი მნიშვნელობა განგაშად რჩება. და განგაშს არასდროს უნდა შეუშალოს ხელი იმან, რომ ტიკეტის შექმნა ვერ ხერხდება – თუ შექმნა ვერ მოხერხდა, ჩანაწერი და შეტყობინება მოწყობილობაზე მაინც რჩება.
შენახვა მხოლოდ იმისა, რაც იცვლება
მონაცემთა წერტილი, რომელიც ყოველ ხუთ წუთში მოწმდება, წელიწადში 105 000 მნიშვნელობას იძლევა. ასი მონაცემთა წერტილის შემთხვევაში ეს ათ მილიონზე მეტი სტრიქონია – მნიშვნელობებისთვის, რომლებიც უმეტესად საერთოდ არ შეცვლილა.
ამიტომ ინახება მხოლოდ ის, რაც ბოლო შენახულ მნიშვნელობასთან შედარებით დაყენებულ ზღვარზე მეტით განსხვავდება – თითო მონაცემთა წერტილზე აბსოლუტური სხვაობის სახით (მაგალითად, 0,5 °C), პროცენტული გადახრის სახით ან ყოველი ცვლილებისას. მიმდინარე მნიშვნელობა და ბოლო შემოწმების დრო მაინც ყოველთვის მონაცემთა წერტილზე დგას; მხოლოდ ისტორია იხვეწება და მცირდება.
სად ჩაიწერება მნიშვნელობები, ესეც დასარეგულირებელია: Odoo-ს მონაცემთა ბაზაში, MongoDB-ში ან CSV-ფაილების სახით Odoo-ს Filestore-ში. ამგვარად, გაზომილ მნიშვნელობებს ERP მონაცემთა ბაზის გარეთ ვინახავთ – იგივე პრინციპი, რაც ტრექინგის პოზიციის მონაცემებისთვის. ისტორია ნებისმიერ შემთხვევაში დიაგრამის სახით შეიძლება აჩვენოთ, საათობრივი შეკუმშვისას საშუალოს სახით და არა ჯამის სახით.
შევსების დონე პროცენტებში და არა ბაიტებში
ზოგი სიდიდე მოწყობილობაში როგორც ასეთი არ არის. დანაყოფის შევსების დონე დაკავებული მეხსიერებიდან და საერთო ზომიდან უნდა გამოითვალოს; ტემპერატურის სენსორები ხშირად მასშტაბირებულ მთელ რიცხვებს აბრუნებენ – 235 არის 23,5 გრადუსისთვის.
ამიტომ მონაცემთა წერტილს შეუძლია მნიშვნელობა გაცხადებული სახით გადაიღოს, კოეფიციენტზე გაამრავლოს ან მეორე OID-ის პროცენტად გამოთვალოს. ზღვრებისთვის ეს გადამწყვეტია: 90 %-იანი ზღვარი ნებისმიერ დისკის ზომაზე მოქმედებს. გიგაბაიტებში მითითებული ზღვარი ყოველ დისკზე ცალ-ცალკე უნდა განახლდეს.
არავის არ უწევს OID-ების ზეპირად ცოდნა
Windows და Linux სერვერებზე HOST-RESOURCES-MIB სტანდარტიზებულია: დისკები და ოპერატიული მეხსიერება ცნობილ ადგილას დგას. მოწყობილობის ამოცნობა კითხულობს ცხრილს, შევსების დონეებს პროცენტებად გადაითვლის და მონაცემთა წერტილებს განგაშის ზღვართან ერთად ერთი დაწკაპუნებით ქმნის.
ყველა დანარჩენისთვის არსებობს SNMP-ბრაუზერი, რომელიც OID-ის ხეს გადის და თითოეულ ნაპოვნ OID-ს მისი მიმდინარე მნიშვნელობით აჩვენებს – და, თუ კატალოგში ცნობილია, იმპორტირებული მწარმოებლის MIB-იდან სახელით, აღწერითა და ერთეულით. მონიშვნა საკმარისია.
რას იღებენ ამით ჩვენი მომხმარებლები
მოწყობილობები და მონაცემთა წერტილები მომხმარებლებზეა მიკუთვნებული. მომხმარებლის პორტალში ჩემი SNMP-მნიშვნელობები განყოფილებაში იპოვით თქვენი მოწყობილობების მიმდინარე გაზომილ მნიშვნელობებს და ბოლო 24 საათის, 7 დღის, 30 დღის ან 12 თვის ისტორიას დიაგრამის სახით – იგივე მნიშვნელობებს, რასაც ჩვენც ვხედავთ. ჩანს მხოლოდ ის, რაც თქვენს კომპანიაზეა მიკუთვნებული.
და როცა ზღვარი გადაჭარბდება, თქვენ არაფრის გაკეთება არ გჭირდებათ: ტიკეტი უკვე ჩვენთანაა, მოწყობილობით, მნიშვნელობითა და დროით, სანამ თქვენ შეამჩნევთ.
რა არ არის მოდული შეგნებულად
ეს არ არის სრული მონიტორინგის შემცვლელი ხელმისაწვდომობის შემოწმებებით, ესკალაციის ჯაჭვებითა და დამოკიდებულებათა ხეებით. ის SNMP-Trap-ებს არ იღებს, არამედ აქტიურად ამოწმებს. და ის ტიკეტს ავტომატურად არ ხურავს – განგაშის მოხსნა შეტყობინებაა და არა სტატუსის ცვლილება.
საქმე ზუსტად ერთ მონაკვეთს ეხება: გაზომილი მნიშვნელობიდან ზღვრის გავლით ტექნიკოსამდე, რომელიც საქმეს აგვარებს. ეს მონაკვეთი ახლა იმდენად მოკლეა, რამდენადაც შეიძლება.
თუ გსურთ თქვენი სერვერების, ქსელური მოწყობილობებისა თუ სენსორების ამ მონიტორინგში ჩართვა, მოგვმართეთ.