we need to have a detailed historical report of downtime of specific group of nodes , the report should indicating when and how long that interfaces was down , could you please give this feature some attention ?
This isn't really something I'd be looking for as a feature request.
You'll probably get a much better response asking for some help writing a report that will get this information for you in the "Reports Lab" within the "Labs" Space
I've actually experienced a lot of ideas on the subject, what I got was a report on when it was down only ,but what I also need is how long time an interface or node was down so that we can evaluate the performance of service providers and do some analysis on the network and connecting lines.
It's actually relatively easy to determine, with the caveat that the information only as good as $POLLING_CYCLE allows it to be. Node or interface up/down detection is much more reliable with traps, but last time I tried, trap based interface status changing was a pipe dream at the scale I'm at, and haven't had the brass to try it since.
Other than the basic charting, you would be looking at reporting off the Events which you should also show on the node or interface in question as a resource, like last 25,50,100 events. While you could certainly play with it, the historical availability charts in the report writer may likely be the best for you.
For really hard statistics, mostly I log into the offending device and check up/down. Or look at the syslog or traps from it for hard timestamps. Availability stats in SW are unreliable when you're measuring 99.999. For that matter, polling issues or issues with the network in between can create phantoms, so you want to base most of your stuff off of a polling cycle of like 3 minutes anyway. (Things have gotten better in the last couple of years.)
Via the web console, navigate to the node or interface in question. Click on the availability chart's Chart data button. There, you can actually assess it directly.
When it comes to reporting on it after that data is gone, forget about it. But your retention on granular data should be at least 7 days, that will always only be as good as your $RETENSION allows.
Worst case, you could always fire up DB manager and start playing with queries, but I think most of what you want is already there.
I get that information several ways:
If you get the desired Feature Request in a new release, I salute you!
If you end up building a beautiful report that fills your needs (and that data IS available in the Orion SQL database, readily mined with SWQL and viewed via the SDK), I think we'd all like to see your results and learn how you built that report.
