All questions related to installations, configurations and maintenance of Advanced Host Monitor (including additional tools such as RMA for Windows, RMA Manager, Web Servie, RCC).
What I'm thinking of, is to using a 3th party program that runs next to RMA on the RMA server.
It catches SNMP Traps and logs them into a log file.
the RMA can use the LogFile testmethode to see what new traps are received...
combine this with the date translations macro and you have a good system..
It is not realtime, but if you set the shedule to 5 minutes, its almost realtime...
jtaugher wrote:(btw .. the "Notify me when a reply is posted" doesn't appear to work).
Works fine with me... checked your email adres in your profile ?
plambrecht wrote:What I'm thinking of, is to using a 3th party program that runs next to RMA on the RMA server.
It catches SNMP Traps and logs them into a log file.
the RMA can use the LogFile testmethode to see what new traps are received...
combine this with the date translations macro and you have a good system..
It is not realtime, but if you set the shedule to 5 minutes, its almost realtime...
That's an outstanding idea. Let me know if you find anything. I've been looking for similar, without much luck at this point. I'm still a newbie with SNMP, so I end at a product that I think'll do it, and it can't.
Question is why you do not send messages directly to HostMonitor?
- because SNMP message is not encrypted?
- or you don't want to have open port in HostMonitor's network?
Solutions should be different :
- in 1st case we can develop some command line utility (or modify RMA) to encrypt SNMP messages and send to HostMonitor. HostMonitor will listen for such messages just like it listens for regular SNMP messages now...
- in 2nd case I don't see better idea than plambrecht have. Message must be stored in some log...
(btw .. the "Notify me when a reply is posted" doesn't appear to work).
It works. May be your spam filter rejects messages?
I think the only reasonable thing you can do is to base your decision upon HM's current functionality, not what may or may not be implemented in the future.
I think Alex is right to keep the 'wish list/to do list' internal -- like any developer that listens to their customers, Alex needs to collect these requests from customers -- but also needs the flexibility to decide which of these requests are in the best interest of HM. Priorities change. Technology changes. And some changes are much more 'expensive' than others. Some changes benefit a few while others benefit many.
Alex has done an excellent job of letting us know the GENERAL direction of HM and allowing HM to be customer-driven.
But in the end, your needs may simply exceed what HM was designed to do. If so, that's OK too. But by making your decision based upon "the facts on the ground today" (is this just an American idiom?), you'll likely not be frustrated later.
Last edited by timn on Fri Mar 18, 2005 8:43 am, edited 1 time in total.
