NO-ISSUE: pkg/metrics/server: Log bind address

[wking]

To compete with the log lines from the controller-runtime, e.g. in 4.21.0-ec.1 CI:

$ curl -s https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/test-platform-results/logs/periodic-ci-openshift-release-master-nightly-4.21-e2e-aws-ovn-serial-2of2/1973126117392912384/artifacts/e2e-aws-ovn-serial/gather-extra/artifacts/pods/openshift-cluster-node-tuning-operator_cluster-node-tuning-operator-58c644666f-g89kv_cluster-node-tuning-operator.log | grep 'bindAddress\|server.go'
{"level":"info","ts":"2025-09-30T21:09:02Z","logger":"controller-runtime.metrics","msg":"Serving metrics server","bindAddress":":8080","secure":false}
I0930 21:12:00.231317       1 server.go:137] starting metrics server
I0930 21:14:24.437793       1 server.go:214] restarting metrics server to rotate certificates
I0930 21:14:24.457703       1 server.go:146] stopping metrics server
I0930 21:14:24.458144       1 server.go:137] starting metrics server

I dunno if both of those metrics servers are expected to be running, but at least logging the port for the locally-coded metrics server will reduce the odds that log-readers think "huh, the Pod spec says metrics are on 60000, but these logs say they're on 8080?".

[openshift-ci-robot]

@wking: This pull request explicitly references no jira issue.

In response to this:

To compete with the log lines from the controller-runtime, e.g. in 4.21.0-ec.1 CI:

$ curl -s https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/test-platform-results/logs/periodic-ci-openshift-release-master-nightly-4.21-e2e-aws-ovn-serial-2of2/1973126117392912384/artifacts/e2e-aws-ovn-serial/gather-extra/artifacts/pods/openshift-cluster-node-tuning-operator_cluster-node-tuning-operator-58c644666f-g89kv_cluster-node-tuning-operator.log | grep 'bindAddress\|server.go'
{"level":"info","ts":"2025-09-30T21:09:02Z","logger":"controller-runtime.metrics","msg":"Serving metrics server","bindAddress":":8080","secure":false}
I0930 21:12:00.231317       1 server.go:137] starting metrics server
I0930 21:14:24.437793       1 server.go:214] restarting metrics server to rotate certificates
I0930 21:14:24.457703       1 server.go:146] stopping metrics server
I0930 21:14:24.458144       1 server.go:137] starting metrics server

I dunno if both of those metrics servers are expected to be running, but at least logging the port for the locally-coded metrics server will reduce the odds that log-readers think "huh, the Pod spec says metrics are on 60000, but these logs say they're on 8080?".

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 openshift-eng/jira-lifecycle-plugin repository.

[jmencak]

/approve
/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jmencak, wking

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [jmencak]

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

[jmencak]

Potentially related to #1346

[jmencak]

/verified This is just adding a debug statement.

[openshift-ci-robot]

@jmencak: The /verified command must be used with one of the following actions: by, later, remove, or bypass. See https://docs.ci.openshift.org/docs/architecture/jira/#premerge-verification for more information.

In response to this:

/verified This is just adding a debug statement.

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 openshift-eng/jira-lifecycle-plugin repository.

[jmencak]

/verified bypass

[openshift-ci-robot]

@jmencak: The verified label has been added.

In response to this:

/verified bypass

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 openshift-eng/jira-lifecycle-plugin repository.

[wking]

Checking CI, no server.go in hypershift-e2e

$ curl -s https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/test-platform-results/pr-logs/pull/openshift_cluster-node-tuning-operator/1411/pull-ci-openshift-cluster-node-tuning-operator-main-e2e-hypershift/1978343517654618112/artifacts/e2e-hypershift/hypershift-aws-run-e2e-external/artifacts/TestCreateCluster/namespaces/e2e-clusters-mtmtp-create-cluster-psffj/core/pods/logs/cluster-node-tuning-operator-6d4d789fdc-5mmbc-cluster-node-tuning-operator.log | grep 'server.go\|bindAddress'
{"level":"info","ts":"2025-10-15T06:31:57Z","logger":"controller-runtime.metrics","msg":"Serving metrics server","bindAddress":":8080","secure":false}

likely this. Standalone e2e-aws-ovn shows the new log line working:

$ curl -s https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/test-platform-results/pr-logs/pull/openshift_cluster-node-tuning-operator/1411/pull-ci-openshift-cluster-node-tuning-operator-main-e2e-aws-ovn/1978329143237939200/artifacts/e2e-aws-ovn/gather-extra/artifacts/inspect/namespaces/openshift-cluster-node-tuning-operator/pods/cluster-node-tuning-operator-749d6b7c7b-rmk24/cluster-node-tuning-operator/cluster-node-tuning-operator/logs/current.log | grep 'server.go\|bindAddress'
2025-10-15T06:12:37.880225706Z {"level":"info","ts":"2025-10-15T06:12:37Z","logger":"controller-runtime.metrics","msg":"Serving metrics server","bindAddress":":8080","secure":false}
2025-10-15T06:15:22.291338421Z I1015 06:15:22.291301       1 server.go:137] starting metrics server on :60000
2025-10-15T06:17:46.492108117Z I1015 06:17:46.490221       1 server.go:214] restarting metrics server to rotate certificates
2025-10-15T06:17:46.492108117Z I1015 06:17:46.490248       1 server.go:146] stopping metrics server
2025-10-15T06:17:46.492108117Z I1015 06:17:46.490525       1 server.go:137] starting metrics server on :60000