Alert receiver architecture simplification #178

New Issue

johnride · 2025-10-24T20:09:25Z

johnride commented

2025-10-24 20:09:25 +00:00

Currently alert receivers have completely independent configuration for each kind of sender, and each very specific kind of sender is implemented by the receiver. For instance, in https://git.nationtech.io/NationTech/harmony/src/branch/master/harmony/src/modules/monitoring/alert_channel/discord_alert_channel.rs we can see that :

DiscordWebhook implements AlertReceiver for about 8 different kinds of Sender.
This makes it extremely cumbersome to add new kinds of receivers as they will have to implement 8 different specializations of AlertReceiver too
- RHOBObservability
- CRDPrometheus
- Prometheus
- KubePrometheus
- (ok maybe only 4 after all)
All these different Senders are, in fact, different flavors of AlertManager

This should be refactored to allow all these senders to use a common implementation of a sensible trait such as

pub trait AlertManagerReceiver {
  fn get_receiver_config(&self) -> serde_json::Value;
}

impl AlertManagerReceiver for DiscordWebhook {

  fn get_receiver_config(&self) -> serde_json::Value {
    self.get_receiver_value()
  }
}

note we will have to consider that some alert receivers have dependencies. Some can be simple, such as a Secret in the case of the DiscordWebhook support provided by OKD to store the actual webhook url value. Some may be more complex such as an entire helm chart for older alertmanager instances that don't bundle the discord receiver handler.

Currently alert receivers have completely independent configuration for each kind of sender, and each very specific kind of sender is implemented by the receiver. For instance, in https://git.nationtech.io/NationTech/harmony/src/branch/master/harmony/src/modules/monitoring/alert_channel/discord_alert_channel.rs we can see that : - DiscordWebhook implements AlertReceiver for about 8 different kinds of Sender. - This makes it extremely cumbersome to add new kinds of receivers as they will have to implement 8 different specializations of AlertReceiver too - RHOBObservability - CRDPrometheus - Prometheus - KubePrometheus - (ok maybe only 4 after all) - All these different Senders are, in fact, different flavors of AlertManager This should be refactored to allow all these senders to use a common implementation of a sensible trait such as ```rust pub trait AlertManagerReceiver { fn get_receiver_config(&self) -> serde_json::Value; } impl AlertManagerReceiver for DiscordWebhook { fn get_receiver_config(&self) -> serde_json::Value { self.get_receiver_value() } } ``` **note** we will have to consider that some alert receivers have dependencies. Some can be simple, such as a Secret in the case of the DiscordWebhook support provided by OKD to store the actual webhook url value. Some may be more complex such as an entire helm chart for older alertmanager instances that don't bundle the discord receiver handler.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: NationTech/harmony#178