SNMP-valvonta Odoo 19:ssä: raja-arvo ylitetty, tiketti avattu
Palvelimet, kytkimet, UPS-laitteet, palvelinhuoneen lämpötila-anturit: lähes kaikki, mikä on verkossa kiinni, puhuu SNMP:tä ja voi kertoa tilastaan. Kysymys on vain, kuka kuuntelee – ja mitä tapahtuu, kun jokin arvo karkaa käsistä.
Asiakkaillemme ylläpitämällemme infrastruktuurille olemme nyt koonneet tämän ketjun yhteen paikkaan: Odoo 19 kyselee laitteilta, vertaa arvoja raja-arvoihin, ja kun raja saavutetaan, se avaa tiketin Helpdeskiin – sen asiakkaan alle, jolle laite kuuluu. Ei erillistä valvontajärjestelmää, joka kirjoittaa sähköpostilla Helpdeskiin, vaan sama järjestelmä, jossa asiakas, laite ja tiketti ovat joka tapauksessa yhteydessä toisiinsa.
Moduulin kehitimme omaan käyttöömme. Se ei ole yhteisöjulkaisu kuten tiliotteita tai sähkölaskuja koskevat moduulimme, vaan osa sisäistä ylläpitoalustaamme – kuten seuranta, josta kerroimme viimeksi.
Mittausarvosta tikettiin
Kulku on tarkoituksella pidetty yksinkertaisena:
- Laite luodaan osoitteen ja tunnistetietojen kanssa (SNMP v1, v2c tai v3 todennuksella ja salauksella). Tallennettaessa Odoo hakee järjestelmän kuvauksen, järjestelmän nimen ja Uptimen – rehellisin vahvistus siitä, että osoite ja tunnistetiedot ovat oikein.
- Laitteelle määritetään datapisteet: OID, yksikkö, asiakaskohdistus.
- Aikataulu kyselee kaikki aktiiviset datapisteet. Laitetta kohden yhdistetään kerran, ei datapistettä kohden – kahdellakymmenellä OID:llä yhdessä kytkimessä se on ero yhden ja kahdenkymmenen istunnon välillä.
- Jokainen datapiste voi valvoa raja-arvoja: ylärajaa, alarajaa tai molempia.
- Jos raja ylitetään, syntyy Helpdesk-tiketti.
Yksi tiketti per tapahtuma, ei per mittaus
Hälytyslogiikan tärkein kohta: vain tilanvaihdos on merkitsevä. Se, joka luo tiketin jokaisesta mittauksesta, saa yhden jumittuneen tai värähtelevän anturin jälkeen yön yli kolmesataa tikettiä – se ei ole hälyttämistä, se on sumuttamista.
Moduuli muistaa siksi datapistekohtaisesti, onko se tilassa ”Normaali” vai ”Hälytys”. Kun raja ylitetään ensimmäistä kertaa, tila vaihtuu, viesti päätyy laitteen Chatteriin ja tiketti avataan – asianosaisella asiakkaalla kumppanina, ja tekstissä ovat datapiste, laite, mitattu arvo ja rikottu raja. Niin kauan kuin arvo pysyy rajan ulkopuolella, ei tapahdu mitään muuta: tiketti on auki, teknikkomme tietävät asiasta.
Kun arvo palaa normaalialueelle, moduuli kirjoittaa saman tiketin sisälle hälytyksen päättymisen ja purkaa yhteyden. Se, suljetaanko tiketti sen jälkeen, on edelleen ihmisen päätettävissä – arvo, joka putoaa hetkeksi rajan alle, ei vielä tarkoita, että syy olisi korjattu.
Raja-arvot tarkistetaan jokaisella mittauksella riippumatta siitä, tallennetaanko arvo. Jatkuvasti liian korkea arvo pysyy hälytyksenä. Ja hälytys ei saa koskaan kaatua siihen, ettei tikettiä voida luoda – jos luonti epäonnistuu, loki ja laitteen viesti jäävät silti voimaan.
Tallennetaan vain muutokset
Datapiste, jota kysellään viiden minuutin välein, tuottaa 105 000 arvoa vuodessa. Sadalla datapisteellä se on yli kymmenen miljoonaa riviä – arvoille, jotka useimmiten eivät ole muuttuneet lainkaan.
Tallennetaan siksi vain se, mikä poikkeaa viimeksi tallennetusta arvosta enemmän kuin asetettu kynnys – datapistekohtaisesti absoluuttisena erotuksena (esimerkiksi 0,5 °C), prosentuaalisena poikkeamana tai jokaisella muutoksella. Nykyinen arvo ja viimeisen kyselyn ajankohta ovat silti aina datapisteellä; vain historiaa harvennetaan.
Minne arvot kirjoitetaan, on myös säädettävissä: Odoon tietokantaan, MongoDB:hen tai CSV-tiedostoina Odoon Filestoreen. Pidämme mittausarvot näin poissa ERP-tietokannasta – sama periaate kuin seurannan sijaintitiedoissa. Historian voi joka tapauksessa näyttää kaaviona, tuntikohtaisessa tiivistyksessä keskiarvona, ei summana.
Täyttöaste prosentteina tavujen sijaan
Kaikki suureet eivät ole laitteessa sellaisenaan. Osion täyttöaste on laskettava käytetystä tallennustilasta ja kokonaiskoosta; lämpötila-anturit palauttavat usein skaalattuja kokonaislukuja – 235 tarkoittaa 23,5 astetta.
Datapiste voi siksi ottaa arvon sellaisenaan, kertoa sen kertoimella tai laskea sen prosenttiosuutena toisesta OID:stä. Raja-arvoille tämä on ratkaisevaa: 90 %:n raja pätee jokaiselle levykoolle. Gigatavuina annettu raja pitäisi ylläpitää asemakohtaisesti.
Kenenkään ei tarvitse osata OID:itä ulkoa
Windows- ja Linux-palvelimilla HOST-RESOURCES-MIB on standardoitu: asemat ja keskusmuisti ovat tunnetussa paikassa. Laitetunnistus lukee taulukon, muuntaa täyttöasteet prosenteiksi ja luo datapisteet hälytysrajoineen yhdellä napsautuksella.
Kaikkea muuta varten on SNMP-selain, joka käy läpi OID-puun ja näyttää jokaisen löydetyn OID:n nykyisen arvon – ja, jos se on luettelossa tiedossa, nimen, kuvauksen ja yksikön tuodusta valmistajan MIB:stä. Rastittaminen riittää.
Mitä asiakkaamme tästä hyötyvät
Laitteet ja datapisteet on kohdistettu asiakkaille. Asiakasportaalista löydät kohdasta Omat SNMP-arvoni laitteidesi nykyiset mittausarvot ja viimeisten 24 tunnin, 7 päivän, 30 päivän tai 12 kuukauden historian kaaviona – samat arvot, jotka mekin näemme. Näkyvissä on vain se, mikä on kohdistettu yrityksellesi.
Ja kun raja-arvo ylittyy, sinun ei tarvitse tehdä mitään: tiketti on jo meillä, laitteen, arvon ja kellonajan kera, ennen kuin huomaat sitä.
Mitä moduuli tietoisesti ei ole
Se ei korvaa täydellistä valvontaa, jossa on saatavuustarkistukset, eskalaatioketjut ja riippuvuuspuut. Se ei vastaanota SNMP-trappeja vaan kyselee aktiivisesti. Eikä se sulje tikettiä automaattisesti – hälytyksen päättyminen on viesti, ei tilanmuutos.
Kyse on täsmälleen yhdestä reitistä: mittausarvosta rajan kautta teknikolle, joka hoitaa asian. Tämä reitti on nyt niin lyhyt kuin se voi olla.
Jos haluat ottaa palvelimesi, verkkolaitteesi tai anturisi mukaan tähän valvontaan, ota yhteyttä.