一般前端开发同学,对日志其实不太敏感,毕竟前端大多数情况下,不太关心日志。即使有,也可能调用一些第三方的统计,比如百度统计或者别的等。在node . js(下文中简称节点)推进过程中,也发现我们平常打日志太随意,该打的日志没有打,打的一些关键日志缺少必要上下文信息,导致在线上定位问题的时候很困难。
本文主要梳理了目前我们团队在nodejs开发中日志方面存在的问题,以及通过统一日志规范,希望达到什么样的效果。
-
<李>节点日志不规范,打日志太随意李
<李>没有良好的日志格式,约定的字段,在麋鹿里不能很好的解析,检索(PS:麋鹿文章在路上)
<李>由于节点对接的后端服务化,调用链不清晰,定位问题困难李
<李>数据部门对节点日志的使用,没有明确的记录.node修改了日志,导致统计数据异常李
-
<李>规范日志打印字段和格式,便于麋鹿检索李
<李>增强节点上下游(nginx/后端)日志格式,加入惟一requestId,方便微服务下定位问题
<李>统计应用运行情况,性能数据李
<李>维护数据部门对节点日志的使用情况李
<强>日志类型
参考一些日志的最佳实践,目前将节点日志分为如下几种类型(范围):
-
<李> desc:系统启动,运行过程中,打的日志,表明系统的一些启动日志,启动参数等,也包含在不能捕获到http上下文的时候,打的日志李
<李>统计:系统性能统计日志,应用会定时收集一些性能信息,便于查询应用当前状态李
<李>访问:每个http请求相关的日志,会包含惟一的requestId,定位该请求相关的所有日志李
<李>商业:业务数据相关日志,主要提供给数据统计使用李
<强>日志级别
只使用致命的错误、警告、信息和调试等级。
-
<李>致命——导致程序退出的严重系统级错误,不可恢复,当错误发生时,系统管理员需要立即介入,一般应用代码不使用。
<李>错误——运行时异常以及预期之外的错误,也需要立即处理,但紧急程度低于致命的,当错误发生时,影响了程序的正确执行。需要注意的是这两种级别属于服务自己的错误,需要管理员介入,用户输入出错不属于此分类,请求后端,读文件,数据库等超时,返回错误结构,属于误差
<李>警告——预期之外的运行时状况,表示系统可能出现问题。对于那些目前还不是错误的,然而不及时处理也会变成错误的情况,也可以记为警告说,如磁盘过低。
<李>信息——有意义的事件信息,记录程序正常的运行状态,比如收到请求,成功执行。通过查看信息,可以快速定位警告,错误,FATAL.INFO不宜过多,通常情况下不超过调试的10%。
<李>调试,与程序运行时的流程相关的详细信息以及当前变量状态。
-
<李>日志格式统一采用JSON,便于麋鹿解析处理。
<李>日志中的各个字段的值,都应该尽量使用英文,不使用中文。
<李>日志具体字段,分为基础数据+扩展数据。基础数据,是底层日志框架自带的,所有日志都会包含。扩展数据,不同类型的日志,包含不同的字段。
目前使用的node-bunyan日志库,官方文档,基础字段包含如下:
-
<李> v:整数.bunyan的日志版本号
<李>水平:整数。日志级别对应的数字
<李>名称:字符串。服务名李
<李>主机名:字符串。主机名李
<李> pid:整数。进程号
<李>时间:string.UTC格式的日期
<李>味精:字符串。日志主体信息李
下面定义的各个数据类型的扩展数据,不是全部的字段,仅包含该日志类型下,必需的字段。这些必需的扩展字段,需要在麋鹿中建立索引,方便定位各种问题。
-
<李> desc类型日志,扩展字段:TODO李
<李>统计类型日志,扩展字段:{性能:{rss: xxxx, cpu: xxx}}
<李>访问类型日志,扩展字段:李
<李>商业李
