How to edit RootCause variable for email alerts?

Hello Community!

What is the best possible way to remove the type of objects that show up under the`${N=SwisEntity;M=NodeStatusRootCause}` variable? The reason being in our environment we have a variety of interfaces we are monitoring, some warrant further investigation when they flap, some not so much and others are in admin down.  Currently, alerts that have the ${N=SwisEntity;M=NodeStatusRootCause} variable will include interfaces that are Unplugged or in admin down state as the root cause for the node changing status.  This causes alerts to be noisier when an interface that we care about goes down but the node has several unplugged and admin down interfaces.  We would still like to monitor interfaces in these unplugged/admin down state for reporting reasons but not be alerted on them. 

Has anyone came across a similar problem?

Thank you!

Parents
  • I'm not 100% clear on what you're asking, but if it is what I think, then we use a custom property.

    So essentially the custom property is called something like "In_Service" and values are Yes/No. You then build your alerts to only alert if the In_Service = YES and whatever other logic you need.

    You would then need to set the RootCause items that you don't want to alert to a NO value.

    Reporting logic can be left untouched and it would then ignore this custom property.

  • I think the issue is what interfaces you are monitoring.

    When we onboard a node, we let SolarWinds select the active ports.  On the screen where it says add interfaces, we do not add any!  So only up and running interfaces are added and monitored.

    THEN once per week we run a network sonar discovery job on each poller, scanning the nodes on that poller for new interfaces.  We then pull those new interfaces in.  You can do that daily, weekly, monthly...  Whatever makes sense in your environment.

    THEN none of those interfaces in the shutdown state are visible, and all of your reports and screens show just what is active and current.  Any interfaces that are shut-down after having been in an active state will need attention as well, but presumably you will handle those by either scheduling the interface removal as part of the node decommissioning OR when the alert is worked.  Offboarding is not a frequent activity in my environment, so we handle them as they occur.

Reply
  • I think the issue is what interfaces you are monitoring.

    When we onboard a node, we let SolarWinds select the active ports.  On the screen where it says add interfaces, we do not add any!  So only up and running interfaces are added and monitored.

    THEN once per week we run a network sonar discovery job on each poller, scanning the nodes on that poller for new interfaces.  We then pull those new interfaces in.  You can do that daily, weekly, monthly...  Whatever makes sense in your environment.

    THEN none of those interfaces in the shutdown state are visible, and all of your reports and screens show just what is active and current.  Any interfaces that are shut-down after having been in an active state will need attention as well, but presumably you will handle those by either scheduling the interface removal as part of the node decommissioning OR when the alert is worked.  Offboarding is not a frequent activity in my environment, so we handle them as they occur.

Children
No Data