Add metrics port to operator#216
Add metrics port to operator#216knative-prow-robot merged 7 commits intoknative:masterfrom jihuin:metrics-port
Conversation
… serving" This reverts commit 86d46bd.
knative-prow-robot
left a comment
There was a problem hiding this comment.
@jihuin: 0 warnings.
Details
In response to this:
Fixes #192
Proposed Changes
- Added metrics port in
operator.yamlso the operator can report metrics to 9090 port.- Changed the component name from
serving-operatortooperatorbecause-is not allowed in metric name for prometheus exporter.Currently the operator only emits the metrics on reconcile count, reconcile latency and work queue depth, that are inherited from
knative.dev/controller.Release Note
NONE
Instructions 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/test-infra repository.
|
/assign @garron |
|
/lgtm |
cmd/manager/main.go
Outdated
| log.Fatal("Error building kubeconfig", err) | ||
| } | ||
| sharedmain.MainWithConfig(signals.NewContext(), "serving-operator", cfg, knativeserving.NewController) | ||
| sharedmain.MainWithConfig(signals.NewContext(), "operator", cfg, knativeserving.NewController) |
There was a problem hiding this comment.
Because the component name serving-operator will be passed to the prometheus exporter as a prefix in the metric name, but the symbol - is not allowed in the prometheus metric name. Meanwhile, single-word application/component name is recommended by prometheus and all other components in knative serving have single-word names.
There was a problem hiding this comment.
Is serving.operator supported? I lean on to keep the full name.
There was a problem hiding this comment.
Only letters, digits and underscores are supported, and single-word prefix is recommended. See https://prometheus.io/docs/practices/naming/
Since all knative serving components have single-word names, e.g. webhook, activator, autoscalar, it makes sense to align with the current naming pattern.
There was a problem hiding this comment.
Good catch @jihuin I noticed the same, and I know that ALL other knative components NOW using _ underscore. For instance:
Since we have more than one operator, let's please use serving_operator !
There was a problem hiding this comment.
@jihuin can you sent a PR to use serving_operator with underscore ?
There was a problem hiding this comment.
Changed to serving_operator
| - name: CONFIG_LOGGING_NAME | ||
| value: config-logging | ||
| - name: CONFIG_OBSERVABILITY_NAME | ||
| value: config-observability |
There was a problem hiding this comment.
I do not think we need to add CONFIG_LOGGING_NAME and CONFIG_OBSERVABILITY_NAME, anymore.
By default, knative/pkg will pick config-logging and config-observability.
There was a problem hiding this comment.
It's true that knative/pkg will watch config-logging and config-observability configmaps by default if nothing is specified. Maybe it is meaningful to add here to let the users be aware of the purposes of these two configmaps.
There was a problem hiding this comment.
Though the configmap filenames are quite self-explaining, the users can not see if or where the configmaps are watched unless digging into knative/pkg
There was a problem hiding this comment.
knative/pkg@9491151
I just had this PR merged. If config-logging and config-observability are missing, the controller should be launched without problem. With this PR, would it be fine, if config-logging and config-observability are missing??
There was a problem hiding this comment.
@jihuin again, you are correct here.
See knative/eventing@36058f4 for adding port (the CONFIG_XYZ_NAME were already in the yamls, eg:
There was a problem hiding this comment.
If the configmaps are missing and not watched, the exporter won't be set up and no metric is exported, but no information is provided in the logs. The configs here can be informative.
|
@jihuin Is there any test we can leverage to check if metrics are exposed? |
|
@houshengbo The metrics are reported through The port number is configurable, and 9090 is the default port number of Prometheus server. |
|
@jihuin I would like to test this change locally, could you tell me the steps? Thx. |
|
@houshengbo Steps to test metrics with Prometheus exporter (default):
|
matzew
left a comment
There was a problem hiding this comment.
let;s change the component name to serving_operator
|
@jihuin can u report on your CLA status ? |
|
@googlebot rescan |
|
/lgtm |
|
@n3wscott I think this now looks good... mind approving ? I am not an approver here, on the serving operator 😿 |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: houshengbo, jihuin, matzew 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 |
Fixes #192, #5
Proposed Changes
operator.yamlso the operator can report metrics to 9090 port.serving-operatortoserving_operatorbecause-is not allowed in metric name for prometheus exporter.Currently the operator only emits the metrics on reconcile count, reconcile latency and work queue depth, that are inherited from
knative.dev/controller.Release Note