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

[Monitoring] Make Exporters Async #35765

Merged
merged 8 commits into from Nov 27, 2018

Conversation

pickypg
Copy link
Member

@pickypg pickypg commented Nov 21, 2018

This changes the exporter code -- most notably the http exporter -- to use async operations throughout the resource management and bulk initialization code (the bulk indexing of monitoring documents was already async).

As part of this change, this does change one semi-core aspect of the HttpResource class in that it will no longer block all concurrent calls until the first call completes with HttpResource::checkAndPublishIfDirty. Now, any parallel attempts to check the resources will be skipped until the first call completes (success or failure). While this is a technical change, it has very little practical impact because the existing behavior was either quick success (then every blocked request processed) or each request timed out and failed anyway, thus being effectively skipped (and a burden on the system).

Closes #35743

@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-features

@pickypg
Copy link
Member Author

pickypg commented Nov 21, 2018

Note: I haven't updated any of the tests yet. I wanted to validate my approach as the amount of code changed was larger than I had initially expected. I'm fairly sure that the direction is the intended one, but before I go down the path of changing all of the tests, I've got it working here async this way.

@pickypg
Copy link
Member Author

pickypg commented Nov 21, 2018

/cc @elastic/kibana-monitoring

Copy link
Member

@martijnvg martijnvg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for working on this @pickypg! This PR is in the right direction. I left some small comments and a bigger comment about the fact that resolveBulk(...) method in LocalExporter also needs to be made async.

@pickypg
Copy link
Member Author

pickypg commented Nov 26, 2018

@martijnvg This one is ready for a full review now that the tests have been updated.

Copy link
Member

@martijnvg martijnvg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left one small comment - LGTM.

This changes the exporter code -- most notably the `http` exporter --
to use async operations throughout the resource management and bulk
initialization code (the bulk indexing of monitoring documents was
already async).

As part of this change, this does change one semi-core aspect of the
`HttpResource` class in that it will no longer block all concurrent
calls until the first call completes with
`HttpResource#checkAndPublishIfDirty`. Now, the any incoming attempts
to check the resources will be skipped until the first call completes
(success or failure). While this is a technical change, it has very
little practical impact because the existing behavior was either
success, then every processed quickly or each request timed out and
failed anyway, thus being effectively skipped.
@pickypg
Copy link
Member Author

pickypg commented Nov 27, 2018

Rebased for cluster upgrade test failure.

@pickypg pickypg merged commit 3337fa7 into elastic:master Nov 27, 2018
@pickypg pickypg deleted the fix/use-async-exporters branch November 27, 2018 19:28
pickypg added a commit that referenced this pull request Nov 27, 2018
This changes the exporter code -- most notably the `http` exporter --
to use async operations throughout the resource management and bulk
initialization code (the bulk indexing of monitoring documents was
already async).

As part of this change, this does change one semi-core aspect of the
`HttpResource` class in that it will no longer block all concurrent calls
until the first call completes with
`HttpResource::checkAndPublishIfDirty`.
Now, any parallel attempts to check the resources will be skipped until
the first call completes (success or failure). While this is a technical
change, it has very little practical impact because the existing behavior
was either quick success (then every blocked request processed) or
each request timed out and failed anyway, thus being effectively
skipped (and a burden on the system).
@pickypg
Copy link
Member Author

pickypg commented Nov 27, 2018

6.x/6.6: 9ffc492

jasontedor added a commit to jasontedor/elasticsearch that referenced this pull request Nov 28, 2018
* master:
  DOCS Audit event attributes in new format (elastic#35510)
  Scripting: Actually add joda time back to whitelist (elastic#35965)
  [DOCS] fix HLRC ILM doc misreferenced tag
  Add realm information for Authenticate API (elastic#35648)
  [ILM] add HLRC docs to remove-policy-from-index (elastic#35759)
  [Rollup] Update serialization version after backport
  [Rollup] Add more diagnostic stats to job (elastic#35471)
  Build: Fix gradle build for Mac OS (elastic#35968)
  Adds deprecation logging to ScriptDocValues#getValues. (elastic#34279)
  [Monitoring] Make Exporters Async (elastic#35765)
  [ILM] reduce time restriction on IndexLifecycleExplainResponse (elastic#35954)
  Remove use of AbstractComponent in xpack (elastic#35394)
  Deprecate types in search and multi search templates. (elastic#35669)
  Remove fromXContent from IndexUpgradeInfoResponse (elastic#35934)
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.

None yet

4 participants