<div dir="ltr">To start off I don't know if this is the correct forum for this, but I'm hoping the right people read this.<div><br></div><div>As I was watching Andreas' presentation The Future of Nagios (<a href="http://www.youtube.com/watch?v=YgbbyyNIiHc" target="_blank">http://www.youtube.com/watch?v=YgbbyyNIiHc</a>) I started thinking about what could be done when it comes to Nagios/Naemon and SNMP traps.</div>

<div><br></div><div>I like a lot of things with Nagios and related products. However when it comes to SNMP traps I'm far from impressed. Most of the guides I've seen use a trap-service template where check-host-alive is used to reset the service after a trap has arrived. Each host which can send traps then get a generic "trap service". </div>

<div><br></div><div>To just receive alerts this work to notify us when something has gone wrong. However there are some shortcomings.</div><div><br></div><div>1. Currently (as far as I know) there isn't a good way to reset the service back to a normal state. It can be done manually or you can wait until the check-host-alive check is run.</div>

<div><br></div><div>2. If a trap has been received from a host and that same host sends another trap the second trap will replace the first trap. The old information will still be available through old notifications or logs. But now as viewable from any status as in Livestatus.</div>

<div><br></div><div>What I would like to see is the ability to dynamically create services as traps are received. Preferably you can create a few base service templates connected to different servicegroups and contactgroups and all that.</div>

<div><br></div><div>As an example I was looking at some traps from Huawei switches today. Specifically I wanted to see traps from a switch stack if one of the switch members die. For this Huawei has a trap called hwStackStackMemberLeave the trap will contain a varbind pointing to the switch id (hwMemberCurrentStackId for the member which died. Once the broken switch is replaced a new trap will be sent hwStackStackMemberAdd. This second trap will also contain a varbind with the id of the switch which is not returning to the stack.)</div>

<div><br></div><div>What would be really great is if we can have a switch host and then when we receive the first trap hwStackStackMemberLeave a service is dynamically created based on a template. Suck as</div><div><br></div>

<div>service { </div><div> host_name $switch-sending-trap$</div><div> use snmp-environment-trap</div><div> name stack-member-error</div><div> description Stack Member Error</div><div>}</div><div><br></div><div>This would remain in warning or critical state until it is cleared manually by an administrator or until we receive a hwStackStackMemberAdd trap. </div>
<div><br></div><div>Also since different members in a stack can fail we would need to handle this as we create dynamic services. So our template might actually look like this:</div><div><br></div><div><div>service { </div>
<div> host_name $switch-sending-trap$</div><div> use snmp-environment-trap</div><div> name stack-member-error-$valueof-hwMemberCurrentStackId$</div><div> description Stack Member Error $valueof-hwMemberCurrentStackId$</div>
<div>}</div></div><div><br></div><div>This could only be cleared if by a hwStackStackMemberAdd trap which contained the same switch id in the varbind. When this this happens the dynamic service would be removed (perhaps at the next scheduled run).</div>
<div><br></div><div>Another reason to set it up like this is that we can have additional traps being sent to the same host and view the status of all of them in real time. For example if a fan breaks in the switch, or the CPU usage gets to high we can create additional dynamic services for those.</div>
<div><br></div><div>Would anything like this be possible with the dynamic object creation planned for Naemon?</div><div><br></div><div><a href="http://networklore.com/" target="_blank">http://networklore.com/</a> </div><div>
<br></div><div><br></div></div>