[Metricbeat] gcp: fix instance machineType reporting #27363
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
endorama
added
bug
Team:Integrations
|
Pinging @elastic/integrations (Team:Integrations) |
botelastic
bot
added
needs_team
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
Trends 🧪💚 Flaky test reportTests succeeded. Expand to view the summary
Test stats 🧪
|
|
This pull request is now in conflicts. Could you fix it? 🙏 |
Refresh instance metadata for each incoming response by updating the `s.computeMetadata` field in the `metadataCollector` struct. The code was applying a sort of caching to the computeMetadata, but in the wrong place. Most probably it was a leftover, as a proper caching for instance metadata is implemented in the `instance` function on line 146. Due to this check `computeMetadata` were not refreshed for each response. `metadataCollector` is instanciated only once for the entire module. Thus by not overriding `computeMetadata` the metadata of the first response handled was used for all subsequent events. Removing the check make the code update the `s.computeMetadata` property for each new response. With this update the correct metadata based on the instance ID reported in the response are used. Fixes a bug were all metrics were being reported with the same `machineType`. NOTE: the code update the same struct field at each iteration; this is most probably not safe in a parallel execution context; this code is not running multiple times in different threads so for the moment this change should not have negative side effects.
endorama
force-pushed
the
endorama/gcp-machineType-issue
branch
from
5cb8a59
to
5df3115
Compare
sayden
approved these changes
Aug 17, 2021
CHANGELOG.next.asciidoc
Outdated
| @@ -407,6 +407,7 @@ https://github.com/elastic/beats/compare/v7.0.0-alpha2...master[Check the HEAD d | |||
| - Fix cloudwatch metricset collecting duplicate data points. {pull}27248[27248] | |||
| - Fix flaky test TestAddCounterInvalidArgWhenQueryClosed. {issue}27312[27312] {pull}27313[27313] | |||
| - Add percent formatters to system/process {pull}27374[27374] | |||
| - Fix instance machineType reporting {pull}27363[27363] | |||
There was a problem hiding this comment.
Add here "In compute metricset of GCP module" (for example)
|
Merging without waiting for CI as I've only updated the Changelog description and CI was green at previous commit. |
mergify bot
pushed a commit
that referenced
this pull request
Aug 17, 2021
Refresh instance metadata for each incoming response by updating the `s.computeMetadata` field in the `metadataCollector` struct. The code was applying a sort of caching to the computeMetadata, but in the wrong place. Most probably it was a leftover, as a proper caching for instance metadata is implemented in the `instance` function on line 146. Due to this check `computeMetadata` were not refreshed for each response. `metadataCollector` is instanciated only once for the entire module. Thus by not overriding `computeMetadata` the metadata of the first response handled was used for all subsequent events. Removing the check make the code update the `s.computeMetadata` property for each new response. With this update the correct metadata based on the instance ID reported in the response are used. Fixes a bug were all metrics were being reported with the same `machineType`. NOTE: the code update the same struct field at each iteration; this is most probably not safe in a parallel execution context; this code is not running multiple times in different threads so for the moment this change should not have negative side effects. (cherry picked from commit 5339327)
💔 Build Failed
Expand to view the summary
Build stats
Trends 🧪Steps errors
Expand to view the steps failures
|
mergify bot
pushed a commit
that referenced
this pull request
Aug 17, 2021
Refresh instance metadata for each incoming response by updating the `s.computeMetadata` field in the `metadataCollector` struct. The code was applying a sort of caching to the computeMetadata, but in the wrong place. Most probably it was a leftover, as a proper caching for instance metadata is implemented in the `instance` function on line 146. Due to this check `computeMetadata` were not refreshed for each response. `metadataCollector` is instanciated only once for the entire module. Thus by not overriding `computeMetadata` the metadata of the first response handled was used for all subsequent events. Removing the check make the code update the `s.computeMetadata` property for each new response. With this update the correct metadata based on the instance ID reported in the response are used. Fixes a bug were all metrics were being reported with the same `machineType`. NOTE: the code update the same struct field at each iteration; this is most probably not safe in a parallel execution context; this code is not running multiple times in different threads so for the moment this change should not have negative side effects. (cherry picked from commit 5339327)
endorama
added a commit
that referenced
this pull request
Aug 17, 2021
…orting (#27419) Refresh instance metadata for each incoming response by updating the `s.computeMetadata` field in the `metadataCollector` struct. The code was applying a sort of caching to the computeMetadata, but in the wrong place. Most probably it was a leftover, as a proper caching for instance metadata is implemented in the `instance` function on line 146. Due to this check `computeMetadata` were not refreshed for each response. `metadataCollector` is instanciated only once for the entire module. Thus by not overriding `computeMetadata` the metadata of the first response handled was used for all subsequent events. Removing the check make the code update the `s.computeMetadata` property for each new response. With this update the correct metadata based on the instance ID reported in the response are used. Fixes a bug were all metrics were being reported with the same `machineType`. NOTE: the code update the same struct field at each iteration; this is most probably not safe in a parallel execution context; this code is not running multiple times in different threads so for the moment this change should not have negative side effects. (cherry picked from commit 5339327) Co-authored-by: endorama <526307+endorama@users.noreply.github.com>
endorama
added a commit
that referenced
this pull request
Aug 17, 2021
…porting (#27420) Refresh instance metadata for each incoming response by updating the `s.computeMetadata` field in the `metadataCollector` struct. The code was applying a sort of caching to the computeMetadata, but in the wrong place. Most probably it was a leftover, as a proper caching for instance metadata is implemented in the `instance` function on line 146. Due to this check `computeMetadata` were not refreshed for each response. `metadataCollector` is instanciated only once for the entire module. Thus by not overriding `computeMetadata` the metadata of the first response handled was used for all subsequent events. Removing the check make the code update the `s.computeMetadata` property for each new response. With this update the correct metadata based on the instance ID reported in the response are used. Fixes a bug were all metrics were being reported with the same `machineType`. NOTE: the code update the same struct field at each iteration; this is most probably not safe in a parallel execution context; this code is not running multiple times in different threads so for the moment this change should not have negative side effects. (cherry picked from commit 5339327) Co-authored-by: endorama <526307+endorama@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What does this PR do?
Refresh instance metadata for each incoming response by updating the
s.computeMetadatafield in themetadataCollectorstruct.Why is it important?
The code was applying a sort of caching to the
computeMetadata, but in the wrong place. Most probably it was a leftover, as a proper caching for instance metadata is implemented in theinstancefunction on line 146.Due to this check
computeMetadatawere not refreshed for each response.metadataCollectoris instanciated only once for the entire module.Thus by not overriding
computeMetadatathe metadata of the first response handled was used for all subsequent events.Removing the check make the code update the
s.computeMetadataproperty for each new response. With this update the correct metadata based on the instance ID reported in the response are used.Fixes a bug were all metrics were being reported with the same
machineType.NOTE: the code update the same struct field at each iteration; this is most probably not safe in a parallel execution context; this code is not running multiple times in different threads so for the moment this change should not have negative side effects.
Checklist
I have made corresponding changes to the documentationI have made corresponding change to the default configuration filesI would like to add an integration test (as I have been able to reproduce it in a pristine environment)
CHANGELOG.next.asciidocorCHANGELOG-developer.next.asciidoc.Author's Checklist
How to test this PR locally
Related issues
Use cases
Screenshots
Logs