Logging improvements about edgex-go

[drasko]

I would opt for JSON structured logs that can be easily parsed by a machine. this is why in export services we used Uber Zap: https://github.com/uber-go/zap

[iotgopher]

In addition to zap, this is a good package to rotate logs https://godoc.org/gopkg.in/natefinch/lumberjack.v2

[yanghua]

hi all,
It seems the project has two log formats when I run multiple microservices. I am writing the scheduler microservice. The JSON format looks good. But who can tell me which one I should choose?

[yanghua]

Hi all,
If no one can give a suggestion, I will agree with @drasko and @RTmaster to replace logger.LoggingClient with uber's zap in my #57 issue. I find the logger.LoggingClient can not print the real code line and define log output level like log4j.

[tsconn23]

@yanghua You need to be sure your logging solution is behind an interface. Properly speaking, logger.loggingClient IS an interface and it is used by all of the core services. You could potentially extend the loggingClient factory to instantiate your new type of logger similar to what has been done for the DBClient.

[yanghua]

@tsconn23 I know LoggingClient client is a interface. But I think the system/framework kernal should provide a unified (a project just need one format) and extendible (could have multiple implementations, but should not let upper modules implement itself, they just need to use the abstract API) log framework. The unified and controllable log format would bring many advantages: collect, parse, analyze and so on.

[drasko]

Status?

[drasko]

If no objections, I will close this one due too inactivity.

[drasko]

Closed due to inactivity.