相关文章推荐

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.

 
推荐文章