notification-controller
notification-controller copied to clipboard
fluxcd
Is it possible to get cluster-name, while we are sending notifications to ms teams
We are trying to send notifications from different cluster, nearly we are creating 10 clusters at a time, need to get notifications to same channel with cluster name. so that we can easily identify from which cluster we are getting notification.
Please help where I need to mention about cluster name?
You can mention it in the .spec.summary of your Alert. Ref: https://fluxcd.io/docs/components/notification/alert/
In .spec.summary we need to mention like as message, but we don't like to touch our Alert every time. While getting notification in our channel value should be replace with cluster name automatically. Any possibility we have?
@Naresh240 if what you mean is the cluster name being automatically added to the alert, that is currently not supported.
I think it would generally make sense to have a means of exposing a cluster name through the Events API. However, the question is, how? One could use the .metadata.uid of the kube-system Namespace which is assumed to be (1) available on every Kubernetes cluster and (2) unique. That ID changes every time the cluster is created which might happen on a regular basis, especially in dev environments. You don't want your handle to change every time. Therefore, notification-controller must provide an API to let users explicitly set the cluster name/ID they expect alerts from that cluster to carry and I'm led to believe that .spec.summary might just be the right field for that. It can easily be set per-cluster using kustomization overlays. Or maybe a dedicated .spec.origin field would help here?
The cluster name is unknown to Kubernetes itself, so there is no way to get this info automatically. You can use a kustomize patch that targets all Alerts objects and sets the cluster name in .spec.summary.
The cluster name is unknown to Kubernetes itself, so there is no way to get this info automatically. You can use a kustomize patch that targets all Alerts objects and sets the cluster name in
.spec.summary.
How about adding a dedicated origin field (or however we choose to call it) to the Alert spec?
How about adding a dedicated origin field (or however we choose to call it) to the Alert spec?
Why add a 2nd field that does the same thing as summary? I would consider adding a cmd flag to notification-controller e.g. --cluster-name that would inject the value in the alert message body.
@stefanprodan How could an implementation of this look like when using Grafana Annotations? The summary field doesn't seem to be attached in https://github.com/fsequeira1/notification-controller/blob/main/internal/notifier/grafana.go or am I'm missing something?
Would be nice to show somehow from which cluster the annotations comes from. We have a Flux Dashboards for multiple clusters and it's very hard to distinguish, which annotations is from which cluster.
This feels like a big deal. We want to use Flux to orchestrate deployments to a fleet of Kube Clusters. If we don't know where the events are coming back from, then its value gets a little muddy.
This feels like a big deal. We want to use Flux to orchestrate deployments to a fleet of Kube Clusters. If we don't know where the events are coming back from, then its value gets a little muddy.
What we (Weaveworks) did in Weave GitOps Enterprise is to instantiate an endpoint on the management cluster for each managed cluster so that each managed cluster hits a unique endpoint.