Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[inputs.vsphere] Introduce use_int_samples to obtain backwards compatibility #5563

Merged
merged 4 commits into from
Mar 11, 2019
Merged

[inputs.vsphere] Introduce use_int_samples to obtain backwards compatibility #5563

merged 4 commits into from
Mar 11, 2019

Conversation

prydin
Copy link
Contributor

@prydin prydin commented Mar 9, 2019

Required for all PRs:

  • Signed CLA.
  • Associated README.md updated.
  • Has appropriate unit tests.

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.

@prydin prydin mentioned this pull request Mar 9, 2019
@danielnelson danielnelson added this to the 1.10.1 milestone Mar 11, 2019
@danielnelson danielnelson merged commit 19988a9 into influxdata:master Mar 11, 2019
danielnelson pushed a commit that referenced this pull request Mar 11, 2019
otherpirate pushed a commit to otherpirate/telegraf that referenced this pull request Mar 15, 2019
otherpirate pushed a commit to otherpirate/telegraf that referenced this pull request Mar 15, 2019
dupondje pushed a commit to dupondje/telegraf that referenced this pull request Apr 22, 2019
hwaastad pushed a commit to hwaastad/telegraf that referenced this pull request Jun 13, 2019
bitcharmer pushed a commit to bitcharmer/telegraf that referenced this pull request Oct 18, 2019
athoune pushed a commit to bearstech/telegraf that referenced this pull request Apr 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants