Logs in the backend system are very important, and those who have done high concurrency services will agree with this. Debugging is not very useful. For such projects, I am also used to this development method for two reasons:
1. debug can only be used in the development environment. It will not work in the production environment. 2. In parallel computing, debugging may fail to discover potential problems. With the previous node. JS experience, giving up debug is not as terrible as we think, as long as our program design is reasonable, the structure is clear, the log is complete, after seeing the exception information, we can quickly locate the problem. Log4j is used for Java. when using the net program, log4net is used as the node. when Javascript is used, log4js .... the above modules are all good, so log4go is a natural choice for the go project. In other words, this log4go is not perfect, and it has not been maintained for two years. The name is so good. The most serious issue is that logs may not be flushed to the disk when the program exits:
1 func main(){2 log.Debug("....")3 defer log.Close()4 }
After the program execution is no log, this problem has not been resolved for two years, see: https://code.google.com/p/log4go/issues/detail? Id = 8 when I use open-source projects, I pay more attention to activity. I wanted to write a module to solve the problem. Later I found seelog and tried it. It was good, the recommended configurations and habits are also consistent with those of log4x. Seelog Source Code address: https://github.com/cihub/seelog seelog support to output logs in the console custom different colors, but the use of ANSI color, in Windows cmd display garbled, solution is to install a plug-in: http://adoxa.altervista.org/ansicon/after decompression, enter :ansicon.exe-I
Log processing under golang