vSphere input: Human readable instance info for datastores on hosts and VMs

[prydin]

Feature Request

Add a human readable instance name to datastores referenced from hosts and VMs.

Proposal:

Some of host.datastore.* and vm.datastore.* metrics have instance keys referring to individual datastores. For example, you can get your IOPS broken down per datastore.

Currently, the instance key is the internal LUN identifier, which is typically just a long hex string. You can use it to manually look up the datastore using e.g. govc and PowerCLI.

We are proposing a change that emits the datastore name, along with the unique LUN identifier.

Current behavior:

Only a hex LUN identifier is emitted as a tag.

Desired behavior:

Emit the datastore name in addition to the LUN identifier as a tag.

Use case:

Datastore instance metrics is of limited use if they don't contain a human readable identifier.

[prydin]

@glinton and @danielnelson, I'd like your input on this:

After a few weeks of this plugin living in the wild, we realized that datastore name is a much better identifier than LUN here. To recap, the datapoints we're referring to here are mount points on a virtual machine. Each of them is identified by a target LUN today. We need to add name of the datastore corresponding the LUN.

Here's the issue: I'm torn between adding a new tag and simply replacing it. I know that the latter isn't compliant with your policy of backwards compatibility, so we'd have to create a config flag where you can select whether you want the old behavior (LUN) or the new one (datastore name). On the other hand, we'd like to keep the number of settings to a minimum.

The question is: What is better? Adding another tag or adding a somewhat obscure setting? The new tag should have a 1:1 mapping to the old LUN tag, so it doesn't increase data cardinality.

[danielnelson]

I would just add a new tag with the name for now.

The plugin is still young and there may be other changes you will want to make, it will be easier to build up a list of desired changes and then in ~6 months you could look into doing a larger change.

[prydin]

Solved in PR #4934