正常项目里面使用log4j2 logback 来打印日志
最近查看日志平台，发现项目里面配置文件都是互相抄的，尤其是pattern会抄错。
把logback的语法抄到log4j2里面去，虽然主要内容都在，但是还是挺别扭的
{
"Level":"%level",
"Trece":"%X{X-B3-TraceId:-}",
"Class":"%logger{40}",
"Message":"%message",
"Stack_trace":"%exception{10}"
}
| 语法 | log4j2 | logback |
|---|
| 日期 | %d{格式/关键字}{时区} | %date、%d |
| 级别 | %level | |
| thread | %t或%thread | |
| 类名 | %c{参数}或%logger{参数}、%C{参数}或%class{参数} | c {length }、lo {length }、logger {length } |
| 方法名 | %M或%method | M / method |
| 行号 | %L | |
| %l 输出完整的错误位置，如com.future.ourfuture.test.test.App.tt(App.java:13) | |
| msg | %m或%msg或%message | m / msg / message |
| 换行 | %n | |
log4j2的对齐
| 格式 | 是否左对齐 | 最小宽度 | 最大宽度 | 说明 |
|---|
| %20 | 右对齐 | 20 | 无 | 右对齐，不足20个字符则在信息前面用空格补足，超过20个字符则保留原信息 |
| %-20 | 左对齐 | 20 | 无 | 左对齐，不足20个字符则在信息后面用空格补足，超过20个字符则保留原信息 |
| %.30 | 不对齐 | 无 | 30 | 如果信息超过30个字符，则只保留最后30个字符 |
| %20.30 | 右对齐 | 20 | 30 | 右对齐，不足20个字符则在信息前面用空格补足，超过30个字符则只保留最后30个字符 |
| %-20.30 | 左对齐 | 20 | 30 | 左对齐，不足20个字符则在信息后面用空格补足，超过30个字符则只保留最后30个字 |
logback的对齐
| 格式 | 日志内容 | 结果 |
|---|
| [%20.20logger] | main.Name | [ main.Name] |
| [%-20.20logger] | main.Name | [main.Name ] |
| [%10.10logger] | main.foo.foo.bar.Name | [o.bar.Name] |
| [%10.-10logger] | main.foo.foo.bar.Name | [main.foo.f] |
- 日志打印是一个耗费io的行为，所以尽量避免打印超长的内容
- 不要把文件转成base64，然后aop打印入参日志
还有人喜欢在网关进行报文的加解密，然后其他人把文件的base64混进来了，然后再打印解密前后的参数,想想一个5M的照片，打印了2次，还解密了一次，内存，cpu，io都被消耗完了。我遇到一个项目账单日的时候总是容器判断gateway死了，重新拉起，就是大量的thread在等待，堵死了健康检查
- mybatis，redis，mq，eureka心跳等jar包的日志，可以和交易日志分开，不要都混到es里面，实在太多了
- 日志一般进过filebeat，一些字段可以再filebeat里面添加和过滤
- 需要对字段进行约定，tomcat的cantia.out、ng的日志，需要约定格式，否则就不要混在一起
- 格式建议要么时间开头，要么json结构
- 也可以patern里面自己组个json结构，这样大家都方便
- 最好搞个traceid，来追踪日志；可以加一个日志的长度的字段