认识达内从这里开始

系统运行监控日志就好比是我们的汽车保险，虽然一般没什么用，但是真的出事的时候，又是查找问题和BUG最可靠的方法了。

所以，我们今天就一起来了解一下，在打印系统运行日志的时候应该如何操作才能更好的方便我们的工作。

为什么时候要打印日志，或者什么时候打印日志，在我看来是同一个问题，那就是打印日志的目的。不同的目的，决定了日志内容的格式，输出的频度，输出的目的地。那可能有哪些打印日志的原因?

(1)调试开发

目的是开发期调试程序使用，这种日志量比较大，且没有什么实质性的意义，只应该出现在开发期，而不应该在项目上线之后输出。如何控制这种类型的日志是否输出，后面也会详细讨论。

(2)用户行为日志

这种类型的日志，记录用户的操作行为，用于大数据分析，比如监控、风控、推荐等等。这种日志，一般是给其他团队分析使用，而且可能是多个团队，因此一般会有一定的格式要求，开发者应该按照这个格式来记录，便于其他团队的使用。当然，要记录哪些行为、操作，一般也是约定好的，因此，开发者主要是执行的角色。

(3)程序运行日志

记录程序的运行状况，特别是非预期的行为、异常情况，这种日志，主要是给开发、维护人员使用。什么时候记录，记录什么内容，完全取决于开发人员，开发者具有高度自主性。本文讨论的主要也是指这种类型的日志，因为作为一个服务端开发、运维人员，程序运行日志往往是解决线上问题的救命稻草。

(4)记录系统或者机器的状态

比如网络请求、系统CPU、内存、IO使用情况等等，这种日志主要是给运维人员使用，生成各种更直观的展现形式，在系统出问题的时候报警。

一条日志要包含哪些内容，我觉的应该包含when、where、how、what、who、context，具体含义会在下面一个小节介绍。

我们要记录日志，总是要在某个时机，比如用户的某个请求、某个网络调用、或者内部状态发生了改变。在后文中，统称为事件(event)，即日志内容是对某个事件的描述。

when，就是我们打印日志的时间(时间戳)，注意这里的时间指的是日志记录的事件的发生时间，而不是日志被最终输出的时间。比如如果日志的输出目标是文件，那么这里的when不是写入到文件的时间，因为往往有延迟。

首先，时间可以被解读(Interpretaion)成具体的、现实的日期，让我们可以知道事件发生时的时间环境，比如出问题的时候是不是有什么活动、结合系统日志分析当时服务器的网络、CPU、IO是怎么样。具体的时间点也可以帮助我们分析事件的发生是不是存在某种规律，比如是不是每天、每周、每月的固定时间点都会出问题。

其次，时间可以表示一个(一组)事件的持续时间(duration)。比如，可以监控处一段代码的执行时间，也可以记录一个网络请求的耗时。这个时间差也能给出我们很多信息，比如根据经验预判当时程序的运行状态，是否比较‘卡’。

最后，时间代表了事件发生的顺序(order)，我们将多个日志按照时间排序，这个顺序能帮助我们debug到底问题是怎么产生的，是按照什么样的时序。这对于多进程(多线程)、异步、分布式程序而言非常重要。虽然我们知道在分布式系统维护全局的时间(globalclock)是很复杂的一件事情，但我们使用NTP协议，基本上能解决大部分的问题。

where，就是指日志是在哪里的被记录的，本质上来说，是事件的产生地点。根据情况，可以具体到是哪个模块、哪个文件，甚至是哪一个函数、哪一行代码。实践告知，至少应该包含模块信息。

where的意义在于能够让自己或者其他程序员一眼就看出这条日志是在哪里产生的，这样就能大致定位问题处在哪里，而不用从日志内容全局grep代码。

howimportant，代表了事件的重要性，我们会打印很多各种类型的日志，但是不同的日志的重要性是不一样的。比如，调试日志是最不重要的，是不应该出现在线上项目的，但是程序运行报错日志却需要认真对待，因为代表程序已经出现了异常。即使是程序的报错日志，也有不同的紧急程度，一次网络请求超时跟子进程异常退出份量完全不一样。

因此，每一条日志都应该有loglevel，loglevel代表了日志的重要性、紧急程度。不同的语言、框架的level细分有一定的差异，但都会包括debug，info，warn，error，fatal(critical)。其重要程度从名字就可以看出。

当然，有时候，warn与error，或者error与fatal之间的界限不那么明显，这个需要在团队之间达成共识。在我们的线上项目，对于error、fatal级别的日志都会报警，如果出现了error日志，那么最迟需要第二天去处理，如果是fatal日志，即使是在大半夜，也得立刻起来分析、处理。

what是日志的主体内容，应该简明扼要的描述发生的什么事情。要求可以通过日志本身，而不是重新阅读产生日志的代码，来大致搞清楚发生了什么事情。

who代表了事件产生者的唯一标识(identity)，用于区分同样的事件。特别是在服务器端，都是大量用户、请求的并发，如果日志内容不包含唯一标识信息，那么这条日志就会淹没在茫茫大海中。

日志的唯一标识也能帮助我们检索、过滤，找出该唯一标识的最近一段时间的所有日志，再按照时间排序，就能还原日志主体的活动轨迹，比如一个用户在网站上的操作会发散到多个进程、服务。当通过用户名(用户的唯一标识)搜索日志时，就能还原该玩家的操作记录，这个在查线上问题的时候非常有效。

当然，这个唯一标识是很广泛的，需要根据具体情况决定，如果网络请求，可能更好的是requestid、sessionid;如果是系统日志，那么可能是进程、线程ID;如果是分布式集群，那么可能是副本的唯一id。

日志记录的事件发生的上下文环境直观重要，能告知事件是在什么样的情况发生的。当然，上面提到的when、where、who都属于上下文，这些都是固定的，通用的。而在本小节，context专指高度依赖于具体的日志内容的信息，这些信息，是用于定位问题的具体原因。

作者：xybaby

来源：博客园

【免责声明】：本内容转载于网络，转载目的在于传递最新信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。