日志深度分析

日志深度分析

做运维的，难免和各种日志打交道，如何充分的利用日志去提升我们的运维水平是每个组织的运维人员都十分关心的，这些年针对日志分析的系统与算法层出不穷。前些年银行扎堆的上日志综合分析系统，大多数是使用splunk做采集，ELK做全文检索，再配合Mongodb存储部分半结构化的数据，构建的一套对日志可进行集中管理，集中分析的系统。这些系统在某些领域可以发挥很好的作用，其中最重大的提升是把日志采集上来了，集中起来了，管理起来了，用起来了。不过在智能化、深度化应用方面，恐怕还不够。特别是遇到了数据库这样复杂的对象，传统的日志分析手段就完全不够用了。

记得2018年的时候，和一个IT运维部门的负责人聊起日志分析来，他给我介绍了他们的日志报警系统面临的困境，他们运维着十多万台服务器，1000多个数据库，每天产生的各种日志报警是以万计的，而运维数据库的DBA只有十来个人。以前日志报警发短信，很多DBA中午时候手机就被短信震得没电了。后来没办法，把短信转发到微信群里，这个群整天都在刷屏，于是乎对报警做了分类，一些重要的报警发到一个群里，不重要的发到另外一个群里。即使这样处理，每天的报警还是多的看不过来。

正在这时候，他的微信群收到了一条ORA-1555的报警信息，他对我说，你看，又一条没用的报警信息。我看了一眼，告诉他，这条报警是不能忽略的。当时他很感意外，ORA-1555不是应用的问题，我们可以不管的吗？

实际上，数据库的日志报错是十分复杂的，可能虽然错误号都是ORA-1555，但是存在不同的报错原因。大体来说ORA-1555报错的主要原因有以下几个：

其中有些情况不是简单的应用问题，而可能是索引有坏块或者UNDO存在问题，这种情况都是需要DBA立即处理的，否则这些语句无论执行多少遍，都是不会成功的。

从上面这个例子，大家可能已经可以看出，日志分析绝对不是简单的文字匹配的问题了，这里面涉及到很多专业的分析，这些分析，使用目前的机器学习、深度学习的算法，都是无法解决的。

做日志深度分析，绝对不是靠算法就能够解决的问题，必须依靠专家与技术团队深入的梳理。比如说ORA-603这个简单的报警，其可能情况十分复杂：

其中有些和系统资源不足有关，有些和操作系统参数设置不合理有关，有些和网络丢包有关，有些和BUG有关。仅仅依靠机器学习和简单的全文检索是无法真正发挥作用的。

在这种复杂的运维场景下，要做好日志分析，必须依靠专业团队的运维经验与运维知识梳理，才能真正的实现精准定位。不过仅仅有这些知识的梳理还是不够的，还需要把这些知识变成自动化的工具：

当系统出现各种报错的时候，这些知识点工具会自动进行分析，并将诊断分析的结论记录下来。运维人员可以十分直观的发现运维的系统中各种报错的情况，以及产生这些报警的原因：

通过查看诊断报告，我们可以获得如何处置这些报警的方法：