Leverage data from topology mapper to support root cause alert processing

Let's face it; manually creating dependencies to support "root cause" type alerting is a painful and time-consuming task.

The data required to "automagically" create dependencies between network objects exists in topo discovery, so why not take the next step and use it to support more intelligent alerting?

Competitive products like HP Network Node Mangler (a.k.a: NNMi) have been doing root cause alert processing out of the box for years, using data from their spiral node discovery to associate a core device with its dependent nodes and interfaces.

If Orion can now collect and store the same relationships with topology mapper, then I say let's use it.

Find more posts tagged with

dependencies_parent_node

dependency

dependancy

npm

discovery

dependency_alerts_grouping_groups_suppression_suppress

root

root_cause

Status: None

Comments

Jfrazier

Not only is the manual process painful and time consuming, in a rather dynamic and/or large environment it can be a full time job just to maintain.

If I recall, NNM uses the ARP tables to figure out what is in the network and where it exists in relation to other nodes...that should be a simple thing here.

It's simple and not ping sweeps that can get some peoples nerves in a frazzle.

vinay.by

I would support your idea but then there could be a lot of dependencies which are already in place with respect to SW. From what I understand at this point of time SW are adding in new features on the base they have already formed, like what other vendors did in the past , how HP evolved - as in NNM 7.3X was the last of its kind and then 8.01 appeared with a new architecture (re-designing of entire product)

If Orion can now collect and store the same relationships with topology mapper ? This is a great question if it can and is it feasible is what SW should be looking at?

rob.hock

Assuming we had the ability to automagically determine dependencies, how would you imagine interacting with them? Or correcting the calculations if we were wrong? How else would you want to use them besides alert suppression?

vinay.by

For me it would be Service Level Maps that would show all areas affected and how much impact it caused to the customer network, my point would be why do we have to create complex auto correlation rules dependencies etc etc to find the out the root cause. We have the data - convert them into a SLM and when an alert is fired navigate to SLM and check for the impact and root cause. I am very happy with what Solarwinds have provided so far wrt to dependencies and alerting I wouldnt want them to change it much unless and until it add some value to it. SLM would be an additional feature that they can think about.

Jfrazier

A fair portion of NNM 8.x was still a good portion of the 7.3x core but with a java front end purchased or licensed from Blue Elephant software in Germany.

They dropped the data warehouse which caused them lots of grief...a good portion by me. Yes it modernized the UI but made it clunky. It made some thing easier and others more of a pain.

But it did it's topology maps quite well...including dependencies on upstream devices...

mcam

Along those lines, it isn't just NTM that provides useful indication of connections. NTM give us the physical connections. The information from the QoE dashboard however gives us the logical connections between servers Especially as our servers are usually on specific networks.