/assign
/triage accepted
/priority important-soon

/approve

Looks like only David can approve this. @dashpole should we perhaps take an action item to add sig-instrumentation approvers and reviewers to kubelet metrics owner file?

/assign @dashpole

Sorry, just getting back from vacation. Sig node owns these packages, and I am an approver based on my previous work in sig-node. Anyone with pkg/kubelet can also approve, so it isn't just me, but it might be nice for someone else who spans both sigs (maybe @ehashman) to be an approver here as well. Did we find the root cause of the negative start time? This change is unobjectionable, but is probably hiding a real issue. With just this change, we would end up dropping metrics that might be valid.

The containerStats.StartTime comes from the container.spec.CreateTime which is collected by cadvisor, so if the containerStats.StartTime is not initialized, it means that the container.spec.CreateTime was not set by cadvisor while it created the containerData. But see the code, normaly it is not possible for the CreateTime not set except in some extreme case. @bobbypage did you ever meet that the container.spec.CreateTime was not set by cadvisor? thanks
https://github.com/google/cadvisor/blob/master/container/common/helpers.go#L74-L99

@dashpole This issue occurs when the pod terminates.
According to @249043822 's analysis, normal data statistics will not be affected,Only happens when the container state changes
so merge this pr we would not end up dropping metrics that might be valid. but we still need to find the root cause .
/cc @249043822 @bobbypage

It looks like @AtkinsChang was right in his comment on May 23. This appear to be from an "empty" time object.

This code snippet return the same as seen in the issue;

package main

import (
	"fmt"
	"time"
)
func main() {
	t := time.Time{}
	fmt.Printf("metric: %e, %d", float64(t.UnixNano())/float64(time.Second), t.Unix()*1000+int64(t.Nanosecond()/1000000))
}

Running it returns metric: -6.795365e+09, -62135596800000.

Can you please describe more about your setup here @yangjunmyfm1920? Is this due to CRI metrics returning the wrong value, or some other thing? It would be nice to be able to reproduce it to be sure about what is causing it. I can't see how that referred cadvisor PR can result in such a time.Time value, so I suspect its something else...

Do you know more about the CRI metrics pipeline ref. the above @dashpole?

Lgtm as well, but think we should find the root cause for this!

/lgtm

I'm not aware of the current status of CRI-O, but it used to still use cAdvisor for metrics. If that is the case, then it would be the cAdvisor code responsible for detecting container start time in this case.

It looks like @AtkinsChang was right in his comment on May 23. This appear to be from an "empty" time object.

This code snippet return the same as seen in the issue;

package main

import (
	"fmt"
	"time"
)
func main() {
	t := time.Time{}
	fmt.Printf("metric: %e, %d", float64(t.UnixNano())/float64(time.Second), t.Unix()*1000+int64(t.Nanosecond()/1000000))
}

Running it returns metric: -6.795365e+09, -62135596800000.

Can you please describe more about your setup here @yangjunmyfm1920? Is this due to CRI metrics returning the wrong value, or some other thing? It would be nice to be able to reproduce it to be sure about what is causing it. I can't see how that referred cadvisor PR can result in such a time.Time value, so I suspect its something else...

Do you know more about the CRI metrics pipeline ref. the above @dashpole?

Lgtm as well, but think we should find the root cause for this!

/lgtm

I agree with @dashpole

/test pull-kubernetes-unit

/test pull-kubernetes-e2e-gce-ubuntu-containerd

/test pull-kubernetes-e2e-kind

The Kubernetes project has merge-blocking tests that are currently too flaky to consistently pass.

This bot retests PRs for certain kubernetes repos according to the following rules:

• The PR does have any do-not-merge/* labels
• The PR does not have the needs-ok-to-test label
• The PR is mergeable (does not have a needs-rebase label)
• The PR is approved (has cncf-cla: yes, lgtm, approved labels)
• The PR is failing tests required for merge

You can:

• Review the full test history for this PR
• Prevent this bot from retesting with /lgtm cancel or /hold
• Help make our tests less flaky by following our Flaky Tests Guide

/retest

@yangjunmyfm192085 pls rebase

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: 249043822, dashpole, dgrisonnet, wzshiming, yangjunmyfm192085

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

The pull request process is described here

/lgtm

/test pull-kubernetes-unit

/test pull-kubernetes-e2e-kind