I am somewhat concerned about the longterm reliability of Orion at this point. I installed last week and have been working for the last week to configure it. In that time I have opened 6 trouble tickets and noticed that over 1000 tickets have been opened since last Wednesday. Has everyone had a fairly stable experience, or have you experienced issues with performance and reliability?- Availability reports don’t report correct values. We had some network nodes go down last week and the availability percentages on the node details page are correct, but the availability report lists 100%. Great way to demonstrate to management that Orion helps ensure 100% uptime!
- A couple of processes on the server were dying and being restarted. Apparently this is a known issue with APM that was supposedly resolved in APM2.0 SP2 (which we are running).
- When configuring a trap alert enclosing a match string in single quotes disallows future editing of that value. Somewhere along the line those quotes aren’t getting parsed in our out correctly and it is messing with the interface. Not a huge deal since I don’t see anywhere that actually requires you to include single quotes. Not sure what it would do with a single apostrophe though.
- Trap alerts at least do not appear to correctly match a “not equal to” IP address. They do succuessfully and correctly match an item “equal to” an IP address however. So there is a workaround, just cumbersome. I don’t know if this is present in the standard alerts or syslog alerts, but have verified it with snmp trap alerts.
- For some network nodes with asynchronous TX/RX interface speeds the utilization percentage graphs don’t correctly show the actual percentage for the lower speed interface. Both percentages are based on the larger value which obviously results in erroneous graphs.
-Discarding a trap as an alert condition doesn’t appear to immediately discard the trap. Alerts that follow a discard action still appear to process the trap (forwarding remaining traps forward all traps with those that I wanted discarded tagged with “marked for discard”). They do not show up in the trap viewer or web interface however. I’m not sure if this same thing would apply to syslog messages.
Also, not a bug per se, but the fact that changes to snmp trap alerts don't take effect immediately was... a painful realization. Apparently I am told that there used to be a note somewhere to inform users of that fact but I have yet to see it (I may be blind), but no matter what this is definately counter intuitive and really leads for a lot of wasted time (especially when coupled with the IP address bug above).