[inputs.vsphere] Introduce use_int_samples to obtain backwards compatibility #5563
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Required for all PRs:
TL;DR version:
In version 1.10, we changed the data type of all samples to floating point. This caused problems when sending data to existing InfluxDB databases. The
use_int_samples
forces the plugin to send int samples for everything except percentages.Long version:
Under certain conditions, such as high load, vCenter can significantly delay sample delivery. When this happens, the plugin will see empty samples for the current time period. To solve this, we have to look back a certain number of sample periods to catch delayed data. Unfortunately, that data can come in at different time series granularity, so we apply a normalization process implemented in Endpoint.alignMetrics. This process consists of dividing the raw time series into buckets according to the desired sample period. If two or more samples end up in the same bucket, averaging occurs.
All vCenter metrics are integers, but when averaging occurs as described above, we need to use floating point math. Since the result of the normalization is a floating point vector, we changed the sample type to always be a float. Obviously, this was a mistake, since it breaks backwards compatibility.
The
use_int_sample
simply rounds output to the nearest integer and sends it as an integer type. Since the raw data was an integer, one could argue that this is just discarding false precision created in the averaging process. Either way, the rounding error should be negligible.