cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post
Level 12

Volumes disappearing due to SNMP name change

I have been experiencing this issue much more frequently now that my company is preparing for a data center migration.  The issue is two fold as I see it.

1. Loss of monitoring.  This is critical because Orion does not detect the loss of connection.  When the volume data changes, Orion loses sight of it and effectively ignores it.  This can and does cause alert status definitions to fail to trigger.  Yes, I can run a SQL query to MANUALLY go in and add the newly named volumes but that leads to the second issue...

2. Loss of data history.  Once the volume name changes and I add the new name via "List Resources", I am left with a non-responsive volume that just sits there (taking up an Orion license I might add).  Another simple matter of just deleting that volume via the Database Manager.  Problem is that I then lose ALL historical data from that volume.  The new name is exactly that, brand new.  No more trend analysis is possible.  I would not like to even think of the messy data merges that would require.

What i do not understand is why Orion locks in on the SNMP returned VALUE rather than allowing it to be dynamic.  The OID is static (.1.3.6.1.2.1.25.2.3.1.3.0) and each volume is just the GETNEXT starting at 3.1.3.1.  The DATA is dynamic based on the returned value of the SNMP query, why can the NAME not be handled the same

3 Replies
Level 7

And 2.5 years later we are still having this issue. I keep hoping each thread I find has a solution instead of just a question about how to solve the problem. But no such luck.

0 Kudos
Level 12

This matter has now gone up in criticality for my implementation.  With the release of SAM 5.5 and the ability to set custom properties for application monitors, I am in the process of changing all of my Node, Volume and App advanced alerts to use custom properties pre-populated with the destination email addresses (as outlined in this Thwack post).  This way I can more dynamically control what teams get notified on a node-by-node basis.

However, since this issue still occurs I will have to add a new step to my cleanup, that being copying the email addresses from the now dead volume and adding them to the new volume record.  Coupled with the complete loss of historical data and high risk of missing a threshold warnings entirely, can someone please comment on whether it is even on the radar for a future release?

0 Kudos
Level 12

Since you posted, I've had this thread in my favourites to see if anyone from SolarWinds replied.

I'm not sure why SolarWinds has never resolved what all their customers must consider to be either a bug, or at the very least an often-frustrating missing ability. When I've raised this previously in tickets, they have never given any reason why this hasn't been considered further, aside from this being by design given that the volume label changes.

Overall, a very poor show. Disappointing. However, perhaps there is an understandable (to them) technical reason within SW for why this hasn't progressed.

0 Kudos