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 (.184.108.40.206.220.127.116.11.18.104.22.168) and each volume is just the GETNEXT starting at 22.214.171.124. The DATA is dynamic based on the returned value of the SNMP query, why can the NAME not be handled the same
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?
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.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.