qq: does this issue happen starting from v0.14.2-gke.0?

I believe this has been going on for a while. We're on gcr.io/gke-release/custom-metrics-stackdriver-adapter:v0.12.2-gke.0 and I see this in our logs:

2024-03-14 08:23:25.409 EDT Trace[939984059]: [801.213144ms] [801.213144ms] END
2024-03-14 08:23:25.607 EDT Trace[911902081]: "SerializeObject" method:GET,url:/apis/custom.metrics.k8s.io/v1beta1,protocol:HTTP/2.0,mediaType:application/json,encoder:{"encoder":"{\"name\":\"json\",\"pretty\":\"false\",\"yaml\":\"false\"}","name":"versioning"} (14-Mar-2024 12:23:20.508) (total time: 5098ms):
2024-03-14 08:23:25.608 EDT Trace[911902081]: [5.098732769s] [5.098732769s] END

Thanks for providing this information!

/label custom-metrics-stackdriver-adapter

btw, @supersam654 did you find high memory issue in v0.12.2-gke.0? If so, try v0.14.2-gke.0 which fixed OOM/high memory issue.

Release note is here https://github.com/GoogleCloudPlatform/k8s-stackdriver/releases/tag/cm-sd-adapter-v0.14.0

These traces log are ignorable. Could you try increasing log level by

        - /adapter
        - --use-new-resource-model=false
        - --v=1

@kallangerard

Trace prints out because whatever action the trace is about takes longer than what the author expects. This is expected for metrics adapter because it fetches data from Cloud Monitoring.

Since the last version (0.15) this now outputs:

unknown flag: --v

when trying to mute Trace output. I think something broke the klog flag parsing. Maybe the initialisation order is wrong?

Update: the logTrace in k8s-stackdriver/event-exporter/vendor/k8s.io/utils/trace/trace.go matches the trace output (Trace[\d+] and END) perfectly. The issue seems to be that commit f3a96b5ed2c4dd345390001cee3500f4cca3c41c updated to klog v2, which no longer uses init() to register the flags:

# How to use klog
1. Replace imports for "github.com/golang/glog" with "k8s.io/klog/v2"
2. Use klog.InitFlags(nil) explicitly for initializing global flags as we no longer use init() method to register the flags

Our main problem with this is that the latter go (logs starting with "Trace") end up in stderr, and are therefore classified as "Error" in GCP Cloud Logging, falsely triggering as a problem in our monitoring.