2023年7月17日发(作者：)

node统⼀操作⽇志_nodejs⽇志规范nodejs ⽇志规范⼀般前端开发同学，对⽇志其实不太敏感，毕竟前端⼤多数情况下，不太关⼼⽇志。即使有，也可能调⽤⼀些第三⽅的统计，⽐如百度统计或者别的等。在 (下⽂中简称node) 推进过程中，也发现我们平常打⽇志太随意，该打的⽇志没有打，打的⼀些关键⽇志缺少必要上下⽂信息，导致在线上定位问题的时候很困难。本⽂主要梳理了⽬前我们团队在nodejs开发中⽇志⽅⾯存在的问题，以及通过统⼀⽇志规范，希望达到什么样的效果。问题node⽇志不规范，打⽇志太随意没有良好的⽇志格式、约定的字段，在 ELK ⾥不能很好的解析&检索 (PS: ELK⽂章在路上)由于node对接的后端服务化，调⽤链不清晰，定位问题困难数据部门对node⽇志的使⽤，没有明确的记录。node修改了⽇志，导致统计数据异常⽬标规范⽇志打印字段&格式，便于 ELK 检索增强node上下游(nginx/后端)⽇志格式，加⼊惟⼀ requestId，⽅便微服务下定位问题统计应⽤运⾏情况，性能数据维护数据部门对node⽇志的使⽤情况实现⽅案⽇志类型参考⼀些⽇志的最佳实践，⽬前将node⽇志分为如下⼏种类型(scope)：desc: 系统启动、运⾏过程中，打的⽇志，表明系统的⼀些启动⽇志、启动参数等，也包含在 不能 捕获到http上下⽂的时候，打的⽇志stat: 系统性能统计⽇志，应⽤会定时收集⼀些性能信息，便于查询应⽤当前状态visit: 每个http请求相关的⽇志，会包含惟⼀的 requestId，定位该请求相关的所有⽇志biz: 业务数据相关⽇志，主要提供给数据统计使⽤⽇志级别只使⽤ FATAL、ERROR、WARN、INFO 和 DEBUG 等级。 FATAL - 导致程序退出的严重系统级错误，不可恢复，当错误发⽣时，系统管理员需要⽴即介⼊，⼀般应⽤代码 不不 使⽤。

ERROR - 运⾏时异常以及预期之外的错误，也需要⽴即处理，但紧急程度低于FATAL,当错误发⽣时，影响了程序的正确执⾏。需要注意的是这两种级别属于服务⾃⼰的错误，需要管理员介⼊， ⽤户输⼊出错不属于此分类⽤户输⼊出错不属于此分类，请求后端、读⽂件、数据库等超时、返回错误结构，属于ERROR

WARN - 预期之外的运⾏时状况，表⽰系统可能出现问题。对于那些⽬前还不是错误，然⽽不及时处理也会变成错误的情况，也可以记为WARN，如磁盘过低。

INFO - 有意义的事件信息，记录程序正常的运⾏状态，⽐如收到请求，成功执⾏。通过查看INFO,可以快速定位WARN，ERROR,FATAL。INFO不宜过多，通常情况下不超过 DEBUG 的10%。

DEBUG - 与程序运⾏时的流程相关的详细信息以及当前变量状态。⽇志格式/字段⽇志格式统⼀采⽤ JSONJSON ，便于 ELK 解析处理。⽇志中的各个字段的值，都应该尽量使⽤ 英⽂英⽂ ，不使⽤中⽂。⽇志具体字段，分为 基础数据 + 扩展数据。基础数据，是底层⽇志框架⾃带的，所有⽇志都会包含。扩展数据，不同类型的⽇志，包含不同的字段。⽇志基础数据⽬前使⽤的 node-bunyan ⽇志库，官⽅⽂档，基础字段包含如下：v: integer 。bunyan的⽇志版本号level: integer。⽇志级别对应的数字name: string。服务名hostname: string。主机名pid: integer。进程号time: string。UTCUTC 格式的⽇期msg: string。⽇志主体信息⽇志扩展数据下⾯定义的各个数据类型的扩展数据，不是不是 全部的字段，仅包含该⽇志类型下，必需的字段。这些必需的扩展字段，需要在 ELK 中建⽴索引，⽅便定位各种问题。1. desc类型⽇志，扩展字段：TODO2. stat类型⽇志，扩展字段：{ perf: {rss: xxxx, cpu: xxx} }3. visit类型⽇志，扩展字段：4. biz{ / 基础数据

v: 1, level: 20, / 扩展字段

// 标志⽇志类型 scope: "visit", //事件类型：在 visit 的⽇志类型下，还会细分不同的事件，⽐如 client-req、client-res、 普通trace、请求后端service-start, service-end, service-err等。 event: "trace", //客户端ID，追踪⽤户、设备会话。在web端，可以是长期的cookie；在APP端，可以是device-id等 rrdid: "", //本次请求的惟⼀ID，串联本次请求的所有相关⽇志 req_id: "some-uuid-for-request", //本次请求的⽤户ID uid: "", //本次请求的客户端相关数据，通过 打⽇志时，⾃动加上 d: { url: "/some/path?include-query", //客户端ip ip: "10.138.10.1", //客户端的 userAgent ua: "" }, //本次node请求的处理时间，毫秒 tm: 500, //该⽇志相关的上下⽂数据，尽量拼成⼀个字符串，放在 extra ⾥ extra: "", //ERROR 级别⽇志，最好包含error相关信息，⽐如请求后端相关参数等 err: { msg: "", stack: "" }, //调⽤后端服务相关参数和响应 service_req: { host: "", path: "", payload: "" }, service_res: { //http状态码 http_code: 200, //响应时间 tm: 100, //响应的body body: "", //异常信息 err: "" }}什么时候打⽇志开发者⽬前只关⼼ visit 类型的⽇志，即和某⼀次http请求相关联的⽇志。desc和stat类型的⽇志，统⼀由开发框架封装后实现，业务开发不⽤ 关⼼。下⾯讲的，都是针对 不⽤visit 类型的⽇志。⼀次http请求，会打出⼀系列相关联的⽇志。在node层，通常⼀次请求，会进⼀步转发给N个后端服务，然后对后端数据进⾏⼀些处理、合并等操作，最后渲染页⾯或是输出JSON。因此，⼀次请求相关的⽇志，⼤体分为以下⼏种 event：client-req: client请求到达node层，统⼀由框架打⽇志，开发 不不 关⼼service-start: node对某个后端服务发起请求，由通⽤请求库负责打⽇志，开发 不不 关⼼service-end: node请求某个后端服务结束，由通⽤请求库负责打⽇志，开发 不不 关⼼service-err: node请求后端服务异常，由通⽤请求库负责打⽇志，开发 不不 关⼼。调⽤后端服务异常，⽇志级别为 WARN，不是不是ERRORtrace: node中业务层打的⽇志，如果异常，能帮助定位本次请求相关问题client-res: 结束client的请求，打印本次请求的http code，本次请求处理时间等，由框架统⼀打，开发 不不 关⼼开发同学在打⽇志时，应该谨慎的选择级别，INFO(含)级别以上，都应该能对定位问题、具体业务统计需求有要求，才能使⽤。⼤部分情况下，可以使⽤ DEBUG 级别，线上 不会不会 开启DEBUG级别。具体⽅法调⽤针对打印 visit类型的⽇志，调⽤ (基于Koa的框架) 属性打⽇志，推荐参数都传递 JSON，具体⽅法如下：({msg: "", "extra": "a=1 b=2 c=value"});({msg: "xxx", "extra": "其他的额外字段"});({msg: "xxx", "extra": "额外上下⽂数据"});//ERROR级别⽇志，应该提供 Error 对象({msg: 'xxx', err: error, extra: ""});注意1，额外的参数，推荐存放在 extra 字段中，统⼀拼成 string；如果确实有必要单独出每个字段， 禁⽌禁⽌ 额外的参数占⽤上述通⽤字段名！！注意2，基础数据中的msg字段，禁⽌禁⽌ 包含具体的上下⽂数据，和该⽇志相关的上下⽂数据，应该拼成字符串，放在单独的 extra 字段中。⽐如，某个⽤户登录接⼝，希望统计调⽤次数，可以这样打印:({msg: "user login", "extra": 'mobile= code=xxxx k3=value3'});参考资料最佳⽇志实践（v2.0）Node 框架接⼊ ELK 实践总结⼤搜车NodeJS⽇志规范化与分析监控请⾃查！这些优秀⽇志实践准则，你做到了⼏点？⽇志最佳实践When to use the different log levelsJava ⽇志管理最佳实践关于⽇志打印的⼏点建议以及⾮最佳实践⽇志记录最佳实践