如果正确的打印日志
哲学
- 日志应该像代码一样易于阅读和理解
- 清楚你在记录什么
- 不要为了日志而记日志
日志级别
一个项目各个log级别的定义应该是清楚明确的，是每个开发人员所遵循的； 即使是TRACE或者DEBUG级别的日志，也应该有一定的规范，要保证除了开发人员自己以外， 包括测试人员和运维人员都可以方便地通过日志定位问题； 对于日志级别的分类，有以下参考： FATAL — 表示需要立即被处理的系统级错误。当该错误发生时，表示服务已经出现了 某种程度的不可用，系统管理员需要立即介入。这属于最严重的日志级别，因此该 日志级 别必须慎用，如果这种级别的日志经常出现，则该日志也失去了意义。 通常情况下，一个进程的生命周期中应该只记录一次FATAL级别的日志，即该进程遇到无 法恢复的错误而退出时。当然，如果某个系统的子系统遇到了不可恢复的错误，那该 子系统的调用方也可以记入FATAL级别日志，以便通过日志报警提醒系统管 理员修复； ERROR — 该级别的错误也需要马上被处理，但是紧急程度要低于FATAL级别。 当ERROR错误发生时，已经影响了用户的正常访问。从该意义上来说，实际上 ERROR错误和FATAL错误对用户的影响是相当的。FATAL相当于服务已经挂了， 而ERROR相当于好死不如赖活着，然而活着却无法提供正常的服务，只能不 断地打印ERROR日志。特别需要注意的是，ERROR和FATAL都属于服务器自己的 异常，是需要马上得到人工介入并处理的。而对于用户自己 操作不当， 如请求参数错误等等，是绝对不应该记为ERROR日志的； WARN — 该日志表示系统可能出现问题，也可能没有，这种情况如网络的波动等。 对于那些目前还不是错误，然而不及时处理也会变为错误的情况，也可以记为WARN日志， 例如一个存储系统的磁盘使用量超过阀值，或者系统中某个用户的存储配额快用完等等。 对于WARN级别的日志，虽然不需要系统管理员马上处理，也是需要 即使查看并处理的。 因此此种级别的日志也不应太多，能不打WARN级别的日志，就尽量不要打； INFO — 该种日志记录系统的正常运行状态，例如某个子系统的初始化，某个请求的成功执行等等。 通过查看INFO级别的日志，可以很快地对系统中出现的 WARN,ERROR,FATAL错误进行定位。 INFO日志不宜过多，通常情况下，INFO级别的日志应该不大于TRACE日志的10%； DEBUG or TRACE — 这两种日志具体的规范应该由项目组自己定义，该级别日志的 主要作用是对系统每一步的运行状态进行精确的记录。通过该种日志，可以查看 某一个操作每一步的执 行过程，可以准确定位是何种操作，何种参数，何种顺序导致了某种错误的发生。 可以保证在不重现错误的情况下，也可以通过DEBUG（或TRACE）级别的 日志对问题进行诊断。 需要注意的是，DEBUG日志也需要规范日志格式，应该保证除了记录日志的开发人员自己外， 其他的如运维，测试人员等也可以通过 DEBUG（或TRACE）日志来定位问题；
为什么要做日志
- 开发过程中帮组开发人员跟踪程序崩溃的原因(DEBUG)。（个人更喜欢喜欢用print和debug）
- 记录一些程序的运行记录(INFO)。
- 程序运行错误的上下文信息(ERROR)。