Add Prometheus metrics to readiness condition reporter - #379
Conversation
✅ Deploy Preview for node-readiness-controller ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Hi @rawadhossain. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Tip We noticed you've done this a few times! Consider joining the org to skip this step and gain Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
/ok-to-test |
AvineshTripathi
left a comment
There was a problem hiding this comment.
Thank you for starting this PR! I have left some comments
| // reporterChecksTotal tracks total probe check results over time. | ||
| reporterChecksTotal = prometheus.NewCounterVec( | ||
| prometheus.CounterOpts{ | ||
| Name: "node_readiness_reporter_checks_total", |
There was a problem hiding this comment.
node_readiness_reporter_checks instead
There was a problem hiding this comment.
but I see in #344 it says node_readiness_reporter_checks_total
There was a problem hiding this comment.
Yeah, was confused about this too, so kept it as in the design doc.
There was a problem hiding this comment.
I followed https://prometheus.io/docs/practices/naming/#metric-names. The metrics convention suggests that an accumulating count has total as a suffix. Also on a similar note, https://www.robustperception.io/on-the-naming-of-things/ was a good read on why our node_readiness_rules_total (a gauge) metric could drop the suffix as can cause to confusions like this.
| mux.HandleFunc("/healthz", func(w http.ResponseWriter, _ *http.Request) { | ||
| w.WriteHeader(http.StatusOK) | ||
| }) | ||
| metricsServer := &http.Server{ |
There was a problem hiding this comment.
why not using "sigs.k8s.io/controller-runtime/pkg/metrics/server"? We already have it as part of go.mod
There was a problem hiding this comment.
Yeah, I looked into this one. It can run standalone without a full Manager setup, but I kept the current approach for a few reasons:
- We use a dedicated registry for the Reporter, so the
/metricsendpoint only exposes the metrics we explicitly register. - The current implementation gives us explicit control over the metrics server shutdown and keeps the existing klog setup.
- Using
metrics/serverdoesn't really make the implementation simpler once the registry and logging setup are included.
I also tested the current setup with a real SIGTERM against a live pod, and it shuts down cleanly in ~0.3s. So I kept the current implementation since it gives us the behavior we wanted and is already validated. Im okay to switch to metrics/server if you think that's preferable here.
Signed-off-by: Rawad Hossain <rawad.hossain00@gmail.com>
| // reporterBuildInfo tracks the reporter binary version to track fleet version skew. | ||
| reporterBuildInfo = prometheus.NewGaugeVec( | ||
| prometheus.GaugeOpts{ | ||
| Name: "node_readiness_reporter_build_info", |
There was a problem hiding this comment.
@rawadhossain just reviewed #406. Don't we need the ldFlags on this one?
There was a problem hiding this comment.
@ajaysundark done with the idFlags changes now that #406 is merged. PTAL.
Signed-off-by: Rawad Hossain <rawad.hossain00@gmail.com>
3613030 to
2e35f85
Compare
|
/lgtm I think this is all good now. @ajaysundark can you take a final look |
| prometheus.HistogramOpts{ | ||
| Name: "node_readiness_reporter_check_duration_seconds", | ||
| Help: "Duration of health probe checks.", | ||
| Buckets: prometheus.DefBuckets, |
There was a problem hiding this comment.
An AI review caught this as excessive, so I looked it up - https://pkg.go.dev/github.com/prometheus/client_golang/prometheus#pkg-variables. The default bucket seems to be 11 buckets from 0.005 granularity to 10s.
I wonder whether these many milliseconds accuracy is needed. May be we could keep it fewer to something like {0.1, 0.5, 1, 5, 10 }?
There was a problem hiding this comment.
Looked into this and I agree that the default buckets are more than we need here. Tested it by running the reporter against real traffic + some deliberate slow responses to see which buckets actually mattered.
So I ended up with {0.005, 0.1, 0.25, 0.5, 1, 2.5, 5, 10}. Kept a few more buckets since they were catching useful delays in testing.
Committed the changes. PTAL.
|
/lgtm please address the comments when you get time before we could merge this. |
|
/lgtm Adding it again! Changes looks good |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ajaysundark, rawadhossain The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Description
Implements the Reporter metrics specified in the observability design
node_readiness_reporter_build_infonode_readiness_reporter_check_duration_secondsnode_readiness_reporter_checks_totalnode_readiness_reporter_condition_writes_totalAlso adds the Prometheus
/metricsand/healthzendpoints to the readiness condition reporter.Implementation choices
/metricsand/healthzto keep the Reporter to one listener and port.:9445as the default metrics port because the Reporter runs withhostNetwork: true. The address is configurable throughMETRICS_BIND_ADDRESS.Build fix
Updated
Dockerfile.reporterto build the Reporter package instead of single filemain.go, since the newmetrics.goalso needs to be included.Fixes #380
Type of Change
/kind feature
Testing
kindcluster and Prometheus.Checklist
make testpassesmake lintpasses