Alert from 3rd party - maintenance mode not respected

Bug #1551217 reported by Ingeborg Hellemo
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Network Administration Visualized
Fix Released
Undecided
Morten Brekkevold
4.4
Fix Released
High
Morten Brekkevold
4.5
Fix Released
Medium
Morten Brekkevold

Bug Description

We use Xymon and UNINETT's plugin hobbit-nav.py which enters alerts into NAV's eventqueue.

These events generates alarms and shows up in the status listing even if the host in question is on maintenance.

Changed in nav:
importance: Undecided → High
milestone: none → 4.4.4
assignee: nobody → Morten Brekkevold (mbrekkevold)
Revision history for this message
Morten Brekkevold (mbrekkevold) wrote :

This is actually two different issues.

These alert have likely never been held back from your alert profile, because withholding of SMS/e-mail/jabber/etc alerts takes place in specific eventengine plugins. 3rd party alerts, like those from Xymon, do not have specific eventengine plugins, and are only processed by the generic eventengine handler. This handler doesn't verify maintenance status at all, and has _never_ done this (in the Python incarnation, which I believe has been around since NAV 3.6 or so). We should probably do this in the generic handler too, though.

When it comes to the status page, the problem is actually that the Xymon alerts have a subject ID that corresponds to Xymon's internal service number. NAV tries to check the maintenance status for this subject, but since it doesn't have any internal knowledge of this Xymon-specific ID, it finds no such thing. However, it should probably fall back to just checking the maintenance status of the netbox itself, if the Xymon alert is associated with a netbox registered in NAV.

In the latter case, I believe the only difference you'll find from before is that Xymon alerts weren't displayed at all in the status page in NAV versions prior to 4.2 (november 2014).

Changed in nav:
status: New → Confirmed
Revision history for this message
Morten Brekkevold (mbrekkevold) wrote :

I have committed a partial fix for your issue here: https://nav.uninett.no/hg/stable/rev/9104b8aa36e0

This fixes the status page issue (given that NAV has actually made the connection between the hobbit alert and a netbox registered in NAV).

A change in the event engine's default behavior may take more time, and have side-effects we haven't thought of yet, so I am reluctant to fix that in a simple maintenance release.

Changed in nav:
status: Confirmed → In Progress
Revision history for this message
Ingeborg Hellemo (ingeborg-hellemo) wrote : Re: [Bug 1551217] Re: Alert from 3rd party - maintenance mode not respected

<email address hidden> said:
> A change in the event engine's default behavior may take more time, and have
> side-effects we haven't thought of yet, so I am reluctant to fix that in a
> simple maintenance release.

Have implemented and will keep you posted about issues. So far so good.

--Ingeborg

Changed in nav:
milestone: 4.4.4 → none
Revision history for this message
Ingeborg Hellemo (ingeborg-hellemo) wrote :

<email address hidden> said:
> Status: Fix Committed => Fix Released

But this only fixes the status page listing, right? You will still be working
on suppressing the alarms?

Revision history for this message
Morten Brekkevold (mbrekkevold) wrote :

I've targeted the issue for both the 4.4 and 4.5 series. The 4.4 fix has been released in 4.4.4.

I wouldn't change eventengine in 4.4, but we can try to get something in for 4.5 (It would be cleaner to report it as a separate issue, though).

Revision history for this message
Morten Brekkevold (mbrekkevold) wrote :

fix for the eventengine part of the problem committed to trunk here: https://nav.uninett.no/hg/default/rev/17baf17137d2

Changed in nav:
importance: High → Undecided
Changed in nav:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.