-
Notifications
You must be signed in to change notification settings - Fork 44
Add metrics port to operator #216
Conversation
… serving" This reverts commit 86d46bd.
knative-prow-robot
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do you change the name here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is serving.operator supported? I lean on to keep the full name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can use the underscore.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jihuin can you sent a PR to use serving_operator with underscore ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 😿 |
houshengbo
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/approve
|
[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