Apiserver tracing #94942
Apiserver tracing #94942
Conversation
|
Skipping CI for Draft Pull Request. |
k8s-ci-robot
added
do-not-merge/work-in-progress
|
/sig instrumentation |
|
@dashpole: The label(s) In response to this:
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. |
k8s-ci-robot
added
sig/instrumentation
|
/sig api-machinery |
k8s-ci-robot
added
the
sig/api-machinery
dashpole
force-pushed
the
apiserver_opentelemetry
branch
from
0e897d2
to
e712ae9
Compare
|
/test all |
k8s-ci-robot
added
area/apiserver
area/cloudprovider
area/code-generation
area/dependency
k8s-ci-robot
added
sig/cluster-lifecycle
|
/retest |
|
lgtm, looks like there might be a few commits that should be squashed down? |
dashpole
force-pushed
the
apiserver_opentelemetry
branch
from
d593324
to
79550ed
Compare
|
squashed |
| } | ||
| // Even if there is no TracerProvider, the otelhttp still handles context propagation. | ||
| // See https://github.com/open-telemetry/opentelemetry-go/tree/main/example/passthrough | ||
| return otelhttp.NewHandler(handler, "KubernetesAPI", opts...) |
There was a problem hiding this comment.
just realized this is in k8s.io/apiserver, not specific to kube-apiserver... if there are multiple servers built on this library, does each need to have a unique id, or is it ok if they all report KubernetesAPI
There was a problem hiding this comment.
This controls the name of the span, so it should be whatever would best identify the server, and it doesn't have to be unique. https://github.com/kubernetes/kubernetes/pull/94942/files#diff-0e1453d49880a4f88f0353b9902c7e914513dd1274e3115100ea42c2d116136bR101-R106 is where we set the resource tags that should distinguish different instances of the apiserver. Right now, we tag it with the service name, "kube-apiserver", and the API Server ID, which has the pattern kube-apiserver-.
There was a problem hiding this comment.
ok... looks like APIServerID is overrideable by consumers of the k8s.io/apiserver library, so that's a reasonable thing to use... hard-coding kube-apiserver isn't good long-term, but can be adjusted in a follow-up
| "k8s.io/utils/path" | ||
| ) | ||
|
|
||
| const apiserverService = "kube-apiserver" |
There was a problem hiding this comment.
things other than kube-apiserver use k8s.io/apiserver, this will need a follow-up to be able to be set by the particular binary consuming the k8s.io/apiserver library
There was a problem hiding this comment.
Will rename to "apiserver".
|
/lgtm |
k8s-ci-robot
added
the
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: brancz, dashpole, dims, liggitt, lilic 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:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
|
/hold cancel |
k8s-ci-robot
removed
the
do-not-merge/hold
|
/retest |
|
@dashpole: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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. I understand the commands that are listed here. |
|
/retest |
What type of PR is this?
/kind feature
What this PR does / why we need it:
Enhancement issue: kubernetes/enhancements#647
Implementation of kubernetes/enhancements#1458.
Add tracing for API Server requests using opentelemetry-go, and the OTLP exporter. This has two primary components:
The following will be done as follow-ups:
Dependencies added
Does this PR introduce a user-facing change?:
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: