Skip to content
This repository was archived by the owner on Jun 24, 2020. It is now read-only.

Conversation

@jihuin
Copy link
Contributor

@jihuin jihuin commented Nov 13, 2019

Fixes #192, #5

Proposed Changes

  • Added metrics port in operator.yaml so the operator can report metrics to 9090 port.
  • Changed the component name from serving-operator to serving_operator because - 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

Copy link
Contributor

@knative-prow-robot knative-prow-robot left a 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.yaml so the operator can report metrics to 9090 port.
  • Changed the component name from serving-operator to operator because - 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.

@jihuin
Copy link
Contributor Author

jihuin commented Nov 13, 2019

/assign @anniefu @trshafer

@jihuin
Copy link
Contributor Author

jihuin commented Nov 13, 2019

/assign @garron

@anniefu
Copy link
Contributor

anniefu commented Nov 13, 2019

/lgtm

log.Fatal("Error building kubeconfig", err)
}
sharedmain.MainWithConfig(signals.NewContext(), "serving-operator", cfg, knativeserving.NewController)
sharedmain.MainWithConfig(signals.NewContext(), "operator", cfg, knativeserving.NewController)

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?

Copy link
Contributor Author

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.

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.

Copy link
Contributor Author

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.

Copy link
Member

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 !

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.

Copy link
Member

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 ?

Copy link
Contributor Author

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

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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

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??

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

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.

@houshengbo
Copy link

@jihuin Is there any test we can leverage to check if metrics are exposed?
Is 9090 the only port designated to metrics or is it something we can configure?

@jihuin
Copy link
Contributor Author

jihuin commented Nov 14, 2019

@houshengbo The metrics are reported through knative.dev/pkg/controller, and are tested in the same package: https://github.com/knative/pkg/blob/master/controller/stats_reporter_test.go

The port number is configurable, and 9090 is the default port number of Prometheus server.

@houshengbo
Copy link

@jihuin I would like to test this change locally, could you tell me the steps? Thx.

@jihuin
Copy link
Contributor Author

jihuin commented Nov 14, 2019

@houshengbo Steps to test metrics with Prometheus exporter (default):

  1. Forward the local port 9090 to the port 9090 on operator pod via the command
    kubectl port-forward ${{operator_pod_name}} 9090

  2. Check the metrics by visiting localhost:9090/metrics in the browser, or run curl localhost:9090/metrics in the terminal

Copy link
Member

@matzew matzew left a 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

@matzew
Copy link
Member

matzew commented Nov 14, 2019

@jihuin can u report on your CLA status ?

@jihuin
Copy link
Contributor Author

jihuin commented Nov 14, 2019

@googlebot rescan

@googlebot googlebot added the cla: yes Author(s) signed a CLA. label Nov 14, 2019
@matzew
Copy link
Member

matzew commented Nov 15, 2019

/lgtm
/approve

@matzew
Copy link
Member

matzew commented Nov 15, 2019

@n3wscott I think this now looks good... mind approving ?

I am not an approver here, on the serving operator 😿

Copy link

@houshengbo houshengbo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm
/approve

@knative-prow-robot
Copy link
Contributor

[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

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@knative-prow-robot knative-prow-robot merged commit 6d87a77 into knative:master Nov 15, 2019
@jihuin jihuin deleted the metrics-port branch November 19, 2019 05:02
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Operator should emit metrics

8 participants