今天我们看一个日志处理分析的问题（jvm操作）
首先说下需求为什么发生：
需求描述： 在我们进行文件分析的时候，如果文件很多，而这个时候我们的线程在分析的时候产生了大量的报错，由于需要定位问题 发生的原因，所以很难减少报错信息，就算减少了很多，对于大批量数据依然还是会导致报错信息过多，而这个错误我们无法预知，可能代码问题 、可能用户操作问题，可能数据问题；如果人工没有及时干预那么很快我们的日志将打满我们的内存；
📢这个时候有人可能会说，为啥不设置一下logging.file.totalSizeCap来限制大小，为啥不设置日志级别，为啥不用日志分析工具;下面听我慢慢道来；
为啥不设置日志级别：
其实我们都是是有日志级别的，但我们一般用的是info级别，改成error的话会丢失很多有用的平时非报错信息，对于我们日常系统维护不好，不满足业务场景；
设置日志文件总量
我们设置了，但是貌似没生效，可能是设置的过大又或者是云环境引入日志导致的，但这也不是我这里要考虑的（项目应该考虑的），
为什么不用日志分析处理工具
如果通过ELK这样的日志分析工具，会增加很多中间件处理，不满足不同平台部署的方便性；而且某些平台也不愿意用这些东西；也试过阿里云的SLS日志服务收集直接云服务配置，介绍下SLS，它会将我们多台机器下的日志进行一个收集的操作，然后我们通过SLS就可以检索到问题，可以快速定位；这又带来了这是阿里的服务，或收费或需要阿里人员的配合，也不方便；而且没有解决日志过多问题；
JVM来进行处理
那么剩下来的就只能通过JVM本身来进行处理；我们先在catch里面转换下异常信息变为一个字符串，
我们通过hutools工具转换下，（该方法可截取3000个异常字符），
然后对异常信息进行加密操作，加密方式自己觉得方便着来； 这里之所以加密，是为了防止异常信息不同的过多，去重的话检索会耗时，所以加密一下做key检索用，我们可以定义一个静态变量来存放好比public static Map<String, Err定义类> GLOBAL_MAP = new ConcurrentHashMap<>();（我这里用 Map<String, String>方便操作）；我们先看用例，这里我定义了三个异常，
好，下面我们加密处理；这里是通过MessageDigest来处理，该类已提供demo示例，我这里不过多说明，CV即可；网上用例也很多，
对于加密处理后的结果我们直接看效果；
我们可以看到最终输出的是三个不一样的一样，一样的全部都不输出了，在异常那里我们保留一个方法可作异常逻辑处理，我们可以将这些内容放入redis中，定期清理，这样可以省去因为不同JVM导致异常重复的情况，不过又得做一点处理，这里只提供思路，都可，再做一个接口显示就完成了简单的日志检索功能了；功能很简单，但想全还是要很慎重的，毕竟是批量分析；
网友评论