Easegress Logger initialization problem and rotation feature

[jthann]

1、In some cases，we need to use logger in init function like this:

func init() {
	logger.Infof("Register adapter %s",xxx)
}

This will report errorpanic: runtime error: invalid memory address or nil pointer dereference， because at this time point，Easegress logger is initialized in main entrypoint. Perhaps for standard out console logger，it should initialize in init not in main. Or is there are any better way to solve this problem.

2、Easegress implement writer logic for performance internally and should support Logger rotation feature as following：

w := zapcore.AddSync(&lumberjack.Logger{
  Filename:   "/var/log/myapp/foo.log",
  MaxSize:    500, // megabytes
  MaxBackups: 3,
  MaxAge:     28, // days
})
core := zapcore.NewCore(
  zapcore.NewJSONEncoder(zap.NewProductionEncoderConfig()),
  w,
  zap.InfoLevel,
)
logger := zap.New(core)

[localvar]

1. we can only know the logger configuration after entering the main function, so I don't think we can initialize the logger in init functions. for your case, I propose to use the fmt.Print to write the log messages (even we use the logger, we can only write the message to standard output before initializing the logger), and I also think you can omit the log, because init functions cannot return an error, which means it should always succeed and should panic if it does fail.
2. Easegress support log rotate, this can be done via using the logrotate command of the OS, below is an example configuration:

/opt/easegress/log/*.log {
    daily
    rotate 10
    compress
    delaycompress
    missingok
    notifempty
    create 644 root root
    postrotate
        /usr/bin/killall -HUP easegress-server
    endscript
}

[jthann]

@localvar Thanks, I'm unfamiliar with logrotate command of OS，that means we should custom Easegress Dockerfile by adding apk add logrotate. Anyway，I don't think it's a good way especially in distributed environments with a lot of node instances.

[localvar]

@jthann , for containers, the solution should be to output all logs to stdout/stderr by default instead of support log rotation directly, this has been discussed in #34 , and we will work on this.

[jthann]

@localvar I do agree k8s container should output all logs to stdout just as 12factor put it. We need this feature not because it is a best practice，but for history reason and compatibility. I've already solve this by using lumberjack integrated with uber-go/zap.