Nagios Support Forum

Ok, I have been so busy since the conference, I haven't posted nearly enough on the forums, I need abrist to tell me no at least once a week...so here is his chance!

I have some devices that when there are issues, send 100's if not 1000's of traps. Alerting on all of those would be absurd. In snmptt.conf, they are also set as NORMAL also, so they are all coming across as OK. that works for me as it causes no alerts for the many traps. However, if I click on the state history of the trap service, it shows NOTHING. If I change the traps to come across as WARNING, then if I click on STATE HISTORY, I see them all, even though its only changing from OK to WARNING the first time.

Is there no way to include all the OK traps in the list as well? I can do it by searching the event log, but normal user's don't have access to look at the event log. If they were able to see all the traps in state history, they could make that part of their routine throughout the day to look there. Otherwise, I'll have to schedule a report of the event long or something.

I know NSTI will also help with this, but version 2.5/3.0/whatever is still being worked on!

Any suggestions? Did I explain this well enough?

...This is not currently possible. But ti may be a relatively easy change in the php. Currently, it will only show soft and hard states, specifically when the states change. So if all the traps are OK, then you will only see the first state change. If you are not alerting on these traps, you may be able to set the check to volatile, forcing nagios to treat every trap as a state change (back to OK). I have not tested this as I am starting a remote at the moment, so if you want, guinea pig this and let us know what happened!

I will try to look at the php at some point, and if it is not an easy change I will submit an internal feature request.

Makes sense since all non-OK traps are considered HARD. Let me test your work around...will report back.

Tried it on two devices. Made no change in what shows up in the State Change page

Hmm, if I look at it in Nagios Core and then Service History, it shows me all the traps there, just not very readable. It also lists them all as HARD states just like warning and crit traps. So why does the service history in XI only show warning and criticals when in Core it shows all? Hmmmmmmm? LOL

Going back a post or two here, I believe OK states should be considered hard, or maybe you mentioned that in this last one. The present explanation for the state change information would be filtering on the php side. The information as you found is absolutely available via core, and should also be in the mysql db, we have just chosen to filter it out for "more important" states. While not ideal, have you looked into running reports for state change on particular hosts? I believe that will show OK, although I have not validated that. Also interesting that is_volatile did not do anything in this case, hence leading me again to php side filtering of the shown states.

sreinhardt wrote:While not ideal, have you looked into running reports for state change on particular hosts? I believe that will show OK, although I have not validated that.

That didn't work either, still did not show OK.
EDIT: It is the same PHP file, so still filtering out the OK

Well, it has come to this . . . .Nope.
NDO only stores state changes, and apparently these state changes do not include volatile services. . .

abrist wrote:Well, it has come to this . . . .Nope.
NDO only stores state changes, and apparently these state changes do not include volatile services. . .

So basically I need to go into snmptt.conf and set everything to warning or critical so NDO will then log it? Because saying it only logs state 'changes' is a misnomer. it logs all warning and critical ones no matter what the previous state was. So if a warning comes in and the state is already warning, the new trap still gets logged.

EDIT: NSTI would of course make this entire conversation worthless as they could just look through that if I had it working

You sir are correct, damn I hate to admit that in this case. Nick ever ship you off a copy of the new code? It's far from perfect but its much much better than 2.0.