保证日志包含足够的信息,足够支持内部控制,定位故障,审计,合规要求
确保日志有效,可读,
打印日志肯定损耗性能,但是要将损耗降到最低
代码审查sonar应该提醒去掉sout
如果日志内容是对象,json等,打印日志是应该pattern加引号
es默认1000字段,遇到某子项目几千字段,日志平台不是大数据分析,
另tomcat等日志需要设置pattern,要不然乱七八糟,也会让es误会
1),可以用warn记录入参错误,
2),err只记录系统出错,内存溢出等无法挽回的异常,自定义的可挽回的异常应该用warn
3),不打印无意义的日志
4),不建议打印查询list,尤其没有分页的
5),保证对象有toString方法,避免输出hash值
6),不要在打印日志时造成异常
log.info(request.getId()); //request为null
7),建议在接口调用,mq消费,task,调度任务等入口地方打印日志,记录时间,入参出参,对排查问题,定位问题有帮助
但是对参数长度应该判断,或者设置豁免打印参数的方法,遇到大报文避免打印
8),不要打印===-----****等日志,这种调试日志应该在发版之前删除
9),单行日志长度不应该超过4KB,
for(Person p: personList){
log.info("the person info: {} ",JSON.toJsonString(p))
}
我遇到某子项目:开始时间,报文参数,结束+耗时,一个记录打印三条,每天1:00-5:00之间每小时打印400w条日志,每天啥事儿不做,已经干2000w+日志上去了
gateway默认线程数很少,等你打印io线程消耗性能,遇到上传文件+报文解密+打印日志的时候,并发能力下降到2位数
和第三方交互时,入参、出参可能是需要加密和解密,如果报文体积较大,明文和密文都打印没有意义,算法测试成功后,个人认为加解密成功的情况下打印明文,计算失败时异常中打印原文即可
建议logback+slf4j即可
可以sleuth+zipkin,也可以logback的mac,或者自己使用threadloacl实现
如果一个日志再root和几个logger里面都有,避免重复打印
可能导致量大的日志
反例:遇到一个傻叉redis的utils打印“redisson del shutdown”265w/天
而且这个日志也没有啥可读性,都是一串乱码
如shardingsphere-jdbc等,需要关闭日志
如无法关闭,可以设置独立的logger,和其他应用日志分开
mybatis,eureka心跳等日志建议分开打印,不要和业务日志混在一起
正例:log.error(“XXX”,e.getMessage(),e);
反例:log.error(“XXX”,e.getMessage());
反例:e.printStacjTrace();
反例:记录了异常,再抛出
注意actuator的权限管理
tomcat,ng日志需要设置pattern
应用日志需要规范字段
日志按用途划分,避免业务日志,框架日志,混合,且日志使用rolling进行分割
本bu采用filebeat采集日志,
可以排除含有某些字段的日志
对分行的日志需要合并,时间开头或者{ 开头的日志才是一行
目前es中为每个业务方向设置space,每个space可以定义生命周期。
默认2个月,其中qr方向因为日志较大,业务日志30天+全量日志2天。
一类项目集团要求半年,所以hx方向设置为半年。
姓名(中文),姓名(英文),email,手机,固话,银行卡号,家庭地址,
身份证,居住证,社保,医保,公积金,
军官证,警官证
车牌,车架,车辆识别码,行驶证,驾照
。。。
都是需要脱敏的
家庭地址可能正则出问题