基于 log4j2 插件实现统一日志脱敏，性能远超正则替换

前言

经过了这两篇文章之后，我们对日志脱敏应该有了一定的理解。

但是实际项目中，我们遇到的情况往往更加复杂：

1）项目的 java bean 定义不规范，大量接口使用 map。

2）历史项目众多，改造成本巨大。

种种原因，导致使用注解的方式耗费大量的时间。但是一般给我们改造的时间是有限的。

那么，有没有一种方法可以统一对敏感信息进行脱敏处理呢？

答案是有的，我们可以基于 log4j2 实现自己的脱敏策略，统一实现日志的脱敏。

log4j2 Rewrite

我们可以基于 log4j2 RewritePolicy 统一使用脱敏策略。

本项目自 V1.2.0 添加对应支持，后续将提升对应的可拓展性。

说明：如果使用 slf4j 接口，实现为 log4j2 时也是支持的。

使用入门

maven 引入

引入核心脱敏包。

其他的一般项目中也有，如 log4j2 包：

log4j2.xml 配置

例子如下:

几个步骤：

1.

指定 package 为

2.

按照 log4j2 Rewrite 规范，指定重写策略为

3.

输出时，直接指定为对应的重写之后的结果

测试

正常的日志打印：

自动脱敏效果如下：

ps: 这里是为了演示各种效果，实际默认对应为 1,2,3,4 这几种策略。

log4j2 配置定制化

为了满足各种用户的场景，在 V1.2.1 引入了 SensitiveRewritePolicy 策略的可配置化。

默认配置

log4j2 配置中， 配置默认等价于

属性说明

SensitiveRewritePolicy 策略的属性说明。

其中 1-13 的内置策略说明如下：

不足之处

这里的策略自定义和 log4j2 的插件化比起来，确实算不上强大，但是可以满足 99% 的脱敏场景。

后续有时间考虑类似 log4j2 的 plugins 思想，实现更加灵活的自定义策略。

性能

正则的替换可能会导致 cpu 飙升等问题，替换的策略也有限制。

实现的底层不是基于正则的，性能要远高于正则，大概是 2 倍左右，符合企业级应用性能。

后续将添加对应的 benchmark。

小结

实际项目中，建议二者结合使用。

基于 log4j2 的方式统一处理非常方便，但是是性能和准确性要有一定的折中。

如果是新项目，建议使用注解的方式，通过日志标准规范开发，后续拓展性也更加灵活。