当我们在使用Flask时，如何记录日志

我们在开发基于Flask的Web应用时，往往容易忽略了对日志的使用，而在Flask的官方文档中，对日志这块的介绍也仅仅停留在如何与系统集成上。记录日志这个看似很简单的事情，在实际中很多人却不一定能做好，要么不知道何时进行日志记录，要么就是记录的日志然并卵。所以，今天就来说说记录日志这件小事。

说它是件小事，因为它的确不会影响你系统的正常流程，有没有它系统都能跑起来，也正因为这样，很多人便忽略了日志的处理，或者干脆都没有配置日志输出，整个系统没有任何日志输出（Nginx日志不算）。当然，如果是我们自己开发的一些小网站，大家用来练练手或着用户量不大，有没有日志都一样，但是对于一些大型的系统，它的用户是很多的，在任何一个环节都可能出问题，为了能够及时的定位问题和监控系统运行状态，正确合理的记录日志就非常非常重要了。一般情况下，我们需要关注的是三个方面的内容：

我们在这里主要是围绕第二个问题来展开，也是我们开发人员最直接接触的情况。

从Flask 0.3 版本开始，系统就已经帮我们预配置了一个logger，而这个logger的使用也是非常简单：

其中的app就是Flask的实例，而这个app.logger也就是一个标准的logging Logger，因此，我们在使用app.logger时可选择的输出级别与python logging中的定义是一致的。

ERROR：这个级别的日志意味着系统中发生了非常严重的问题，必须有人马上处理，比如数据库不可用了，系统的关键业务流程走不下去了等等。很多人在实际开发的时候，不会去区分问题的重要程度，只要有问题就error记录下来，其实这样是非常不负责任的，因为对于成熟的系统，都会有一套完整的报错机制，那这个错误信息什么时候需要发出来，很多都是依据单位时间内error日志的数量来确定的。因此如果我们不分轻重缓急，一律error对待，就会徒增报错的频率，久而久之，我们的救火队员对错误警报就不会那么在意，这个警报也就失去了原始的意义。

WARN：发生这个级别的问题时，处理过程可以继续，但必须要对这个问题给予额外的关注。假设我们现在有一个系统，希望用户每一个月更换一次密码，而到期后，如果用户没有更新密码我们还要让用户可以继续登录，这种情况下，我们在记录日志时就需要使用WARN级别了，也就是允许这种情况存在，但必须及时做跟踪检查。

INFO：这个级别的日志我们用的也是比较多，它一般的使用场景是重要的业务处理已经结束，我们通过这些INFO级别的日志信息，可以很快的了解应用正在做什么。我们以在12306上买火车票为例，对每一张票对应一个INFO信息描述“[who] booked ticket from [where] to [where]”。

DEBUG和TRACE：我们把这两个级别放在一起说，是应为这两个级别的日志是只限于开发人员使用的，用