SNMP monitorings Odoo 19: robežvērtība pārsniegta, biļete atvērta
Serveri, slēdži, UPS iekārtas, temperatūras sensori serveru telpā: gandrīz viss, kas ir pieslēgts tīklam, runā SNMP un var sniegt informāciju par savu stāvokli. Jautājums ir tikai, kas klausās – un kas notiek, kad kāda vērtība izkrīt no normas.
Infrastruktūrai, ko mēs uzturam saviem klientiem, mēs šo ķēdi tagad esam sakārtojuši vienā vietā: mūsu Odoo 19 aptauj ierīces, salīdzina vērtības ar robežvērtībām, un, ja robeža tiek sasniegta, tas atver biļeti Helpdesk – pie klienta, kuram ierīce pieder. Nevis atsevišķa monitoringa sistēma, kas pa e-pastu raksta Helpdesk, bet tā pati sistēma, kurā klients, ierīce un biļete tāpat ir saistīti.
Moduli mēs izstrādājām savai darbībai. Tā nav kopienas publikācija kā mūsu moduļi bankas izrakstiem vai e-rēķiniem, bet mūsu iekšējās uzturēšanas platformas daļa – tāpat kā izsekošana, par kuru ziņojām nesen.
No mērījuma līdz biļetei
Norise apzināti ir uzturēta vienkārša:
- Ierīce tiek izveidota ar adresi un piekļuves datiem (SNMP v1, v2c vai v3 ar autentifikāciju un šifrēšanu). Saglabājot Odoo iegūst sistēmas aprakstu, sistēmas nosaukumu un uptime – godīgāko apstiprinājumu, ka adrese un piekļuves dati ir pareizi.
- Ierīcē tiek definēti datu punkti: OID, mērvienība, klienta piesaiste.
- Laika plāns aptauj visus aktīvos datu punktus. Katrai ierīcei savienojas vienu reizi, nevis katram datu punktam – ar divdesmit OID uz viena slēdža tā ir atšķirība starp vienu un divdesmit sesijām.
- Katrs datu punkts var uzraudzīt robežvērtības: augšējo robežu, apakšējo robežu vai abas.
- Ja robeža tiek pārsniegta, rodas Helpdesk biļete.
Viena biļete katram incidentam, nevis katram mērījumam
Svarīgākais trauksmes loģikā: skaitās tikai stāvokļa maiņa. Kas katram mērījumam izveido biļeti, tam pēc nakts ar iesprūdušu vai raustošos sensoru ir trīs simti biļešu – tā nav trauksmes došana, tā ir apmākšana.
Tāpēc modulis katram datu punktam atceras, vai tas ir stāvoklī „Normāls“ vai „Trauksme“. Pirmoreiz pārsniedzot robežu, stāvoklis mainās, ierīces Chatter nonāk ziņa un tiek atvērta biļete – ar skarto klientu kā partneri, ar datu punktu, ierīci, izmērīto vērtību un pārkāpto robežu tekstā. Kamēr vērtība paliek ārpus robežas, nekas cits nenotiek: biļete ir atvērta, mūsu tehniķi zina.
Ja vērtība atgriežas normas diapazonā, modulis tajā pašā biļetē ieraksta paziņojumu par normalizēšanos un noņem saikni. Vai biļete pēc tam tiek slēgta, joprojām izlemj cilvēks – vērtība, kas īslaicīgi nokrīt zem robežas, vēl nenozīmē, ka cēlonis ir novērsts.
Robežvērtības tiek pārbaudītas katrā mērījumā neatkarīgi no tā, vai vērtība tiek saglabāta. Pastāvīgi pārāk augsta vērtība paliek trauksme. Un trauksme nekad nedrīkst izgāzties tāpēc, ka biļeti nevar izveidot – ja izveide neizdodas, protokols un ziņa pie ierīces tik un tā paliek.
Saglabāt tikai to, kas mainās
Datu punkts, ko aptauj ik piecas minūtes, gadā dod 105 000 vērtību. Ar simts datu punktiem tie ir vairāk nekā desmit miljoni rindu – vērtībām, kas parasti nemaz nav mainījušās.
Tāpēc tiek saglabāts tikai tas, kas no pēdējās saglabātās vērtības atšķiras par vairāk nekā iestatīts slieksnis – katram datu punktam kā absolūta starpība (piemēram, 0,5 °C), kā procentuāla novirze vai pie katras izmaiņas. Pašreizējā vērtība un pēdējās aptaujas laiks tik un tā vienmēr ir pie datu punkta; tikai vēsture tiek retināta.
Kur vērtības tiek rakstītas, ir arī iestatāms: Odoo datubāzē, MongoDB vai kā CSV faili Odoo filestore. Tādējādi mēs mērījumu vērtības paturam ārpus ERP datubāzes – tas pats princips kā ar izsekošanas pozīciju datiem. Vēsturi jebkurā gadījumā var attēlot kā diagrammu, ar stundu agregāciju kā vidējo, nevis summu.
Aizpildījums procentos, nevis baitos
Daži lielumi ierīcē kā tādi nav pieejami. Nodalījuma aizpildījums jāaprēķina no aizņemtās atmiņas un kopējā lieluma; temperatūras sensori bieži sniedz mērogotus veselus skaitļus – 235 nozīmē 23,5 grādus.
Tāpēc datu punkts var pārņemt vērtību, kā tā ziņota, reizināt ar koeficientu vai aprēķināt kā procentuālo daļu no otra OID. Robežvērtībām tas ir izšķiroši: 90 % robeža der jebkura diska lielumam. Robeža gigabaitos būtu jāuztur katram diskam atsevišķi.
Nevienam nav jāzina OID no galvas
Windows un Linux serveriem HOST-RESOURCES-MIB ir standartizēta: diski un operatīvā atmiņa atrodas zināmā vietā. Ierīču atpazīšana nolasa tabulu, pārrēķina aizpildījumu procentos un ar vienu klikšķi izveido datu punktus kopā ar trauksmes robežu.
Visam pārējam ir SNMP pārlūks, kas iet cauri OID kokam un parāda katru atrasto OID ar tā pašreizējo vērtību – un, ja tas zināms katalogā, ar nosaukumu, aprakstu un mērvienību no importētās ražotāja MIB. Pietiek atzīmēt.
Ko klienti no tā iegūst
Ierīces un datu punkti ir piešķirti klientiem. Klientu portālā sadaļā Manas SNMP vērtības atradīsiet savu ierīču pašreizējās mērījumu vērtības un pēdējo 24 stundu, 7 dienu, 30 dienu vai 12 mēnešu vēsturi kā diagrammu – tās pašas vērtības, ko redzam arī mēs. Redzams ir tikai tas, kas piešķirts jūsu uzņēmumam.
Un, ja robežvērtība tiek pārsniegta, jums nekas nav jādara: biļete mums jau ir, ar ierīci, vērtību un laiku, pirms jūs to pamanāt.
Kas modulis apzināti nav
Tas nav pilnvērtīga monitoringa aizstājējs ar pieejamības pārbaudēm, eskalācijas ķēdēm un atkarību kokiem. Tas nepieņem SNMP traps, bet aptauj aktīvi. Un tas neaizver nevienu biļeti automātiski – paziņojums par normalizēšanos ir ziņa, nevis statusa maiņa.
Runa ir tieši par vienu posmu: no mērījuma caur robežu līdz tehniķim, kas par to rūpējas. Šis posms tagad ir tik īss, cik tas var būt.
Ja vēlaties savus serverus, tīkla ierīces vai sensorus iekļaut šajā uzraudzībā, vērsieties pie mums.