How to manage multiple instances of the same service

[dabbene]

Hi, I need to manage multiple instances of the same service, in order to have alarms active for a service due to more events that have different values attributes showed in infomation text.
I need that for the service A , that is alarmed for the event E1 if will occur the event E2, it doesn't hide the E1 and in the "service problems " view I can have both.

I cannot create different services , because possible events are a lot and i need to manage them dynamically.

I know that for snmp traps there is a specific addon. i would to know if there is something similar for generic alarms.
Thanks

Ignazio

[agriffin]

I am a little confused about what you're trying to accomplish. So you need to perform two service checks within a single Nagios service? Would you care to clarify what you're looking for?

[dabbene]

Hi , i try to do a sample. I have a service called "application alarm" that is related to a program faults.
So every time the program fails it sends an alarm event that is managed by a nagios plugin.
So if the program fails during the processing of the data "A" , it sends "alarm A", if it fails for the data "B" it sends "alarm B" and so on.
It executes a lot of tasks in parallel so it can fail for several reasons at the same time.I need to manage all alarm events

All fail reasons are a lot and they can change dynamically, so I won't to create and configure a service for all of them.


So in a while, I have the service "application alarm" in the critical state for the event "Alarm A" .and then can happen that the same service "application alarm" fails also for the event "Alarm B" , the nagios service state left to critical, but the "information text " will become "alarm B" and I lost all info about the "alarm A".

How can I manage this scenario? Conceptually is the same problem that I have to manage snmp traps from a device.

I hope I was more clear.

Thanks in advance

Ignazio

[agriffin]

I'm not aware of any generic add-on that does this. I'm not quite sure what the best way to manage this is, though the information is not thrown away. You can still look at old states in the event log. Maybe you could set up an event handler that checks the log to see if the old status recovered, and if not, resubmit the old status.

[jsmurphy]

This is something that members of my team found difficult about the transition to Nagios... a lot of them were used to Solarwinds, Tivoli or OpenView where a staple of the monitoring is done by keeping a list of problems rather than the most recent state. States are awesome for active data but it makes handling passive data much more difficult. To get around the not-so-great handling of passive data we forward any traps/passive alerts to a team mailbox with a rule to move any passive emails to a particular folder... this simulates the list over time functionality that they are used to (even if it doesn't give you separated host views, which isn't a problem as long as the verbosity is tuned down).

This is probably your best bet unless you want create a custom webpage with the NDOUtils backend that will mimic a problem list... I've actually been considering building an XI addon with that purpose in mind.

[dabbene]

Thanks for your reply, I suspected that there wasn't any stuff to cover this need.
I think It is an actual limit of Nagios vs other NMS platforms.
I'm evaluating to implement a plugin for that.
Thanks
Ignazio

[agriffin]

Please let us know if you come up with a solution, I'm sure many others could benefit from it!