今天为了冲刺社区版发布，大家加班联调。坐到办公室的电脑前面还是习惯写上一点东西，最近事务性的事情比较多，具体的技术谈的不多。虽然今天是周末，还是写点技术性的东西吧，今天能把本文看完的，那一定是技术粉了。前几天和一个做AIOPS的朋友交流，提到日志分析与告警的问题，他们在金融行业使用日志智能分析，通过对业务日志，各种基础设施日志的建模分析，帮助用户建立了一个十分优秀的故障预警平台，使用效果很好。我以前也研究过基于日志分析的智能化预警，在一个比较复杂的系统环境中，一旦某个业务出现问题的时候，运维人员往往是一头雾水，不知道问题出现在哪个环节，这种情况在金融行业十分常见。十多年前我就遇到过类似的事情，当时一家银行因为核心交易系统故障，导致2小时核心业务全部失效。事后分析问题的时候，几十个软硬件厂商坐在一起相互甩锅，几个小时都没讨论出啥有价值的信息出来。而基于异常检测算法的日志智能分析可以从纷繁的数据中根据模型，大致定位到问题的“根因”上。这里的根因打了一个引号，这是因为，日志智能分析大致能够定位到出问题的IT基础设施或者服务模块，但是并不能直接定位到导致该IT基础设施或者服务模块故障的根因。虽然如此，这种能力已经是企业用户十分需要的了。对于互联网企业，因为核心系统研发十分规范，数据库等IT基础设施使用也十分规范，一旦能够定位到某个点，后面的自动化处置与问题解决相对也比较容易。不过对于传统IT企业，即使是研发和IT基础架构管理比较严格的银行，这种定位有时候还是不够的。比如说问题定位到了数据库，那么数据库到底是什么引起的问题还是无法快速定位。重启数据库恢复系统？直接切换备用系统？恐怕这种决策并不容易，特别是没有完全定位问题之前就做这种处置，恐怕连互联网企业也不敢轻易做吧。于是我就和他讨论针，如果仅仅对数据库的告警日志，他们的算法有没有办法定位问题根因。他说：“那还不容易，比如Oracle就有一个oerr工具，输入错误码，不就知道问题是啥了吗？”。实际上这个问题还真的不简单，我以前也写过几篇关于这个问题的文章，当时举的例子是ORA-1555这个著名问题。从oerr ora 1555的输出来看，这个问题似乎很简单，不过从这个输出上，我们是无法定位到问题的根因的。下面的思维导图是我们这些年积累的这个错误的可能问题路径。 这个问题实际上是挺复杂的，如果LOB字段出现损坏（逻辑错误），也会报此错误，这时候我们可以根据一些特征来确定是否是这个问题。这个分支定位比较容易，首先ORA-01555后面一定会跟有ORA-22924错误，同时rollback segment number with name “” too small的信息也十分明显，RBS的名称是空的。了解ORACLE LOB字段操作的朋友很清楚，LOB字段是不实用UNDO SEGMENT的。如果访问的没有LOB字段，也有几个分支，还要看UNDO是手工管理还是自动管理。如果UNDO是自动管理的，那么如果SQL执行的DUARATION是0或者是明显小于UNDO_RETENTION值的，那么不一定是UNDO_RETENTION设置太小，或者SQL执行的时间太长了，我们可以百分之百的定位这是因为索引的ITL槽上存在逻辑错误导致的。那么如果DURATION大于UNDO_RETENTION是不是就可以直接定位为SQL写的不好，执行时间过长呢？也不一定。还有好几种情况需要仔细甄别呢。也不能排除是ORACLE BUG导致了此问题。其中 Bug 22241601是索引存在问题，必须REBUILD，Bug 8231583必须通过重建UNDO表空间才能彻底解决。看到我的这个案例，他也觉得这个问题依靠异常检测算法或者一些比较简单的方法是解决不了的，只有通过专家的经验才能做真正的根因定位。实际上ORACLE数据库上还算好，MOS上积累了大量的知识库，可以协助专家分析。国内的运维专家也积累了大量的经验。如果此类问题出现在国产数据库上，那就麻烦了。没有知识库，没有靠谱的文档，也没有专家积累过此类经验，我们靠什么去定位问题呢？在国产或者开源数据库上，我们的很多问题定位都是通过perf/stap等OS工具去一点点分析出来的，这种故障定位没有几个人能做的很好，也十分耗时耗力，有时候找到了某个系统调用是网图的根因，但是我们又很难和数据库原厂的开发人员沟通，一起来定位问题。国产数据库厂商有没有建立MOS这样的平台，也没有OCS、CUS这样专业的售后团队来处置这样的问题。由此可见，我们的国产数据库厂家不能光把精力放在数据库产品的研发与销售上，建设类似MOS这样的平台的工作也迫在眉睫了。
