-
Notifications
You must be signed in to change notification settings - Fork 25.2k
Add setting to decommission legacy monitoring cluster alerts #62668
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
Changes from all commits
62aa8ec
f3c04de
f5c399d
f4beb02
b9b2b37
2faf8e2
3185715
3735e1a
3a281f7
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -23,6 +23,7 @@ | |
import org.elasticsearch.gateway.GatewayService; | ||
import org.elasticsearch.license.XPackLicenseState; | ||
import org.elasticsearch.xpack.core.ssl.SSLService; | ||
import org.elasticsearch.xpack.monitoring.Monitoring; | ||
import org.elasticsearch.xpack.monitoring.exporter.http.HttpExporter; | ||
import org.elasticsearch.xpack.core.monitoring.exporter.MonitoringDoc; | ||
import org.elasticsearch.xpack.monitoring.exporter.local.LocalExporter; | ||
|
@@ -62,7 +63,9 @@ public Exporters(Settings settings, Map<String, Exporter.Factory> factories, | |
|
||
final List<Setting.AffixSetting<?>> dynamicSettings = | ||
getSettings().stream().filter(Setting::isDynamic).collect(Collectors.toList()); | ||
clusterService.getClusterSettings().addSettingsUpdateConsumer(this::setExportersSetting, dynamicSettings); | ||
final List<Setting<?>> updateSettings = new ArrayList<Setting<?>>(dynamicSettings); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. should #getSettings() also return this new setting ? (I think it is only really used for testing, but seems more correct to return all the settings up through the plugin). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It seems I missed that step, good catch! |
||
updateSettings.add(Monitoring.MIGRATION_DECOMMISSION_ALERTS); | ||
clusterService.getClusterSettings().addSettingsUpdateConsumer(this::setExportersSetting, updateSettings); | ||
HttpExporter.registerSettingValidators(clusterService, sslService); | ||
// this ensures that logging is happening by adding an empty consumer per affix setting | ||
for (Setting.AffixSetting<?> affixSetting : dynamicSettings) { | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It feels kinda weird to have this AND
xpack.monitoring.exporters.*.cluster_alerts.management.enabled
setting.I wonder if makes sense to
xpack.monitoring.exporters.<i>.cluster_alerts.management.enabled=false
and set some cluster state to no longer try to install cluster alerts (and reach out to delete the cluster alerts for those exporters)xpack.monitoring.exporters.<new_exporter>.cluster_alerts.management.enabled=false
based on the cluster state.thoughts ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be in favour of less settings but OTOH current flow with this setting seems simpler and less error-prone. And currently you can't enable single exporter back (with
xpack.monitoring.exporters.<i>.cluster_alerts.management.enabled=true
) which I think is good thing (easier to reason about cluster state).We can still expose
_monitoring/cluster_alert/disable
endpoint if needed though if we want, it may be easier for the user to just call API than looking up setting to useThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I consider this more of a first step with a new action that performs the migration to follow. If the exporters are disabled, this setting only ensures that the alerts are not created if they are turned back on (since alerts are created lazily much to my chagrin).
The main concern that was raised in the migration issue was that if a new exporter is configured, either on purpose or by accident, the cluster alerts for that exporter will not be installed. A global setting to control the existence of the alerts is the easiest way to fix that, even if it overlaps with other settings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that makes sense, thanks for explaining.