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

Implement xpack.monitoring.elasticsearch.collection.enabled setting #33474

Merged

Conversation

ycombinator
Copy link
Contributor

@ycombinator ycombinator commented Sep 6, 2018

Resolves #33290.

This PR implements an optional setting named xpack.monitoring.elasticsearch.collection.enabled, defaulting to true.

This setting will determine whether X-Pack Monitoring (when active overall) should collect Elasticsearch metrics or not.

@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra

@ycombinator ycombinator requested review from tlrx and pickypg September 11, 2018 21:13
@ycombinator ycombinator added review and removed WIP labels Sep 11, 2018
@ycombinator ycombinator force-pushed the x-pack/monitoring/add-es-collection-flag branch from 0123599 to cd751df Compare September 13, 2018 14:50
Copy link
Member

@pickypg pickypg left a comment

Choose a reason for hiding this comment

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

Some ideas on simplifying this.

@ycombinator ycombinator force-pushed the x-pack/monitoring/add-es-collection-flag branch from df4964a to 66c7b2e Compare September 14, 2018 22:26
@ycombinator ycombinator force-pushed the x-pack/monitoring/add-es-collection-flag branch from 66c7b2e to 79a79c7 Compare September 14, 2018 22:29
return this.elasticsearchCollectionEnabled;
}

public boolean shouldScheduleExecution() {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Should this and some of the other related methods in here be private or at least protected?

Copy link
Member

Choose a reason for hiding this comment

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

I'd be okay with either way. I even though about package protected after I initially wrote it (so it can be tested but not reused). But you're right it doesn't need to be public.

@ycombinator
Copy link
Contributor Author

@pickypg Thanks for your feedback. I've simplified the implementation per your recommendation. This is ready for review again.

Copy link
Member

@pickypg pickypg left a comment

Choose a reason for hiding this comment

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

Code LGTM. Just some minor doc comments.

[source,yaml]
---------------------------------------------------
xpack.monitoring.collection.enabled: true
xpack.monitoring.elasticsearch.collection.enabled: true
Copy link
Member

Choose a reason for hiding this comment

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

This should be false.

.. Verify that the `xpack.monitoring.enabled`,
`xpack.monitoring.collection.enabled`, and
`xpack.monitoring.elasticsearch.collection.enabled` settings are `true` on each
node in the cluster. By default, data collection is disabled. For more
Copy link
Member

Choose a reason for hiding this comment

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

This second sentence is very confusing with this new setting in the mix.

By default xpack.monitoring.collection.enabled is disabled (false), and that overrides xpack.monitoring.elasticsearch.collection.enabled, which defaults to being enabled (true). Both settings can be set dynamically at runtime.

(Or similar)

This is different from xpack.monitoring.collection.enabled, which allows you to enable or disable
all monitoring collection. However, this setting simply disables the collection of Elasticsearch
data while still allowing other data (e.g., Kibana, Logstash, Beats, or APM Server monitoring data)
to use through this cluster.
Copy link
Member

Choose a reason for hiding this comment

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

This is my own bad phrasing:

to use through this cluster.

should probably be

to pass through this cluster.

@@ -122,15 +122,15 @@ public TimeValue getInterval() {
return interval;
}

public boolean isMonitoringActive() {
boolean isMonitoringActive() {
Copy link
Member

Choose a reason for hiding this comment

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

This one is used in the Rest endpoint to silently block incoming traffic.

Copy link
Member

@pickypg pickypg left a comment

Choose a reason for hiding this comment

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

LGTM!

@ycombinator ycombinator merged commit 2aba52d into elastic:master Sep 18, 2018
@ycombinator ycombinator deleted the x-pack/monitoring/add-es-collection-flag branch September 18, 2018 01:33
ycombinator added a commit to ycombinator/elasticsearch that referenced this pull request Sep 18, 2018
…lastic#33474)

* Implement xpack.monitoring.elasticsearch.collection.enabled setting

* Fixing line lengths

* Updating constructor calls in test

* Removing unused import

* Fixing line lengths in test classes

* Make monitoringService.isElasticsearchCollectionEnabled() return true for tests

* Remove wrong expectation

* Adding unit tests for new flag to be false

* Fixing line wrapping/indentation for better readability

* Adding docs

* Fixing logic in ClusterStatsCollector::shouldCollect

* Rebasing with master and resolving conflicts

* Simplifying implementation by gating scheduling

* Doc fixes / improvements

* Making methods package private

* Fixing wording

* Fixing method access
ycombinator added a commit that referenced this pull request Sep 18, 2018
…33474) (#33791)

* Implement xpack.monitoring.elasticsearch.collection.enabled setting

* Fixing line lengths

* Updating constructor calls in test

* Removing unused import

* Fixing line lengths in test classes

* Make monitoringService.isElasticsearchCollectionEnabled() return true for tests

* Remove wrong expectation

* Adding unit tests for new flag to be false

* Fixing line wrapping/indentation for better readability

* Adding docs

* Fixing logic in ClusterStatsCollector::shouldCollect

* Rebasing with master and resolving conflicts

* Simplifying implementation by gating scheduling

* Doc fixes / improvements

* Making methods package private

* Fixing wording

* Fixing method access
@jimczi jimczi added v7.0.0-beta1 and removed v7.0.0 labels Feb 7, 2019
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.

5 participants