NodeJS面向服务架构（SOA）日志记录位置最佳实践咨询

各层级日志记录侧重点 #

控制器层 #

• 记录请求入口/出口信息：涵盖请求方法、URL、唯一请求ID、用户身份标识（如存在）、响应状态码、请求总耗时。作为用户请求的入口节点，这里的日志要能清晰标记请求的整体上下文，便于后续追踪完整请求链路。
• 捕获并记录请求参数合法性错误：比如参数缺失、格式不符等用户输入类问题，直接在控制器层完成记录，无需传递到下层服务。

服务层 #

• 记录业务逻辑关键节点：包括业务操作的启动/结束标记、核心状态变更（如订单创建→支付完成的状态流转）、业务规则判定结果。服务层是业务逻辑核心，这里的日志要能完整还原业务执行流程。
• 记录业务异常信息：像余额不足、库存短缺这类业务层面的错误，需在此层记录详细业务上下文，便于排查业务规则类问题。
• 记录跨服务调用细节：若存在服务间交互，需记录目标服务标识、调用参数、返回结果、调用耗时，以此追踪服务依赖链路。

数据访问层（DAL） #

• 记录数据库操作详情：包含SQL语句（注意脱敏敏感字段，如密码、手机号）、执行耗时、数据影响行数、数据库连接状态。若出现数据库连接失败、SQL执行报错等问题，需在此层详细记录异常信息。
• 避免冗余记录：无需重复服务层已记录的业务上下文，仅聚焦数据库相关的专属操作信息。

外部API封装层 #

• 记录外部API全链路信息：包括请求URL、方法、脱敏后的请求头与参数、响应状态码、关键响应内容、调用耗时。
• 重点记录外部API异常：如调用超时、返回错误码、连接失败等情况，需单独标记这类异常，便于区分内部问题与外部依赖故障。

通用最佳实践 #

• 统一结构化日志格式：采用JSON等结构化格式输出日志，固定包含请求ID、时间戳、日志级别、所属层级、核心内容、上下文元数据，方便后续日志分析工具解析。
• 强制敏感信息脱敏：所有层级的日志均需过滤密码、token、银行卡号等敏感数据，避免信息泄露。
• 合理划分日志级别：使用DEBUG、INFO、WARN、ERROR、FATAL等标准级别，控制器层用INFO记录请求流转，服务层用DEBUG记录细节、ERROR记录业务异常，数据访问层与外部API层根据场景选择对应级别。
• 实现全链路追踪：为每个请求生成唯一请求ID，所有层级的日志均携带该ID，确保能串联起整个请求的所有日志节点，快速定位问题。
• 避免重复日志：各层级仅记录自身职责范围内的信息，比如服务层已记录业务操作，数据访问层就无需重复记录相同业务内容，减少日志冗余。

内容的提问来源于stack exchange，提问作者erikkjer