我是一个新入行的菜鸟，现在在做java服务器，在这里记录下服务器框架的主要构成，有任何不准确与错误的地方，希望看到的人提出意见。非常感谢！
 
一、概述。
 
1.1日志系统介绍。
 
任何一个应用程序或者游戏的服务器日志系统都是必须的，日志系统的主要目的是：监视代码变量变化；记录服务器访问操作记录以及异常运行操作记录；进行部分统计分析工作；担当开发环境中调试器作用，输出代码调试信息。
 
1.2  日志系统的选择。
 
现在最流行的应该是logback，网上很多log4j应该替换为logback的帖子。但是项目一般都会用到很多的框架，很多框架的日志系统都是log4j，所以我们也必须在项目中加入log4j与slf4j。我们需要的jar包包括：logback.classic-1.1.1.jar、logback-core-1.1.1.jar、slf4j-api-1.7.6.jar。是简单介绍下logback的优点，当然大部分都是网上的观点摘抄。
 
更快的速度。某些执行速度据说快了10倍，而且内存占用也更小了。实现了SLF4j。logback-classics实现了SLF4j，可以非常容易的切换log4j。自动重载配置文件。配置文件修改后，能自动重新加载配置文件，扫描过程快速安全。堆栈树带有包版本。自动去除旧日志文件。当然还有很多其他的优缺点比较，这里只列举我比较关心的。
 
1.3  下载地址。
 
http://logback.qos.ch/download.html 可以去官方下载最新包，以及相关文档支持。
 
二、配置
 
贴一个测试的日志配置logback.xml
 
message.contains("dao")
 
ACCEPT
 
DENY
 
%date %-5level [%logger{0}] %thread - %msg%n
 
message.contains("dao")
 
ACCEPT
 
DENY
 
${log.base}.log
 
${log.base}_%d{yyyy-MM-dd}.log.zip
 
100MB
 
%date %-5level [%logger{0}] %thread - %msg%n
 
粘一个别的大神正在用的，具体设置根据项目自行编写。
 
2 
 
3
 
4 
 
5 
 
6 
 
7 %date [%thread] %-5level %logger{80} - %msg%n
 
8 
 
9 
 
10
 
11 
 
12 
 
13 class="ch.qos.logback.core.rolling.RollingFileAppender">
 
14 
 
15 DEBUG
 
16 ACCEPT
 
17 DENY 
 
18 
 
19 
 
20 D:/logs/debug.%d{yyyy-MM-dd}.log
 
21 30
 
22 
 
23 
 
24 %date [%thread] %-5level %logger{80} - %msg%n
 
25 
 
26 
 
27
 
28 
 
29 
 
30 class="ch.qos.logback.core.rolling.RollingFileAppender">
 
31 
 
32 ERROR
 
33 ACCEPT
 
34 DENY 
 
35 
 
36 
 
37 D:/logs/error.%d{yyyy-MM-dd}.log
 
38 30
 
39 
 
40 
 
41 %date [%thread] %-5level %logger{80} - %msg%n
 
42 
 
43 
 
44
 
45 
 
46 
 
47 class="ch.qos.logback.core.rolling.RollingFileAppender">
 
48 
 
49 
 
50 message.contains("str")
 
51 
 
52 ACCEPT
 
53 DENY
 
54 
 
55 
 
56 D:/logs/contains.%d{yyyy-MM-dd}.log
 
57 
 
58 30
 
59 
 
60 
 
61 %date [%thread] %-5level %logger{80} - %msg%n
 
62 
 
63 
 
64
 
65 
 
66 
 
67 
 
68 class="ch.qos.logback.core.db.DriverManagerConnectionSource">
 
69 com.mysql.jdbc.Driver
 
70 jdbc:mysql://host_name:3306/datebase_name
 
71 username
 
72 password
 
73 
 
74 
 
75
 
76 
 
77 
 
78 
 
79 
 
80 
 
81 
 
82 
 
83 
 
84 
 
85 
 
86 
 
87 
 
88 
 
89 
 
90 
 
91 
 
92 
 
93 
 
94 
 
95 
 
96 
 
97 
 
98 
 
99 
 
100 
 
101 
 
102 
 
103
 
104 
 
105 
 
106 
 
107 
 
108 
 
109 
 
110 
 
111
 
112 

 
在程序中打错误日志的主要目标是为更好地排查问题和解决问题提供重要线索和指导。但是在实际中打的错误日志内容和格式变化多样，错误提示上可能残缺不全、没有相关背景、不明其义，使得排查解决问题成为非常不方便或者耗时的操作。
 
而实际上，如果编程的时候稍加用心，就会减少排查问题的很多无用功。在阐述如何编写有效的错误日志之前，了解错误是怎么产生的， 非常重要。
 
错误是如何炼成的
 
对于当前系统来说， 错误的产生由三个地方引入：
 
1.上层系统引入的非法参数。对于非法参数引入的错误， 可以通过参数校验和前置条件校验来截获错误；
 
2.与下层系统交互产生的错误。与下层交互产生的错误， 有两种：
 
a.下层系统处理成功了，但是通信出错了， 这样会导致子系统之间的数据不一致；
 
对于这种情况，可以采用超时补偿机制，预先将任务记录下来，通过定时任务在后续将数据订正过来。
 
b.通信成功了，但是下层处理出错了。
 
对于这种情况， 需要与下层开发人员沟通， 协调子系统之间的交互；
 
需要根据下层返回的错误码和错误描述做适当的处理或给予合理的提示信息。
 
无论哪一种情况， 都要假设下层系统可靠性一般， 做好出错的设计考虑。
 
3.本层系统处理出错。
 
原因一：疏忽导致。疏忽是指程序员能力完全可避免此类错误但实际上没做到。比如将 && 敲成了 & ， == 敲成了 = ；边界错误， 复合逻辑判断错误等。疏忽要么是程序员注意力不够集中， 比如处于疲倦状态、加班通宵、边开会边写程序；要么是急着实现功能，没有顾及程序的健壮性等。
 
改进措施：使用代码静态分析工具，通过单元测试行覆盖可有效避免此类问题,或者Jenkins构建sona
 
原因二：错误与异常处理不够周全导致的。比如输入问题。计算两个数相加， 不仅要考虑计算溢出问题， 还要考虑输入非法的情形。对于前者，可能通过了解、犯错或经验就可以避免，而对于后者，则必须加以限定，以使之处于我们的智商能够控制的范围内，比如使用正则表达式过滤掉不合法的输入。对于正则表达式必须进行测试。对于不合法输入， 要给出尽可能详细、易懂、友好的提示信息、原因及建议方案。
 
改进措施：尽可能周全地考虑各种错误情形和异常处理。在实现主流程之后，增加一个步骤：仔细推敲可能的各种错误和异常，返回合理错误码和错误描述。每个接口或模块都有效处理好自己的错误和异常，可有效避免因场景交互复杂导致的bug。
 
原因三：逻辑耦合紧密导致。 由于业务逻辑耦合紧密， 随着软件产品一步步发展， 各种逻辑关系错综复杂， 难以看到全局状况，导致局部修改影响波及到全局范围，造成不可预知的问题。
 
改进措施：编写短函数和短方法，每个函数或方法最好不超过 50 行。 编写无状态函数和方法， 只读全局状态， 相同的前提条件总是会输出相同的结果， 不会依赖外部状态而变更自己的行为；定义合理的结构、 接口和逻辑段， 使接口之间的交互尽可能正交、低耦合；对于服务层， 尽可能提供简单、正交的接口；持续重构， 保持应用模块化和松耦合， 理清逻辑依赖关系。
 
对于有大量业务接口相互影响的情况， 必须整理各个业务接口的逻辑流程及相互依赖关系， 从整体上进行优化；对于有大量状态的实体， 也需要梳理相关的业务接口， 整理状态之间的转换关系。
 
原因四：算法不正确导致。
 
改进措施：首先将算法从应用中分离出来。 若算法有多种实现， 可以通过交叉校验的单元测试找出来， 比如排序操作；如果算法具有可逆性质， 可以通过可逆校验的单元测试找出来， 比如加密解密操作
 
原因五：相同类型的参数，传入顺序错误导致。比如，modifyFlow(int rx, int tx), 实际调用为 modifyFlow(tx,rx)
 
改进措施：尽可能使类型具体化。该用浮点数就用浮点数， 该用字符串就用字符串， 该用具体对象类型就用具体对象类型；相同类型的参数尽可能错开；如果上述都无法满足， 就必须通过接口测试来验证， 接口参数值务必是不同的。
 
原因六：空指针异常。空指针异常通常是对象没有正确初始化， 或者使用对象之前没有对对象是否非空做检测。
 
改进措施：对于配置对象， 检测其是否成功初始化；对于普通对象， 获取到实体对象使用之前， 检测是否非空。可以使用工具类
 
原因七：事务与并发错误。事务与并发结合在一起， 很容易产生非常难以定位的错误。
 
改进措施：对于程序中的并发操作， 涉及到共享变量及重要状态修改的， 要加 INFO 日志。
 
如果有更有效的做法，欢迎留言指出。
 
原因八：业务不熟悉导致的错误。在中大型系统， 部分业务逻辑和业务交互都比较复杂， 整个的业务逻辑可能存在于多个开发同学的大脑里， 每个人的认识都不是完整的。这很容易导致业务编码错误。
 
改进措施：通过多人讨论和沟通， 设计正确的业务用例， 根据业务用例来编写和实现业务逻辑；最终的业务逻辑和业务用例必须完整存档；在业务接口中注明该业务的前置条件、处理逻辑、后置校验和注意事项；当业务变化时， 需要同步更新业务注释；代码REVIEW。业务注释是业务接口的重要文档， 对业务理解起着重要的缓存作用。
 
原因九：设计问题导致的错误。比如同步串行方式会有性能、响应慢的问题， 而并发异步方式可以解决性能、响应慢的问题， 但会带来安全、正确性的隐患。异步方式会导致编程模型的改变， 新增异步消息推送和接收等新的问题。使用缓存能够提高性能， 但是又会存在缓存更新的问题。
 
改进措施：编写和仔细评审设计文档。设计文档必须阐述背景、需求、所满足的业务目标、要达到的业务性能指标、可能的影响、设计总体思路、详细方案、预见该方案的优缺点及可能的影响；通过测试和验收， 确保改设计方案确实满足业务目标和业务性能指标。
 
原因十：未知细节问题导致的错误。比如缓冲区溢出、 SQL 注入攻击。从功能上看是没有问题的， 但是从恶意使用上看， 是存在漏洞的。再比如， 选择 jackson 库做 JSON 字符串解析， 默认情况下， 当对象新增字段时会导致解析出错。必须在对象上加 @JsonIgnoreProperties(ignoreUnknown = true) 注解才能正确应对变化。如果选用其他 JSON 库就不一定有这个问题。
 
改进措施：一方面要通过经验积累， 另一方面， 考虑安全问题和例外情况， 选择成熟的经过严格测试的库。
 
如何编写更容易排查问题的错误日志
 
打错误日志的基本原则：
 
尽可能完整。每一条错误日志都完整描述了：什么场景下发生了什么错误， 什么原因(或者哪些可能原因)， 如何解决(或解决提示)；
 
尽可能具体。比如 NC 资源不足， 究竟具体指什么资源不足， 是否可以通过程序直接指明；通用错误，比如 VM NOT EXIST ， 要指明在什么场景下发生的，可能便于后续统计的工作。
 
尽可能直接。最理想的错误日志应该让人在第一直觉下能够知道是什么原因导致，该怎么去解决，而不是还要通过若干步骤去查找真正的原因。
 
将已有经验集成直接到系统中。所有已经解决过的问题及经验都要尽可能以友好的方式集成到系统中，给新进人员更好的提示，而不是埋藏在其他地方。
 
排版要整洁有序， 格式统一化规范化。密密麻麻、随笔式的日志看着就揪心， 相当不友好， 也不便于排查问题。
 
采用多个关键字唯一标识请求，突出显示关键字：时间、实体标识(比如vmname)、操作名称。
 
排查问题的基本步骤：
 
登录到应用服务器 -> 打开日志文件 -> 定位到错误日志位置 -> 根据错误日志的线索的指导去排查、确认问题和解决问题。
 
其中：
 
从登陆到打开日志文件。由于应用服务器有多台， 要逐一登录上去查看实在不方便。需要编写一个工具放在 AG 上直接在 AG 上查看所有服务器日志， 甚至直接筛选出所需要的错误日志。
 
定位错误日志位置。目前日志的排版密密麻麻，不易定位到错误日志。一般可以先采用"时间"来定位到错误日志的附近前面的地方， 然后使用 实体关键字 / 操作名称 组合来锁定错误日志地方。根据 requestId 定位错误日志虽然比较符合传统，但是要先找到 requestId , 并且不具有描述性。最好能直接根据时间/内容关键字来定位错误日志位置。
 
分析错误日志。错误日志的内容最好能够更加直接明了， 能够明确指明与当前要排查的问题特征是吻合的， 并且给出重要线索。
 
通常， 程序错误日志的问题就是日志内容是针对当前代码情境才能理解，看上去简洁， 但总是写的不全， 半英文格式；一旦离开代码情境， 就很难知道究竟说的是什么， 非要让人思考一下或者去看看代码才能明白日志说的是什么含义。这不是自己给自己罪受？拓展：细说 Java 主流日志工具库
 
比如：
 
if ((storageType == StorageType.dfs1 || storageType == StorageType.dfs2)                && (zone.hasStorageType(StorageType.io3) || zone.hasStorageType(StorageType.io4))) {// 进入dfs1 和dfs2 在io3 io4 存储。} else {      log.info("zone storage type not support, zone: " + zone.getZoneId() + ", storageType: "+ storageType.name());      throw new BizException(DeviceErrorCode.ZONE_STORAGE_TYPE_NOT_SUPPORT);}
 
zone 要支持什么 storage type 才是正确的? Do Not Let Me Think !
 
错误日志应该做到：即使离开代码情境，也能清晰地描述发生了什么。
 
此外，如果能够直接在错误日志中说明清楚原因， 在做巡检日志的时候也可以省些力气。从某种意义上来说， 错误日志也可以是一种非常有益的文档，记录着各种不合法的运行用例。
 
目前程序错误日志的内容可能存在如下问题：
 
1.错误日志没有指明错误参数和内容：
 
catch(Exception ex){      log.error("control ip insert failed", ex);      return new ResultSet(ControlIpErrorCode.ERROR_CONTROL_IP_INSERT_FAILURE);}
 
没有指明插入失败的 control ip. 如果加上 control ip 关键字， 更容易搜索和锁定错误。
 
类似的还有：
 
log.error("Get some errors when insert subnet and its IPs into database. Add subnet or IP failure.", e);
 
没有指明是哪个 subnet 的它下属的哪些 IP. 值得注意的是， 要指明这些要额外做一些事情， 可能会稍微影响性能。这时候需要权衡性能和可调试性。
 
解决方案：使用 String.format("Some msg to ErrorObj: %s", errobj) 方法指明错误参数及内容。
 
这通常要求对 DO 对象编写可读的 toString 方法。
 
2.错误场景不明确：
 
log.error("nc has exist, nc ip" + request.getIp());
 
在 createNc 中检测到 NC 已经存在报错。但是日志上没有指明错误场景， 让人猜测，为什么会报NC已存在错误。
 
可以改为
 
log.error("nc has exist when want to create nc, please check nc parameters. Given nc ip: " + request.getIp());log.error("[create nc] nc has exist, please check nc parameters. Given nc ip: " + request.getIp());
 
类似的还有：
 
log.error("not all vm destroyed, nc id " + request.getNcId());
 
改成
 
log.error("[delete nc] some vms [%s] in the nc are not destroyed. nc id: %s", vmNames, request.getNcId());
 
解决方案：错误消息加上 when 字句， 或者错误消息前加上 【接口名】, 指明错误场景，直接从错误日志就知道明白了。
 
一般能够知道 executor 的可以加上 【接口名】， service 加上 when 字句。
 
3.内容不明确, 或不明其义：
 
if(aliMonitorReporter == null) {        log.error("aliMonitorReporter is null!");} else {       aliMonitorReporter.attach(new ThreadPoolMonitor(namePrefix, asynTaskThreadPool.getThreadPoolExecutor()));}
 
改为：
 
log.error("aliMonitorReporter is null, probably not initialized properly, please check configuration in file xxx.");
 
类似的还有：
 
if (diskWbps == null && diskRbps == null && diskWiops == null    && diskRiops == null) {      log.error("none of attribute is specified for modifying");      throw new BizException(DeviceErrorCode.NO_ATTRIBUTE_FOR_MODIFY);}
 
改为
 
log.error("[modify disk attribute] None of [diskWbps,diskRbps,diskWiops,diskRiops] is specified for disk id:" + diskId);
 
解决方案：更清晰贴切地描述错误内容。
 
4.排查问题的引导内容不明确：
 
log.error("get gw group ip segment failed. zkPath: " + LockResource.getGwGroupIpSegmnetLockPath(request.getGwGroupId()));
 
zkPath ? 如何去排查这个问题？我该去找谁？到哪里去查找更具体的线索？
 
解决方案：加上相应的背景知识和引导排查措施。
 
5.错误内容不够具体细致：
 
if (!ncResourceService.isNcResourceEnough(ncResourceDO,    vmResourceCondition)) {      log.error("disk space is not enough at vm's nc, nc id:" + vmDO.getNcId());      throw new BizException(ResourceErrorCode.ERROR_RESOURCE_NOT_ENOUGH);}
 
究竟是什么资源不够？目前剩余多少？现在需要多少？值得注意的是， 要指明这些要额外做一些事情， 可能会稍微影响性能。这时候需要权衡性能和可调试性。
 
解决方案：通过改进程序或程序技巧， 尽可能揭示出具体的差异所在， 减少人工比对的操作。
 
6.半英文句式读起来不够清晰明白，需要思考来拼凑起完整的意思：
 
log.warn("cache status conflict, device id "+deviceDO.getId()+" db status "+deviceDO.getStatus() +", nc status "+ status);
 
改为:
 
log.warn(String.format("[query cache status] device cache status conflicts between regiondb and nc, status of device '%s' in regiondb is %s , but is %s in nc.", deviceDO.getId(), deviceDO.getStatus(), status));
 
解决方案：改为自然可读的英文句式。
 
总结起来， 错误日志格式可以为：
 
log.error("[接口名或操作名] [Some Error Msg] happens. [params] [Probably Because]. [Probably need to do].");log.error(String.format("[接口名或操作名] [Some Error Msg] happens. [%s]. [Probably Because]. [Probably need to do].", params));
 
或
 
log.error("[Some Error Msg] happens to 错误参数或内容 when [in some condition]. [Probably Because]. [Probably need to do].");log.error(String.format("[Some Error Msg] happens to %s when [in some condition]. [Probably Because]. [Probably need to do].", parameters));
 
[Probably Reason]. [Probably need to do]. 在某些情况下可以省略；在一些重要接口和场景下最好能说明一下。
 
每一条错误日志都是独立的，尽可能完整、具体、直接说明何种场景下发生了什么错误，由什么原因导致，要采用什么措施或步骤。
 
问题：
 
1.String.format 的性能会影响打日志吗？
 
一般来说， 错误日志应该是比较少的， 使用 String.format 的频度并不会太高，不会对应用和日志造成影响。
 
2.开发时间非常紧张时， 有时间去斟酌字句吗？
 
建立一个标准化的内容格式，将内容往格式套，可以节省斟酌字句的时间。
 
3.什么时候使用 info, warn , error ?
 
info 用于打印程序应该出现的正常状态信息， 便于追踪定位；
 
warn 表明系统出现轻微的不合理但不影响运行和使用；
 
error 表明出现了系统错误和异常，无法正常完成目标操作。
 
错误日志是排查问题的重要手段之一。当我们编程实现一项功能时， 通常会考虑可能发生的各种错误及相应原因：
 
要排查出相应的原因， 就需要一些关键描述来定位原因。
 
这就会形成三元组：
 
错误现象 -> 错误关键描述 -> 最终的错误原因。
 
需要针对每一种错误尽可能提供相应的错误关键描述，从而定位到相应的错误原因。
 
也就是说，编程的时候，要仔细思考， 哪些描述是非常有利于定位错误原因的， 尽可能将这些描述添加到错误日志中。
 

解决方案
 
程序启动添加 -XX:-OmitStackTraceInFastThrow
 
例如：
 
nohup java -jar xxx.jar -XX:-OmitStackTraceInFastThrow&
 
 
问题分析
 
环境：windows，jdk1.8
 
打开本地命令行cmd
 
>  java -XX:+PrintFlagsFinal -version
 
 
从这里看jdk1.8默认是启用OmitStackTraceInFastThrow的，那么是什么意思呢？
 
 
参考地址：https://www.jianshu.com/p/cc1bd35466cb
 
OmitStackTraceInFastThrow ：JVM对一些特定的异常类型做了Fast Throw优化，如果检测到在代码里某个位置连续多次抛出同一类型异常的话，C2会决定用Fast Throw方式来抛出异常，而异常Trace即详细的异常栈信息会被清空。这种异常抛出速度非常快，因为不需要在堆里分配内存，也不需要构造完整的异常栈信息。
 
 

  

 
作用
 
规范日志输出体系，在遇到生产问题时，日志可以充分描述系统的状态，能方便、快速定位问题。
 
各个日志文件记录的信息
 

 
image.png
 
注：
 
(1)[app]代表当前的应用标识，各个系统应该有统一的唯一标识码。
 
(2)应用日志([app].log)是系统持续输出日志文件，而[app].seq.log是被归档的文件；
 
大小
 
要求每输出日志文件大小建议设置在200M-300M之间，并可以通过修复配置文件按需调整。最好是在运行时可动态调整，包括级别、路径等
 
日志级别
 
日志具有几个级别，分别是INFO、DEBUG、ERROR、WARN、FATAL。
 
ERROR：系统可以继续运行，但最好要尽快修复的错误。这个级别输出较多，常常伴随Java异常，错误(Error)的环境不一定会造成系统的崩溃，系统可以继续服务接下来的请求。运行时错误信息，包括异常信息等。其中应当包含技术异常。技术异常包括外部接口失败、IO异常、数据库连接异常等；
 
WARN：系统可以正常运行，但需要引起注意的警告信息。这个级别预示较小的问题，由系统外部的因素造成的，比如用户输入了不符合条件的参数。如程序调用了一个即将作废的接口，接口的不当使用，运行状态不是期望的但仍可继续处理等；其中应当包含业务异常。业务异常标识业务中出现的异常信息，比如，用户余额不足、密码输入错误等
 
INFO：系统运行的主要关键时点的操作信息，一般用于记录业务日志。同时也应该有足够的信息以保证可以记录再现缺陷的路径。这个级别记录了系统日常运转中有意义的事件。有意义的事件信息，如程序启动，关闭事件，收到请求事件、统计信息、系统性能信息、接口报文输出等。
 
DEBUG：系统运行中的调试信息，便于开发人员进行错误分析和修正，一般用于程序日志，关心程序操作(细粒度)，不太关心业务操作(粗粒度)。系统出现问题时，必须抛出异常，在处理异常时记录日志，且日志级别必须是前三个级别Fatal、Error、Warn中的一种；
 
日志输出
 
1.应用中不可直接使用其他日志输出，应该使用系统同一的日志输出API。
 
import com.leimingtech.logging.MonitorLogger;?
 
import com.leimingtech.logging.MonitorLoggerFactory;
 
private static MonitorLogger mlogger = MonitorLoggerFactory.getMonitorLogger(AftersaleApplyServiceImpl.class);
 
mlogger.info(AftersaleStatusCode.SERVICE_AFTERSALE_APPLY_SAVE_RETURN_SUCCESS_CODE,AftersaleStatusCode.SERVICE_AFTERSALE_APPLY_SAVE_RETURN_SUCCESS_MESSAGE, logMap);
 
2.对于 trace/debug/级别的日志输出，必须进行日志级别的开关判断。
 
说明：虽然在 debug(参数)的方法体内第一行代码 isDisabled(Level.DEBUG_INT)为真时(Slf4j 的常见实现Log4j 和 Logback)，就直接 return，但是参数可能会进行字符串拼接运算。此外，如果debug(getName())这种参数内有 getName()方法调用，无谓浪费方法调用的开销。
 
正例：// 如果判断为真，那么可以输出trace 和debug 级别的日志
 
if (logger.isDebugEnabled()) {
 
logger.debug("Current ID is: {} and name is: {}", id, getName());
 
}
 
3.异常信息应该包括两类信息：案发现场信息和异常堆栈信息。如果不处理，那么通过关键字 throws 往上抛出。
 
4.谨慎地记录日志。生产环境禁止输出 debug 日志；有选择地输出 info 日志。
 
如果使用 warn 来记录刚上线时的业务行为信息，一定要注意日志输出量的问题，避免把服务器磁盘撑爆，并记得及时 删除这些观察日志。
 
说明：大量地输出无效日志，不利于系统性能提升，也不利于快速定位错误点。
 
记录日志时请思考：这些日志真的有人看吗？看到这条日志你能做什么？能不能给问题排查带来好处？
 
5.业务关键环节必须打印日志。
 
6.外部接口调用必须打印日志，并统计接口调用耗时，以便统计趋势图。
 
7.error级别以上的日志，必须记录关键业务信息，如方法的入参，错误发生时的变 量现场，以便回溯追踪问题。
 
8.禁止打印密码等敏感信息。
 
9.可以使用 warn 日志级别来记录用户输入参数错误的情况，避免用户投诉无所适从。如非必要请不要在此场景打出 error 级别，避免频繁报警。
 
说明：注意日志输出的级别，error 级别只记录系统逻辑出错、异常或者重要的错误信息。
 
10.项目中禁止出现System.out.println()打印日志，统一使用日志码方式进行打印日志打印异常日志参数时禁止使用e.printStackTrace()。
 
11.打印日志的代码任何情况下都不允许失败，一定要确保不会因为Log语句的问题而抛出异常造成中断。
 
12.循环体内尽量不打印日志。
 
13.service层在对应的client模块下创建statuscode包，下面创建对应的code码声明文件，controller层在controller包同级目录下创建对应的stauscode包
 
14.日志状态码类统一继承ServcieStatusCode.class 。
 
public static final IndexSyncServiceCode INDEX_SYNC_ERROR = new IndexSyncServiceCode("500101", "商品索引同步失败", new Object[0]);?
 
public static final IndexSyncServiceCode CREATE_INDEX_ERROR = new IndexSyncServiceCode("500102", "创建商品索引失败", new Object[0]);?
 
public static final IndexSyncServiceCode CREATE_DELETE_INDEX_ERROR = new IndexSyncServiceCode("500103", "删除索引失败", new Object[0]);
 
15.状态码定义长度必须是6位，2开头的为成功，4开头的为客户端错误，5开头的为服务端错误，第4个字符应该是非0。
 
16.API入参打印统一使用@LogContext注解方式。
 
17.捕获已知异常时需要打印，在打印的日志信息中声明创建的logMap需要加上可供排查的重要参数保留案发现场。