Format the log

[yanmxa]

Here's a comprehensive comparison of the specified logging libraries based on various features, including log format, log level configuration, dynamic change log level, log code location, and time formatting:

Library	Log Format	Log Level Configuration	Control Log Level	Log Code Location	Time Formatting	Support Dynamic Level Configuration	Notes
glog	Text-based	Via command-line flags	Set via -v flag for verbosity levels	Yes, with log.V() calls	Default format (RFC3339)	No	Simple interface, widely used in Go.
zap	JSON or text	Via config or code	Configurable at initialization with log levels	Yes, with caller information	Customizable format	Yes	High performance, structured logging.
zapr	JSON or text	Via logr interface	Same as zap; uses logr interface for config	Yes, with caller information	Follows zap configuration	Yes	Adapter for zap, integrates with logr.
logr	Text-based (varies)	Via context or runtime config	Control via context or runtime configuration	Yes, with WithValues	Format varies by backend	Yes	Interface for structured logging, flexible.
klog	Text-based	Via command-line flags	Set via --v flag for verbosity levels	Yes, provides file and line	Default format (RFC3339)	No	Designed for Kubernetes, simpler format.

• We want to configure the LogLevel at run time and format the time to make it readable! So glog and klog are not suitable, I will remove them from the list.
• zap provides advanced features like structured logging and customizable formats, making it suitable for high-performance applications.
• zapr and logr offer flexibility through their interfaces, integrating well with other logging systems while providing features like context-based logging.

[yanmxa]

zap Vs zapr ?

• zap is highly flexible and allows you to configure multiple log levels, providing detailed control over how logs are recorded. However, when logging key-value pairs, you must use zapcore.Filed to structure the key/value entries

  logger.Info("Info log", zapcore.Field{Key: "key", String: "val"})

• zapr builds on zap's flexibility, reusing the same configuration. The key difference is that zapr exposes a higher-level, user-friendly interface for logging key-value pairs. Instead of manually using zapcore.Field, you can directly log with a cleaner syntax:

  log.V(0).Info("info", "key", "val")

  The cons

  • dynamic log level changes in zapr are managed by the underlying zap logger. while V(0) typically corresponds to INFO, and V(1) to DEBUG, levels beyond V(1) may not behave as expected, as zap doesn't directly map them.
  • This limitation makes higher verbosity levels (V(2) and above) less useful or unsupported. For the global hub, sticking to standard DEBUG, INFO, and ERROR levels are sufficient and works well for typical use cases.
  • The -2 in the above snippet means that log.V(2).Info() calls will be active. -3 would enable log.V(3).Info(), etc. Note that zap's levels are int8 which means the most verbose level you can give it is -128. The zapr implementation will cap V() levels greater than 127 to 127, so setting the zap level to -128 really means "activate all logs".

    zc.Level.SetLevel(-2)
    ...
    log.V(2).Info("-2heloo2", "ni", "hao")
    ...
    2024-10-23T21:00:22.363+0800    LEVEL(-2)       log-zapr/main.go:83     -2heloo2        {"ni": "hao"}

[yanmxa]

Suggest using the zapr, which can be invoked by the interface logr easily. The only concern is it only supports DEBUG, INFO, and ERROR