日志分析与智能预测

今天已经回到南京，不过按照南京政府防疫的要求还需要3+11管理，前三天要居家观察，天天做核酸，不能聚集，因此这三天还需要居家办公。我这个人一直是工作和休息不大分得开的，有时候想到一个问题总想立即拉个电话会议，这是因为90年代创业时队伍规模很小，大家集体租房居住，沟通十分方便。只有到野外没有手机信号的地方徒步，才能彻底放下所有的事情，真正的放空几天。正是这个原因，我养成了每年出去走几天的习惯。 昨天返程的路上，我就立即切换为工作状态了，和几个合作伙伴在微信上沟通一些项目的事情，其中一个合作伙伴就提到了日志分析的问题。因此我想回归人间的第一篇文章就写写日志分析吧。 几年前我们开始做智能化故障预测的时候是两眼一抹黑，首先我们想到的就是和高校合作，因为高校对前沿技术的跟踪与研究是十分紧密的。当我们和高校的团队交流数据库故障的发现与预测时，他们首先提出的方法就是基于日志分析的故障感知与告警收敛。确实日志分析是一种系统故障可视化的十分重要的方法，当我们对某些IT基础设施的内部原理不是很清楚的时候，往往也能通过日志发现一些蛛丝马迹，从而定位问题。

几年前，一个大型电子招标系统出现故障，开始开发厂商想甩锅数据库，虽然当时参与分析的专家没有一个懂weblogic的，不过最后我们还是通过对weblogic的日志进行分析的时候，发现了一个疑点，通过这个疑点，最终十分精准的定位了问题。 所以说，当系统出现故障时候，日志分析是十分重要的手段。 日志分析的最大优势在于我们不需要深入了解某些IT基础设施的基本原理，就可以通过日志分析获得一些十分有价值的分析结论。 因此日志分析作为运维可视化的一个快速切入点是很不错的。 这也是目前国内的大多数做AIOPS的厂商，算法中最强的部分。

日志分析的原理十分朴素，日志文件由应用程序、操作系统、网络、数据库、中间件等IT实时生成的供运维人员发现和分析问题的事件记录。它们由一组日志消息组成，这些消息按出现的顺序排列并保存在文件等持久化设施之中以供运维人员分析。我在前些年也写过不少关于数据库故障分析的文章，其中也提出了要分析Oracle数据库的故障，一定要首先分析alert log，排除一些比较容易被发现的问题，从而降低分析的产能改变，虽短分析的时间。在数据库的故障分析中，日志分析的效果是十分好的，十次故障7、8次可能可以从日志分析中获得最终定位问题的方向。 不过虽然日志分析的效果不错，但是采用传统的人工分析的方法来作为常态化的监控手段是成本极大，效率不高的。我们的IT系统，运维部门给业务部门承诺的SLA往往都是99.99甚至是99.995,核心系统甚至可能要达到99.999。因此系统中绝大多数时间里是没有故障的。基于这个特点，人工分析只能用于故障发生后的定位，无法对故障进行预测，也正是这个特点，基于机器学习/深度学习的智能化算法才大行其道。因为基于日志的时序记录特征以及系统无故障时间比例较大的特点，就可以借助特征分析来自动发现异常，从而实现无监督学习或者半监督学习的算法。

日志分析的流程是比较成熟的，数据采集，汇总索引，搜索分析，监控报警，深度分析等流程环节在一些企业中都已经建立。

似乎从方法论上看，日志分析的流程和方法都相当成熟，应用起来应该比较容易。目前日志分析方面的平台与工具也相当多，很多企业也已经开展了近10年的日志分析工作，也取得了相当大的成果。不过对于日志分析的效果，业内也众说纷纭，有的企业说他们的效果很好，在运维中发挥了极大的作用；也有些企业说他们采购的日志分析平台就是个花架子，做做实验，写几篇论文还行，实战效果不佳。 为什么会这样呢？似乎在理论上来说，通过算法的调参，较为精准的把0.01%的异常通过日志中的异常记录找出来是可行的。但是实际应用中，特别是系统故障时，想要通过日志平台定位问题效果不佳呢？ 实际上我们有些时候希望通过日志平台来解决运维问题的出发点就存在缺陷，因为我们针对某个单一的IT基础设施的故障分析能力不足，才考虑使用日志分析这个相对容易的方法来解决对某些IT基础设施（比如数据库，中间件、云平台等相对复杂的IT基础设施）分析能力不足的问题。这种出发点决定了基于此思路构建的日志分析平台存在的局限性。对于问题相对突出、运维人员较为熟知的故障，其预警与分析效果还行，而对于较为复杂，运维人员没有见识过的问题，其能够发挥的效果就有限了。就像我听到某企业对他们的日志分析平台的评价是，我一眼可以看出来的问题，分析效果还行，我分析不出来的问题，它也发现不了。 实际上很多IT基础设施的日志十分复杂，类似的错误信息可能代表了多种不同的含义，而很多应用软件的日志输出又极不规范，不同研发人员输出日志的习惯也不同，这些都让日志分析变得更为复杂。

几年前，一个客户的1000多套数据库中出现最多的日志报警就是ORA-1555，他们刚开始的时候把这些问题都归结为SQL执行效率问题，抓出SQL，作为罪证发给研发人员去解决。不过后来出了几次故障，发现其实并不是研发部门的问题，有些是数据库BUG，有些是他们的数据库配置问题，有些是数据库出现了逻辑坏块导致。因此被研发部搞的灰头土脸，在CTO面前丢了几次脸。于是他们就问我，ORA-1555到底是怎么回事，怎么会这么复杂。我画了上面的这张思维导图给他，他看完才恍然大悟。原来同样的错误号码，内在的错误原因如此复杂。
正是因为隐含在某个错误信息后面的问题是十分复杂的，因此仅仅基于算法筛选还无法满足精准告警与定位的目标。我们还需要通过专家，对于复杂的错误信息构建知识图谱，并基于知识图谱进行更为精准的定位。 日志分析肯定是十分有效的故障定位于故障预警手段，不过和其他AIOPS方面的算法一样，完全基于数学方法的算法都具有一定的局限性，而专家分析的成本又太高，因此机器学习/深度学习算法+运维知识图谱才是更为有效的方法。