Cherry-pick #20281 to 7.x: Add leader election for autodiscover#20510
Merged
ChrsMark merged 1 commit intoelastic:7.xfrom Aug 11, 2020
Merged
Cherry-pick #20281 to 7.x: Add leader election for autodiscover#20510ChrsMark merged 1 commit intoelastic:7.xfrom
ChrsMark merged 1 commit intoelastic:7.xfrom
Conversation
(cherry picked from commit 9ab9b97)
Contributor
|
Pinging @elastic/integrations-platforms (Team:Platforms) |
Contributor
❕ Build Aborted
Expand to view the summary
Build stats
Test stats 🧪
Log outputExpand to view the last 100 lines of log output
|
kaiyan-sheng
approved these changes
Aug 10, 2020
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Cherry-pick of PR #20281 to 7.x branch. Original message:
What does this PR do?
Implements leader election as part of kubernetes autodiscover provider. With this, when the beat is elected as leader it will start cluster scope metricsets.
Under the hood, all leader candidates will try to gain the lock on Lease object (https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#lease-v1-coordination-k8s-io). When the lock is gained then the configured cluster wide mericsets will get started.
Why is it important?
To get rid of
Deploymentprocedure for the singleton Metricbeat instance which is needed for the cluster scope metricsets.Sample configuration that will start
state_nodemetricset when a leadership is gained:Then we can monitor the
leaseto check which provider holds the lock:Checklist
CHANGELOG.next.asciidocorCHANGELOG-developer.next.asciidoc.How to test this PR locally
Make sure that events for
state_nodeare being collected from only one metricbeat instance. You can the in the logs and verify that only one metricbeat has gained the lock so far.Monitor the
leaseobject to keep track of the lock holder:watch kubectl describe lease beats-cluster-leaderStop the Metricbeat instance that currently holds the lock and make sure that another one takes over and we keep getting events from
state-node. Make sure that theleasechanged holder (logs will also let us know that a new metricset is getting started)Also test without setting
identifierand check that it takes the default value properly likemetricbeat-cluster-leader.Check with old autodiscover (template based/hints based) for possible regressions.
Related issues