[Misc] Standardizing klog Level Guidelines in AIBrix

[kr11]

Summary

This issue aims to standardize klog level usage across Kubernetes controllers by establishing clear logging guidelines.

For the immediate phase, we will standardize on klog.V(4).

Motivation

With varying klog levels observed in files like modeladapter_controller.go and podautoscaler_controller.go, it's challenging to maintain and analyze logs effectively. Standardizing log levels and creating detailed guidelines will enable more consistent and meaningful logging, aiding in development and troubleshooting.

Proposed Change

No response

Alternatives Considered

No response

[Jeffwan]

info, warning and error should be revisited for all the codes using this opportunity. Varun notice some references are incorrect #135 (comment)

[Jeffwan]

Let's use V(2) and V(4) in logs, there's no need to use V(3) which complex the management

[Jeffwan]

@kr11 Can you help find all v(3) and v(5) instance and change to V(2) or V(4) based on the log information? BTW, v(2) is the default level and klog.v(4).InfoS equivalent to klog.InfoS. Let's probably also remove v(2) for all logs that explicitly using v(2)

[Jeffwan]

if you can add some guidance in the development docs. that would be great! l

[Jeffwan]

Besides the log level, since we use klog to simplify the logger import. now it have different log formats which needs to be refactored

we probably can use this adaptor https://github.com/kubernetes/klog/blob/main/klogr/klogr.go or just change to structure logging

[kr11]

@kr11 Can you help find all v(3) and v(5) instance and change to V(2) or V(4) based on the log information? BTW, v(2) is the default level and klog.v(4).InfoS equivalent to klog.InfoS. Let's probably also remove v(2) for all logs that explicitly using v(2)

@Jeffwan I just add a PR #202 about this issue, please take a look.

And, is klog.v(4).InfoS equivalent to klog.InfoS a typo? Should it be klog.V(2).InfoS = klog.InfoS instead? 😊

[Jeffwan]

@kr11 good catch. that's a typo.

[Jeffwan]

#264 addressed this issue.