wip : new architecture test for Alerting, this one binds everything at the Score level. The score itself knows exactly what kind of sender is deployed on what such as Prometheus Sender deployed on Kubernetes. This still allows for extensibility where users can create new scores for new combinations easily, and allows for a generic AlertInterpret that handles reusable core logic to manage alerting concerns within Harmony

examples/monitoring/Cargo.toml

@@ -1,5 +1,5 @@
 [package]
-name = "monitoring"
+name = "example-monitoring"
 edition = "2024"
 version.workspace = true
 readme.workspace = true

examples/monitoring/src/main.rs

@@ -1,11 +1,11 @@
 use harmony::{
     inventory::Inventory, maestro::Maestro,
-    modules::monitoring::monitoring_alerting::{MonitoringAlertingScore, MonitoringSystem},
-    topology::K8sAnywhereTopology,
+    modules::monitoring::alert_score::PrometheusAlertingScore, topology::K8sAnywhereTopology,
 };
 
 #[tokio::main]
 async fn main() {
+    let alerting_score = PrometheusAlertingScore { receivers: vec![] };
     let mut maestro = Maestro::<K8sAnywhereTopology>::initialize(
         Inventory::autoload(),
         K8sAnywhereTopology::from_env(),
@@ -14,10 +14,11 @@ async fn main() {
     .unwrap();
 
     //let monitoring = MonitoringAlertingScore {
-    //    alert_receivers: vec![],       
+    //    alert_receivers: vec![],
     //    alert_rules: vec![],
     //    scrape_targets: vec![],
     //};
     //maestro.register_all(vec![Box::new(monitoring)]);
+    maestro.register_all(vec![Box::new(alerting_score)]);
     harmony_cli::init(maestro, None).await.unwrap();
 }