chore: ensure metrics are correctly exposed #701
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Oct 15, 2025
Techassi
reviewed
Oct 17, 2025
Comment on lines
+551
to
+565
| pub fn metrics_ports(&self, role: &HbaseRole) -> Vec<(String, u16)> { | ||
| match role { | ||
| HbaseRole::Master => vec![( | ||
| HBASE_METRICS_PORT_NAME.to_string(), | ||
| HBASE_MASTER_METRICS_PORT, | ||
| )], | ||
| HbaseRole::RegionServer => vec![( | ||
| HBASE_METRICS_PORT_NAME.to_string(), | ||
| HBASE_REGIONSERVER_METRICS_PORT, | ||
| )], | ||
| HbaseRole::RestServer => { | ||
| vec![(HBASE_METRICS_PORT_NAME.to_string(), HBASE_REST_METRICS_PORT)] | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
note: The mapping of role to metrics port exists in two places: Here and below at line 575 which inevitably contains the risk to drift apart. I think it makes sense to contain this mapping in a single place instead.
One possible solution is to drop the associated metrics_port function and user .map() to extract only the port numbers when needed.
Comment on lines
+554
to
+562
| HBASE_METRICS_PORT_NAME.to_string(), | ||
| HBASE_MASTER_METRICS_PORT, | ||
| )], | ||
| HbaseRole::RegionServer => vec![( | ||
| HBASE_METRICS_PORT_NAME.to_string(), | ||
| HBASE_REGIONSERVER_METRICS_PORT, | ||
| )], | ||
| HbaseRole::RestServer => { | ||
| vec![(HBASE_METRICS_PORT_NAME.to_string(), HBASE_REST_METRICS_PORT)] |
There was a problem hiding this comment.
suggestion: Use to_owned instead.
Suggested change
| HBASE_METRICS_PORT_NAME.to_string(), | |
| HBASE_MASTER_METRICS_PORT, | |
| )], | |
| HbaseRole::RegionServer => vec![( | |
| HBASE_METRICS_PORT_NAME.to_string(), | |
| HBASE_REGIONSERVER_METRICS_PORT, | |
| )], | |
| HbaseRole::RestServer => { | |
| vec![(HBASE_METRICS_PORT_NAME.to_string(), HBASE_REST_METRICS_PORT)] | |
| HBASE_METRICS_PORT_NAME.to_owned(), | |
| HBASE_MASTER_METRICS_PORT, | |
| )], | |
| HbaseRole::RegionServer => vec![( | |
| HBASE_METRICS_PORT_NAME.to_owned(), | |
| HBASE_REGIONSERVER_METRICS_PORT, | |
| )], | |
| HbaseRole::RestServer => { | |
| vec![(HBASE_METRICS_PORT_NAME.to_owned(), HBASE_REST_METRICS_PORT)] |
| .map(|(name, value)| ServicePort { | ||
| name: Some(name), | ||
| port: i32::from(value), | ||
| protocol: Some("TCP".to_string()), |
There was a problem hiding this comment.
suggestion: Use to_owned instead.
Suggested change
| protocol: Some("TCP".to_string()), | |
| protocol: Some("TCP".to_owned()), |
| &rolegroup.role_group, | ||
| )) | ||
| .context(ObjectMetaSnafu)? | ||
| .with_label(Label::try_from(("prometheus.io/scrape", "true")).context(LabelBuildSnafu)?) |
There was a problem hiding this comment.
question: Does it make sense to pull this key out into a constant? Or make it an associated function on Label, like Label::prometheus_scrape()?
Comment on lines
+831
to
+832
| type_: Some("ClusterIP".to_string()), | ||
| cluster_ip: Some("None".to_string()), |
There was a problem hiding this comment.
suggestion: Use to_owned instead.
Suggested change
| type_: Some("ClusterIP".to_string()), | |
| cluster_ip: Some("None".to_string()), | |
| type_: Some("ClusterIP".to_owned()), | |
| cluster_ip: Some("None".to_owned()), |
Comment on lines
+847
to
+865
| fn prometheus_annotations(hbase: &v1alpha1::HbaseCluster, hbase_role: &HbaseRole) -> Annotations { | ||
| Annotations::try_from([ | ||
| ("prometheus.io/path".to_owned(), "/prometheus".to_owned()), | ||
| ( | ||
| "prometheus.io/port".to_owned(), | ||
| hbase.metrics_port(hbase_role).to_string(), | ||
| ), | ||
| ( | ||
| "prometheus.io/scheme".to_owned(), | ||
| if hbase.has_https_enabled() { | ||
| "https".to_owned() | ||
| } else { | ||
| "http".to_owned() | ||
| }, | ||
| ), | ||
| ("prometheus.io/scrape".to_owned(), "true".to_owned()), | ||
| ]) | ||
| .expect("should be valid annotations") | ||
| } |
There was a problem hiding this comment.
question: Similar question to above - does it make sense to pull these out into contants or associated function on Annotation?
Techassi
moved this from Development: Waiting for Review
to Development: In Review
in Stackable Engineering
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Part of stackabletech/issues#747
This PR adds a metrics service with the additional Prometheus annotations. It also adds some documentation on monitoring for the TLS case since, similar to NiFi, HBase also exposes metrics behind a port which gets secured by TLS
Follow up monitoring Stack PR because moving to the metrics service, the port name changed: stackabletech/demos#316
Definition of Done Checklist
Author
Reviewer
Acceptance
type/deprecationlabel & add to the deprecation scheduletype/experimentallabel & add to the experimental features tracker