You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thank's for filing this @povilasv, modeling this as a metric makes sense!
There is a proposal on how we should model such "state"/"phase"/"status" metrics in SemConv. It is already in use by hw metrics and jmx metrics as mentioned at #1032 (comment) (see #1554).
Process' status will also be modeled like this: #1212 (comment)
I have filed another one for k8s.namespace.phase: #1668 which I think will help us verify the proposal.
My only question here would be how the modeling should actually look like. What you propose aligns with kube-state-metrics but I would like to see how this will be combined with other statuses like running and terminated as well as how we reflect the reason part. Can we deal with them all at once so as to ensure that the decision will scale and cover all?
FWIWI, If I'm not mistaken we can't have k8s.container.status.waiting and k8s.container.status.waiting.reason (metric name cannot be namespace at the same time).
Area(s)
area:k8s
Is your change request related to a problem? Please describe.
K8s Cluster receiver uses would like to monitor K8s CrashLoop Back off state. We had a multiple issues about it:
Previously I tried to model
status.waiting
as Resource attribute, but because it's mutable it cannot be Resource attribute. See #997I would like to propose adding this as metric to unblock this PR open-telemetry/opentelemetry-collector-contrib#35668
Describe the solution you'd like
Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: