NationTech/harmony
6
0
Fork 1
Code Issues 35 Pull Requests 6 Actions Packages Projects Releases 1 Wiki Activity

feat: add service monitors support to prom #66

Merged
johnride merged 9 commits from monitoring_servicemonitor into master 2025-07-02 15:29:23 +00:00
Conversation 0 Commits 9 Files Changed 7 +3 -2
2 changed files with 3 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit eeae14b6bb - Show all commits

3
examples/monitoring/src/main.rs
View File

@ -1,3 +1,4 @@
use std::collections::HashMap;
use harmony::{ use harmony::{
inventory::Inventory, inventory::Inventory,
@ -63,7 +64,7 @@ async fn main() {
target_labels: vec![], target_labels: vec![],
pod_target_labels: vec![], pod_target_labels: vec![],
selector: Selector { selector: Selector {
match_labels: None, match_labels: HashMap::new(),
match_expressions: vec![MatchExpression { match_expressions: vec![MatchExpression {
key: "test".to_string(), key: "test".to_string(),
operator: "In".to_string(), operator: "In".to_string(),

2
harmony/src/modules/monitoring/kube_prometheus/types.rs
View File

@ -154,7 +154,7 @@ pub struct MatchExpression {
#[serde(rename_all = "camelCase")] #[serde(rename_all = "camelCase")]
pub struct Selector { pub struct Selector {
// # label selector for services // # label selector for services
pub match_labels: Option<HashMap<String, String>>, pub match_labels: HashMap<String, String>,
pub match_expressions: Vec<MatchExpression>, pub match_expressions: Vec<MatchExpression>,
johnride commented 2025-06-26 13:43:47 +00:00
Outdated
Review
Copy Link

I think we already do have a Label type somewhere. I think it would be more appropriate here than String. That's true for all the label related fields in this file.

This Label type might not be fully compatible in its current form/place but it is definitely a semantic that we will see very often in various use cases and implementations. I think it is worth for us to maintain a Label type which we can eventually provide very interesting functionnality for such as search, tracking, matching, versionning, etc.

I think we already do have a Label type somewhere. I think it would be more appropriate here than String. That's true for all the label related fields in this file. This Label type might not be fully compatible in its current form/place but it is definitely a semantic that we will see very often in various use cases and implementations. I think it is worth for us to maintain a Label type which we can eventually provide very interesting functionnality for such as search, tracking, matching, versionning, etc.
} }