morten.brekkevold@uninett.no said:
Slik jeg ser det så er det unødvendig og skaper bare ekstra støy at det sendes ut "Link down" når boksen bak "Link down" allerede er meldt nede. > Imidlertid så er det svært nyttig å få melding dersom en link går ned uten at boksen bak går ned. Gjelder selvsagt bare for bokser med redundante uplinker.
Er enig i tankegangen her. Pr. i dag gjør ikke eventEngine noen særbehandling av linkState-events, de bare dyttes ukritisk til alarmkøen.
Det medfører også et annet problem vi har observert: Noen konfigurerte alle HP-switchene sine til å sende linktraps til NAV. De hadde en rekke porter som flapper som bare det, og ble dermed bombardert med alarmer fra NAV.
Sett bort i fra at de ikke burde ukritisk sende alle slike traps til NAV (hvem bryr seg om linkstate-alarmer på aksessporter?), så burde eventEngine gjøre som for boxState/moduleState og innføre karantenetid på linkState-alarmer, slik at flapping ikke utløser alarmskred. Dette er forøvrig nevnt her: https://bugs.launchpad.net/nav/+bug/939429
Ser ut som noen(tm) må knekke noen Java-knoker likevel ;P
Jeg er litt usikker på jeg er helt med her. Er det ikke slik at det er to forskjellige måter at linkState-events kan oppstå:
1) det sendes snmp-traps til trapmottak (snmptrapd) 2) ipdevpoll
Pt. så har ikke vi satt opp boksene vår til å sende traps til NAV så jeg har bare sett på ipdevpoll.
Min oppfatning av problemstillingen er at uansett "delsystem" (link-state, snmpagent down, tjenesteovervåker osv) så må skyggestatus sjekkes. Det er ingen vits å sende melding om link-down, tjenste X osv er nede dersom boksen er nede.
Man gjør vel dette i dag når en box bak en ruter går ned?
Dette med skyggestatus har jo vært en av styrkene til NAV.
Børge
On Fri, 02 Mar 2012 11:46:41 +0100 Borge Brunes borge.brunes@uit.no wrote:
morten.brekkevold@uninett.no said:
Slik jeg ser det så er det unødvendig og skaper bare ekstra støy at det sendes ut "Link down" når boksen bak "Link down" allerede er meldt nede. > Imidlertid så er det svært nyttig å få melding dersom en link går ned uten at boksen bak går ned. Gjelder selvsagt bare for bokser med redundante uplinker.
Er enig i tankegangen her. Pr. i dag gjør ikke eventEngine noen særbehandling av linkState-events, de bare dyttes ukritisk til alarmkøen.
Det medfører også et annet problem vi har observert: Noen konfigurerte alle HP-switchene sine til å sende linktraps til NAV. De hadde en rekke porter som flapper som bare det, og ble dermed bombardert med alarmer fra NAV.
Sett bort i fra at de ikke burde ukritisk sende alle slike traps til NAV (hvem bryr seg om linkstate-alarmer på aksessporter?), så burde eventEngine gjøre som for boxState/moduleState og innføre karantenetid på linkState-alarmer, slik at flapping ikke utløser alarmskred. Dette er forøvrig nevnt her: https://bugs.launchpad.net/nav/+bug/939429
Ser ut som noen(tm) må knekke noen Java-knoker likevel ;P
Jeg er litt usikker på jeg er helt med her. Er det ikke slik at det er to forskjellige måter at linkState-events kan oppstå:
- det sendes snmp-traps til trapmottak (snmptrapd)
- ipdevpoll
Pt. så har ikke vi satt opp boksene vår til å sende traps til NAV så jeg har bare sett på ipdevpoll.
Min oppfatning av problemstillingen er at uansett "delsystem" (link-state, snmpagent down, tjenesteovervåker osv) så må skyggestatus sjekkes. Det er ingen vits å sende melding om link-down, tjenste X osv er nede dersom boksen er nede.
Man gjør vel dette i dag når en box bak en ruter går ned?
Dette med skyggestatus har jo vært en av styrkene til NAV.
Det spiller ingen rolle hvilket delsystem som genererer hendelser. Det er eventEngine som evaluerer hendelser og bestemmer hvorvidt det skal genereres alarm.
Egentlig skyggestatus finnes bare på boksnivå, i.e. boxShadow. En boxDown-hendelse som ser ut til å skyldes skyggeforhold oversettes til en boxShadow-alarm i stedet for å bli sendt som en boxDown-alarm. Dette gjøres altså på bakgrunn av topologi-informasjon.
Ingen andre "enheter" i NAV-sammenheng har egen skyggestatus, ikke engang tjenester.
Det er derimot, som sagt, opp til eventEngine hvorvidt det skal genereres alarm for en hendelse. Denne avgjørelsen tas lokalt i den pluginen som behandler en hendelse. Det er ikke alle hendelser som har egen plugin, og de behandles da bare på generelt vis, og da er det ingen tilbakeholdenhet med å varsle alle hendelser umiddelbart.
Men jeg tolker deg dithen at det du egentlig er ute etter, er at eventEngine skal holde tilbake alarmer om ting som linkState, snmpAgentState, serviceState etc. dersom en boks er nede, ikke at vi skal ha linkShadow-, snmpAgentShadow- og serviceShadow-alarmer.
Her trengs det nok uansett en opprydning.
-
Borge Brunes -
Morten Brekkevold