只有在程序出问题以后才会知道打一个好的日志有多么重要。

1. 日志是什么？

日志，维基百科的定义是记录服务器等电脑设备或软件的运作。

日志文件提供精确的系统记录，根据日志最终定位到错误详情和根源。日志的特点是，它描述一些离散的（不连续的）事件。

2. 日志有什么用？

1). 打印调试：即可以用日志记录变量或记录一段逻辑。记录程序运行的流程，即程序运行了那些代码，方便排查逻辑问题。

2). 问题定位：程序出异常或者出谷中时快速定位问题，方便后期解决问题。因为线上无法debug，在测试环境模拟一套生产环境，费时费力。所以依靠日志记录的信息定位问题，这点非常重要。

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

4). 根因分析（甩锅必备）：即在关键地方记录日志。方便在和各个终端定位问题时，可以定位到到底是谁的问题

3. 什么时候记录日志？

1). 系统初始化：系统或服务初始化的启动参数。

2). 编程语言提示异常：各种语言的异常捕捉机制

3). 业务流程预期不符：如外部传参不正确，传入数据不在合理范围之内等等。

4. 日志的类型

日志分类：stats统计日志、monitor诊断日志、vist访问日志。

1). stats统计日志：

用户访问统计：用户ip、上传下载的数据量，请求耗时等。

计费日志：用户使用的网络资源或磁盘占用，格式比较严格。

2). monitor诊断日志：

• 请求入口和出口。

• 外部服务调用和返回。

• 资源消耗操作：如读写文件等。

• 容错行为： 如云硬盘的副本修复操作。

• 程序异常：如数据库无法连接。

• 后台操作：定期执行删除的线程。

• 启动、关闭、配置加载。

3). 访问日志：

• 记录用户的管理和操作。

5.日志文件的规范

• 单个日志文件大小要控制。
• 日志要定期清理

6.日志等级一定要规范

1). debug调试信息

在开发和调试的时候使用，尽可能的消息，正式环境不打印。包括参数信息、调试细节、返回值信息等等。

2). info用来收集关注的信息

info日志要简洁易懂

info级别主要记录系统的关键信息，旨在保留系统正常工作期间关键运行指标。一般将初始化系统配置、业务状态变化、业务流程核心处理记录。

3. warn警告信息

主要输出警告性质的日志，这些内容是可以预知而且有规划的，即使出现程序也能正常处理。warn级别属于可以预见的错误，需要尽早处理。

4). error错误信息

• 主要针对一些不可预知的错误信息。

• error日志内容一定要详实。

• error日志一定是全局统一收集的。

• 避免在每个类中收集到处都是try: exception。

7.日志的规范

1). if..else。

if..else判断是否正确的时候需要在else加入warn日志

2). 不打印无意义的日志。

日志里边要带有业务信息，否则意义不大。

#错误
logger.Error("Consume message faild!!!")
#正确
logger.Error=("Consume message faild, msgId{}".format(id))

3). 不推荐使用字符串拼接，建议使用占位符。

4). 循环体内不要打印Info日志。

5). 打印日志打码任何情况下都不允许发生异常。

6). 日志文件至少保存15天，因为有些异常具备以“周”为频次出现的特点。

7). 日志命名。

日志命名方式为appName-logType-logName.log.
appName：项目名称，如dwSpider, dwApi。
logType：日志类别。推荐有三个类型，stats:统计日志、monitor:诊断日志、vist:访问日志。
logName：日志描述，可以为爬虫名称或者具体的日志描述。
如：dwSpider-monitor-qichachaBaseUpdate.log

8.不多不少的日志

说明：大量地输出无效日志，不利于系统性能提升，也不利于快速定位错误点。记录日志时请思考：这些日志真的有人看吗？看到这条日志你能做什么？能不能给问题排查带来好处？

1). 无用日志常见情况：

• 能够放在一条日志中的东西放在多条日志中输出。
• 预期会发生且能够正常处理的异常，打印一堆无用的堆栈。
• 为了开发调试方便而加入的“临时”日志。

2).日志过少的情况有：

• 请求出错时不能通过日志直接定位问题，需要添加临时日志并重新请求才能定位问题。
• 无法确定服务中的后台任务是否按照期望执行。
• 无法确定服务的内存数据结构的状态。
• 无法确定服务的异常处理逻辑（如重试）是否正常执行。
• 无法确定服务启动时配置是否正确加载。
• 等

3). 常见的会遗漏的日志：

• 系统的配置参数：系统在启动过程中通常会首先读启动参数，可以在系统启动后将这些参数输出到日志中，方便确认系统是否安装期望的参数启动。
• 后台定期执行的任务：如定期更新缓存的任务，可以记录任务开始时间，任务结束时间，更新了多少缓存配置等等，这样可以掌握定期执行任务的状态。
• 异常处理逻辑：失败重试的日志也需要记录下来。
• 日志中需要记录关键参数：出错时间和出错原因等。

9.不断优化日志

• 日志不是一遍就能写好的，需要结合实际使用、问题的定位不断地额优化。
• 如果定位问题时间过长则说明需要优化。
• 需要思考是否可以通过优化日志来提前判断该问题是否可能发生。
• 定义好团队的日志规范，保证每个开发记录的日志格式统一。
• 定期对代码日志进行review。

10.好的日志的特点

• 能够快速的定位问题。
• 从日志就能了解问题的原因。.
• 了解线上系统的运行状态。
• 发现系统的瓶颈
• 不能影响系统的正常运行。