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
2 changed files with 18 additions and 18 deletions
Showing only changes of commit 8dee6a7162 - Show all commits

View File

@ -21,7 +21,6 @@ use harmony::{
};
use harmony_macros::http_scheme;
use serde_yaml::{Mapping, Value};
#[tokio::main]
async fn main() {
@ -58,24 +57,20 @@ async fn main() {
relabelings: vec![],
};
let mut selector = HashMap::new();
selector.insert(
"matchExpressions".to_string(),
vec![Selector {
key: "monitored".to_string(),
operator: "In".to_string(),
values: vec!["test-service-1".to_string()],
}],
);
let service_monitor = ServiceMonitor {
name: "test-service-monitor".to_string(),
additional_labels: None,
job_label: None,
target_labels: vec![],
pod_target_labels: vec![],
selector: selector,
match_labels: None,
selector: Selector {
match_labels: None,
match_expressions: vec![MatchExpression {
key: "test".to_string(),
operator: "In".to_string(),
values: vec!["test-service".to_string()],
}],
},
namespace_selector: None,
endpoints: vec![service_monitor_endpoint],
fallback_scrape_protocol: None,

View File

@ -145,12 +145,20 @@ pub struct ServiceMonitorEndpoint {
#[derive(Debug, Clone, Serialize)]
#[serde(rename_all = "camelCase")]
pub struct Selector {
pub struct MatchExpression {
pub key: String,
pub operator: String,
pub values: Vec<String>,
}
#[derive(Debug, Clone, Serialize)]
#[serde(rename_all = "camelCase")]
pub struct Selector {
// # label selector for services
pub match_labels: Option<HashMap<String, String>>,

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.
pub match_expressions: Vec<MatchExpression>,
}
#[derive(Debug, Clone, Serialize)]
#[serde(rename_all = "camelCase")]
pub struct ServiceMonitor {
@ -178,10 +186,7 @@ pub struct ServiceMonitor {
// values:
// - example-service-1
// - example-service-2
pub selector: HashMap<String, Vec<Selector>>,
// # label selector for services
pub match_labels: Option<Mapping>,
pub selector: Selector,
// # Namespaces from which services are selected
// # Match any namespace