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.
By clicking “Sign up for GitHub”, you agree to our
terms of service
and
privacy statement
. We’ll occasionally send you account related emails.
Already on GitHub?
Sign in
to your account
currently only two types of status are available in kube_pod_container_status_waiting_reason metrics (ContainerCreating,ErrImagePull).
Can this be modified to have "Pending" as well, when the pods dont have enough resources to run?
Also include
ImagePullBackOff
and
CrashLoopBackOff
as a potential waiting reasons.
ImagePullBackOff
is the most prevalent waiting reason I see (k8s server version v1.7.7) in the case of a failed image pull.
ErrImagePull
is quite brief and will most likely be missed by a Prom scrape.
Ditto for
CrashLoopBackOff
. Crash-looping pods have a
current
state of
terminated
very briefly and then go into
waiting
with a reason of
CrashLoopBackOff
.
More broadly, it's unclear why this service is
so restrictive about potential label values
. It makes the collectors ignore useful data.
@mheggeseth
the reasoning is because every unique label combination creates a new time-series. Which inevitably puts higher load on the time-series database when we have unbound number of time-series. This is why we whilelist label names. If you wish to add more possible values I invite you to add them.