Julio_Martinez
Former Employee
Joined 8 years ago
User Profile
User Widgets
Contributions
Re: datasource migration function
Hi, Monitoring Engineering team lead here. I wrote these and would like to provide some insight into why the VMware Gen3 datasources are the way they are. We introduced a slew of history breaking changes which run a lot deeper than aesthetics for many reasons. Including better alerting (e.g. ESX datasources only alert when a server is in standalone mode), new data points (status data points for everything, from VM's to Datastores, we added support for relaying vCenter alerts) and a easing the collector's load on the VMware API. And yes, aesthetics played a part, I think these look nicer, but I'm biased. In the end I made the call to split and rename the datasources for the following reasons. vCenter and ESXi are different products, they expose similar API's but they react to it in different ways. We want the flexibility to extract different information from both these products independently. Improved monitoring now > keeping history. It's always a balance but in this case new features justified it. We renamed it in such a way customers could choose to keep the old ones without us removing some data points. When doing destructive operations it's always better to give you the power to decide if/when to do it. These datasources pave the way for other features like topologies and such. Some datasources change AD behavior completely (HW sensors) causing complete loss of history. That being said, we do need better module migration tools to make these changes less painful. We are keenly aware of it and it’s actively being worked on. Regards,3Views0likes0Comments