2 Replies Latest reply on Apr 15, 2009 7:51 AM by Miron

    Meaningful trap alerts

    klc2009

      We are trying to figure out the best way to get trap alerts that are not full of a lot of useless information mixed in with what we really need to know.

      At this point, we are getting traps from our AC units, since the way these units work a MIB entry for the condition does not exist unless the condition itself exists. When the condition clears, the MIB entry is removed. Thus, the need for traps rather than UnDPs.

      We need to have the device name in the email message generated by the trap alert, but using the ${DNS} variable does not work because I'm told "we don't use reverse dns on our environmental systems". However, if I look at the traps in Trap Viewer, I see a column for IP Address and a column for Hostname (which also lists the IP address) BUT when I look at Traps in the Orion web interface, I see an IP Address column and a column named Caption that lists the name of the device. How is it that the web interface can display the device name, but I can't get it into an email message?

      The other dilemma is this: in order for the email message to contain the actual problem without the receiver having to scroll through a bunch of other stuff to get to it, we have to set up a separate alert for each condition. For instance, one of the trap conditions is lgpConditionHumidifierProblem. So I have an alert set up to check for that condition in the trap message. If it exists, then the email message with subject line "IP Address (again, heres where I want device name): Humidifier Problem". This would work fine, except that there are 186 possible trap conditions on these units and I really think creating a separate alert for each one is not a practical solution.

      I considered trying to do something like have the alert action set up to write the trap to a file, then add another alert action to run an external program. The program would pause for a few seconds to allow the file to be written, then it would parse the file and do some translation of it's own (substitute IP with device name, substitute condition description with something in plain english, etc), write it to another file and then send email containing the new file's contents. This might work, too, except in the case where several traps arrive simultaneously.

      So what solutions are others using? I have read a lot of posts about trap alert issues, but none that I read suggest any good solutions.