Hei,
morten.brekkevold@uninett.no said:
On Thu, 07 Aug 2014 17:09:24 +0200 Borge Brunes borge.brunes@uit.no wrote:
Hmm. Sikkert. Tja.
Jeg ser jo at noe av variablene, bla. ifname, jeg savner allerede ligger inne, men blir ikke funnet/postet?
Hvor finner jeg oversikt over hvilke variabler jeg kan bruke?
Det finnes dessverre ingen god enhetlig oversikt over det, men vi burde dokumentere litt mer rundt det å modifisere maltekstene selv.
Noen variabler er tilgjengelig for _alle_ alarmer, fordi de kommer fra selve AlertHistory og/eller AlertQueue-modellene til NAV. I tillegg kan alle programsnutter som genererer events velge å legge ved et eget sett med "custom" variabler med tekstverdier til hver enkelt hendelse. Det er disse som blir vanskelig å lage noen god oversikt over.
Med releasen i går la jeg til muligheten for å debuglogge alarmtekst-produksjonen til eventengine. Om man slår på debuglogging av loggeren "nav.eventengine.alerts.template" i logging.conf, vil eventengine for hver genererte alarm debuglogge hvilke variabler den har tilgjengeliggjort for malene, og også hvordan den utfylte malen ser ut med den gitte alarmens verdier.
Det er lite fleksibelt om all kode som poster events må huske på å legge til det samme settet med customvariabler, spesielt hvis den samme eventen kan postes av forskjellige delsystemer (som raskt er tilfelle i krysningen mellom snmptrapd og idpevpoll).
En bedre løsning for fremtiden vil antageligvis være at man bygger inn mer kunnskap om de forskjellige alarmene i modellen til NAV, slik at man i maltekstene kan hente ut alarm-subjektet i en egen variabel. Dette vil da være en Netbox-instans, om alarmen omhandler en netbox, eller en Interface-instans om alarmen omhandler en port, osv. Det er noe sånt jeg vil vurdere å lage som respons på feature-requesten din, Børge.
Dette blir kanskje litt på siden, men jeg skriver noen ord likevel.
Under sjakk-ol her i Tromsø så hadde vi ansvaret for nettet sammen med Datametrix. Fungerte alderes utmerket.
Ganske snart så ble det klart at Cisco PRIME ikke var bra nok for overvåking av utstyret/nettet, så vi måtte finne på noe som var enkelt å hive opp. Vurderte NAV, men Dax hadde ikke erfaring med dette så det ble The Dude fra Mikrotik: http://www.mikrotik.com/thedude
Veldig mange år siden jeg sist hadde sett på denne. Utviklingen er stoppet opp, kjører på Windows (men med web-grensenitt også), men bortsett fra det så gjorde den jobben.
Når vi først hadde satt den opp så spanderte jeg litt tid på hvordan ting fungerte, og synes at det er et par ting som vi bør se nærmere på:
1) Først og fremt så synes jeg at "StatusKartet" er veldig bra, med flere nivåer slik at store nett kan deles opp. Slik NAVs nettmap er i dag så bruker ikke vi dette fordi det er for omfangsrik, og det ikke er mulig dele opp etter f.eks. bygg. Våre brukere (bla. Orakeltjenesten) har etterspurt denne type kart med oversikt slik at man kan på en enkelt måte se om alt er "grønnt".
2) Konfigurering av hva som skal overvåkes på en boks er veldig greit. Ønsker man å overvåke endring i f.eks. status på en link så legger bare inn overvåking av OID til interface så legges denne inn som en tjeneste som overvåkes.
Anbefaler dere å ta en kjapp titt på The Dude for å hente inspirasjon og se hvordan andre har løst de samme problemstillingene som vi har hatt.
Børge
On Mon, 18 Aug 2014 13:26:14 +0200 Borge Brunes borge.brunes@uit.no wrote:
Dette blir kanskje litt på siden, men jeg skriver noen ord likevel.
Under sjakk-ol her i Tromsø så hadde vi ansvaret for nettet sammen med Datametrix. Fungerte alderes utmerket.
Ganske snart så ble det klart at Cisco PRIME ikke var bra nok for overvåking av utstyret/nettet, så vi måtte finne på noe som var enkelt å hive opp. Vurderte NAV, men Dax hadde ikke erfaring med dette så det ble The Dude fra Mikrotik: http://www.mikrotik.com/thedude
Interessant - Vidar Stokkenes påsto på IRC at han hadde vært innom og sett at Sjakk-OL-gjengen brukte NAV :)
Når vi først hadde satt den opp så spanderte jeg litt tid på hvordan ting fungerte, og synes at det er et par ting som vi bør se nærmere på:
- Først og fremt så synes jeg at "StatusKartet" er veldig bra, med flere nivåer slik at store nett kan deles opp. Slik NAVs nettmap er i dag så bruker ikke vi dette fordi det er for omfangsrik, og det ikke er mulig dele opp etter f.eks. bygg. Våre brukere (bla. Orakeltjenesten) har etterspurt denne type kart med oversikt slik at man kan på en enkelt måte se om alt er "grønnt".
Vi har vel vært inne på tanken om å ha statusmarkeringer på kartet, men så langt kom vi aldri. Det var aldri lett å jobbe med koden som ble skrevet for den siste inkarnasjonen av Netmap.
Nå har vi riktignok hatt en sommerstudent her i år som har ryddet i denne koden, og han har blant annet innført filtrering på room og location, som kan være det du er ute etter her.
Jeg har faktisk planlagt å gjøre en code review med ham på akkurat dette om noen få strakser.
- Konfigurering av hva som skal overvåkes på en boks er veldig greit. Ønsker man å overvåke endring i f.eks. status på en link så legger bare inn overvåking av OID til interface så legges denne inn som en tjeneste som overvåkes.
Jeg tror NAV alltid har fungert litt motsatt vei. Filosofien har vært "overvåk alt" og la brukeren velge hva vedkommende ønsker varsling av i etterkant.
Det ville selvfølgelig være mulig å skrive om NAV til at man heller eksplisitt må slå på overvåkning av diverse ting, men det vil være en fullstendig reversering av hva NAV driver på med i dag, og spørsmålet er om vi da trenger Alert Profiles lenger. Og hvor håndterbart kan man gjøre dette når man overvåker 1600 bokser?
Anbefaler dere å ta en kjapp titt på The Dude for å hente inspirasjon og se hvordan andre har løst de samme problemstillingene som vi har hatt.
Har notert meg det bak øret :)