Support setting the Gossip cluster "label"#3254
Closed
greed42 wants to merge 1 commit intoprometheus:mainfrom
Closed
Support setting the Gossip cluster "label"#3254greed42 wants to merge 1 commit intoprometheus:mainfrom
greed42 wants to merge 1 commit intoprometheus:mainfrom
Conversation
This is an alternate mechanism for isolating Alertmanager clusters without having to set up the right components of TLS. It should solve issues such as <prometheus#2250>, although enabling this feature will lead to loss of non-persisted state. (For example, if you rely on alertmanager cluster peering to maintain silences instead of using persistent volume storage in Kubernetes.) The Gossip label serves as the "cluster ID" idea mentioned in <prometheus#2250 (comment)>. You can enable with the command-line flag, `--cluster.gossip-label`; any non-empty string will form an effective namespace for gossip communication. If you use Prometheus Operator, you can set the `ALERTMANAGER_CLUSTER_GOSSIP_LABEL` environment variable (as Prometheus Operator does not have a way of adding additional command-line flags). You would need to modify your Alertmanager object something like: ``` kind: Alertmanager ... spec: ... containers: - name: alertmanager env: - name: ALERTMANAGER_CLUSTER_GOSSIP_LABEL value: infrastructure-eu-west-2 ... ``` This is low-security mechanism, suitable for use with Alertmanager configuration where anyone can add or remove a silence. It protects against surprising cluster expansion due to IP:port re-use. Signed-off-by: Graham Reed <greed@7deadly.org>
greed42
force-pushed
the
gossip-label
branch
from
877dc9c to
983e4d7
Compare
Member
|
Superseded by #3354 |
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
2 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.
This is an alternate mechanism for isolating Alertmanager clusters without having to set up the right components of TLS.
It should solve issues such as #2250, although enabling this feature will lead to loss of non-persisted state. (For example, if you rely on alertmanager cluster peering to maintain silences instead of using persistent volume storage in Kubernetes.) The Gossip label serves as the "cluster ID" idea mentioned in #2250 (comment).
You can enable with the command-line flag,
--cluster.gossip-label; any non-empty string will form an effective namespace for gossip communication.If you use Prometheus Operator, you can set the
ALERTMANAGER_CLUSTER_GOSSIP_LABELenvironment variable (as Prometheus Operator does not have a way of adding additional command-line flags). You would need to modify your Alertmanager object something like:This is low-security mechanism, suitable for use with Alertmanager configuration where anyone can add or remove a silence. It protects against surprising cluster expansion due to IP:port re-use.