日志规范

1. 日志的类别

1.1 系统执行日志（log文件）

此类日志，主要为代码执行时的日志打印，每个启动的服务实例都会记录程序的运行日志，主要用于问题排查。

开发、测试环境可放开DEBUG级别日志的输出，生产环境必须关闭DEBUG，设置INFO级别以上打印输出

1.2 系统操作日志（operator_log表存储操作日志）

此类日志，主要为系统功能的操作日志，需记录操作人，后端调用记录操作人为“系统”。

此类日志设计，需考虑记录功能模块，手动或者自动（系统），保持日志功能查询的灵活性。

同时，此类日志的文本，需产品提供对应的文本。

1.3 补偿日志（消息消费、第三方接口补偿重试记录日志）

此类日志，针对MQ消费重试补偿，幂等校验，以及第三方支付、厂商、开放平台接口的调用补偿，记录等场景。

此类日志设计，需考虑记录重试次数，执行结果，执行入参，对应业务，数据类型等。

1.4 代码执行日志（第三方对接或特殊场景下例如硬件代码执行关联业务的日志或者服务关键点操作的接口调用日志）

此类日志，主要为特殊场景下的接口调用记录，例如：三方支付调用数据记录，用户操作的源数据。

此类日志设计，也需考虑调用方，调用时间，数据状态，调用参数等。

此类日志的作用，主要作用于记录留档，避免扯皮，有迹可循，有据可依。

2.日志的级别

FATAL

FATAL级别日志，代表系统崩溃。理论上，系统不允许FATAL级别的日志。

ERROR

ERROR级别日志，代表系统错误。主要记录系统错误的日志，包含业务校验错误，代码执行错误，阻塞功能流程的故障。记录时，需记录错误场景，错误原因，故障时刻的源数据，入参，以及业务场景的关键数据。

例如：下单失败时，日志需体现出失败的原因，订单号、酒店编码，如涉及到校验场景，例如产品校验，则需加上产品编码id等。方便快速错误原因，定位代码。

WARN

WARN级别日志，代表系统警告。一般使用在不阻塞功能主流程，但出现了代码执行错误异常或者校验异常的场景。

例如：下单成功，推送系统通知。推送系统通知如果异常，不应影响下单成功。此处应打印WARN级别的警告日志。方便后续追溯统计，完善系统的健壮性。

INFO

INFO级别日志，代表系统正常执行。主要使用在功能的关键步骤处，记录场景、入参、关键数据等。

例如：下单过程的每个关键流程步骤，应打印INFO日志。出现问题时，方便配合WARN、ERROR日志，反向追溯用户行为和上下文数据，定位问题。

DEBUG

DEBUG级别日志，代表系统调试日志。主要为开发测试过程中，打印更加详细的数据日志，以及第三方框架组件的代码执行日志，打印时，应打印出系统运行时的详细数据。

注：线上出现不紧急故障时，可通过指定方式动态调整日志级别，配合排查线上问题，此操作非常敏感，排查问题后，必须关闭DEBUG，恢复INFO级别。

3.日志打印规范

注：上述日志类别除1.1外，其他需要尤其注意的是设计方案。此处不针对那几类进行详细说明。

日志打印规范，要求对应上述1.1类别的系统执行日志。

示例：

 

 

说明：

log.warn记录为WARN级别的执行日志，示例中打印WARN级别日志的原因：自动夜审接口调用，第一步关键参数校验失败，但不影响主题业务流程，可能是上游接口传参异常，所以打印WARN级别。

log.info记录为INFO级别的执行日志，示例中打印INFO级别日志的原因：打印点为系统执行的关键步骤，步骤前后打印INFO，方便排查定位系统执行是否正常。出现异常时，方便辅助排查问题。

log.error记录为ERROR级别的执行错误日志，示例中带引ERROR级别日志的原因:夜审执行异常，可能是代码BUG，也可能是其他系统原因导致。夜审未正常执行，记录错误点及参数，方便定位排查问题。

注：上述示例中的日志打印，场景为执行自动夜审，关键参数为执行哪家酒店的夜审，所以每条日志的打印，记录场景的同时，需填充对应的酒店编码。