海量日志分析与智能运维

1、AIOps 与智能日志中心

1.1AIOps 五等级

要说智能日志中心，首先要了解什么是智能运维。目前业界对智能运维的运用，主要分为以下五个等级。

一级是最容易的，只要你有个想法试试就行，到网管监控系统里，拿一个监控指标的曲线下来，就能够尝试异常检测。

一级尚未成熟的单点应用，当有了一个成熟的单点应用，就算是达到二级。二级必需要有必定的基础设施建设做为前提。当单场景模块可以串联起来，造成流程化 AI 运维，也就达到了三级的层次。

目前业界基本上处于从一二级，往二三级努力的阶段，想实现4、五级还比较远。

你们都知道，如今 AI 应用强、技术成熟，能被普遍应用的基本上仅有两个模块——语音识别和人脸识别。语音及人脸识别可以快速得以发展，主要由于国内市场的需求，及国内大人口基数下普遍的数据资源。

运维领域数据较少，且信息比较碎片化，这使得 AIOps 发展缓慢。日志易五年前开始作日志分析的时候，主要也是得益于海量的日志数据，AI算法的应用下，得以实现智能日志分析。目前日志易智能日志中心处于 AIOps 五等级的二级到三级之间。

1.2智能日志中心介绍

为了帮助你们实现更高级的 AIOps 能力，日志易打造了一个智能日志中心。以下图，为智能日志中心的全景架构图。

咱们都知道， AI 重要的是数据。因此，首先咱们要具有尽可能多类型的数据采集、处理及分析能力。

日志易支持 Linux、Windows、AIX、HPUX 等各类平台的数据采集，也能采集 ODBC、Syslog、APM 的数据，甚至手机 App 埋点数据，而后配合一些 CMDB 数据，流程工单数据，很是方便地实现业务运维层面的关联分析。

采集以后，咱们有数十种 ETL 方法来对日志进行规范化处理。日志自己是非结构化的，而日志分析须要格式化的数据，ETL 作好了，后续的分析才容易展开。

这个环节，会涉及到一些数据脱敏及业务日志串联，对于一些时间戳设计不合理的日志，日志易会自动对其进行补全，以便后续分析工做的展开。

对数据进行搜索时，业界主流开源解决方案是 ES。然而，因为 ES 开源引擎是一个通用的搜索引擎，难以知足日志处理的一些特殊需求，用Java 开发，内存消耗及性能上存在很大优化空间，在面临海量日志数据时，ES 每每显得力不从心。

基于以上缘由，日志易本身开发了比通用引擎快 5 倍以上的 Beaver 搜索引擎，保证了海量数据的实时存取。咱们还有上百个 SPL 指令进行统计分析，有多种不一样场景的算法。搜索引擎能够说是 AIOps 的大脑。

咱们有日志易智能日志中心，也有基于日志开发的智能运维应用 Lynxee、大屏 Galaxee、数据工厂。安全审计、业务关联分析等解决方案，也是基于智能日志中心实现的。

智能日志中心能够与大屏展现、告警推送、按需调用脚本执行、公开的数据 API 和第三方平台对接，这一部分能够说是 AIOps 的手。

以上这些合在一块儿，就是整个智能日志中心，咱们也能够把它看做 AIOps 的中控（或者中台）。

日志易有上百种不一样类型数据的采集分析方案，能够直接导入安装，如思科、F五、天融信等各类网络设备日志，Oracle、MySQL 等数据库日志，Nginx、Apache 等中间件日志等。这些内置数据采集分析方案，能够节省数据采集处理的时间。

咱们在实践中发现，作一个运维数据中心，70% 以上的时间是在作数据采集和处理。真正处理好了之后的分析过程仍是很快的。这和 AI 界说人工智能 80% 的工做是数据清洗，是比较吻合的。

2、围绕日志的 AIOps 场景与算法原理介绍

2.1AIOps 场景

说到 AIOps 的场景，咱们能够从成本、质量、效率三个方面作出规划，以下图：

以质量保障而言，以往的异常检测，须要运维工程师基于本身的经验作出判断和分析，咱们要作的，是借助AI来实现这一目的。

故障的发生都是有先兆的，可能表现为延时逐渐增大，响应逐渐变慢等。咱们能够基于这些先兆及历史数据作出模型，对即将发生的异常作出预判。

成本管理和效率提高要面临的状况更加复杂。成本管理面临成本优化、资源优化、容量规划、性能优化等复杂场景。

效率提高涉及复杂度较高的智能变动、智能问答、智能决策、容量预测等，以双十一容量预测为例，要基于历史数据预估流量，同时结合业务（如促销活动带来的增量）等因素综合分析。纵然如此，预估也每每会和现实存在较大出入。

就目前的阶段，质量保障仍是最关键、性价比很高的，是能够首先实现智能化的部分。咱们的智能日志中心，目前主要关注的也是这个方向。

具体来讲，在质量保障上，运维人员但愿作到的，就是尽早告警、尽快定位、尽快修复。表如今“日志+算法”的 AIOps 实践上，具体流程为如下三步：

一、快速发现故障：即基于多种算法进行异常预测；

二、问题归因定位：即经过日志模式洞察罕见报错信息；

三、辅助修复决策：即经过多方位展示系统状态加速决策。

2.2AIOps 之快速发现故障

快速发现故障即尽快告警。告警的本质，是告诉运维人员两件事情：一，有问题了；二，问题有多严重。

咱们从日志直接产生告警，或者通过统计分析变成时序指标，再监控告警。经过整合告警的优先级和重要程度，拟合出来一个服务的健康度，让用户对系统状态一目了然。

通常而言，监控系统会有两种告警：一种是匹配关键字，一种是采样指标的阈值对比。匹配关键字的严重性，就是匹配 warning、critical 等；阈值的严重性，就是定义多个阈值区间，好比 CPU 大于 80% 发中危告警、大于 120% 发高危告警。在智能日志中心，这两种告警都支持。

从日志、时序指标的监控告警，到服务健康度、故障定位，日志易有一整套监控流程，这是智能日志中心的重要组成部分，位于引擎的上层。告警这部分仍是以质量保障和 AI 算法为主。

2.3AIOps 之问题归因定位

2.3.1指标异常检测

《SRE》是这几年很火的书了，里面有个概念值得推荐，就是所谓“黄金指标”。

无论是主机设备层面，仍是应用服务层面，或者集群、端到端等等，均可以从延迟、流量、错误和饱和度四个最关键的角度，来衡量它的健康状态。

在日志易中，咱们能够经过 SPL 语句，快速从不一样的日志数据，转换成为对应的指标数据。只须要更换红字这段过滤条件，就能够作到全面的指标数据覆盖。

既然有了指标数据，下一步要考虑的就是如何智能地检测指标，以便根据历史状况，智能地发现问题了。

由于指标的千差万别，很难有一种单一的普适算法。因此日志易针对不一样场景需求，启用不一样的算法。下面稍微介绍部分算法的原理。

CVAE 算法

咱们都知道 VAE是深度学习里的一种，通常你在网上搜这个算法解释，都是讲怎么作图像识别的。

指标就是一个很简单的曲线，因此咱们把曲线按照滑动窗口的形式，切割成一段一段的小曲线，合在一块儿，就成了一个特征矩阵了，而后进入多层的编码解码，反复迭代，获得更好的模型。

为了提升效果，在训练数据上，还能够主动添加一些噪声偏差。

而后实际检测的时候，咱们就把测试数据通过编解码得出来的一小段模拟曲线的分布，和实际数据做对比，是否是发生了严重偏离。由于模拟曲线是正态分布的，因此这个偏离就是 3Sigma。

这个算法，很适合作强周期性的指标检测。通常来讲，由大量人群行为产生的数据，像业务访问，就很适合。

咱们在这块还有一个创新：增强了时间特征上的处理。咱们知道，人的行为确定是有大小周期的，今天和昨天、本周一和上周1、每月一号、每一年春节、每一年 61八、双十一等，都是在算法上会重点增强学习的行为。

iForest 算法

第二个是 iForest 算法，这是一个专门用来作异常检测的随机森林算法变种。

它适合一些和时间没有强相关性的指标，好比主机的 CPU、内存等，数据自己离散度较大，没有什么规律，可能主要关心的就是它不要出现太明显的偏离。

这种指标比较多，要求算法检测速度够快。

KDE 算法

第三个是 KDE 算法，这个算法针对的是一类特殊的场景。

咱们知道，有些服务并非 7x24 小时运行的。好比股票市场，天天 9 点开盘，15 点收盘。在闭市的时候，证券公司相关系统的业务指标彻底是零。闭市和开市两个阶段，泾渭分明，普通算法在这两个跃迁的时刻几乎确定是要误报的。

同理，还有不少理财之类的金融场景，在周末两天无业务输出也是一个道理。

因此咱们按照天的维度，对天天的每一个时间点都选取它周围的若干个点，造成一个集合，进行核密度分析，而后一天的全部点合起来，获得最终的 KDE 模型。

这个模型有点相似于在 3D 地图上，无数个正态分布堆在一块儿造成的山峦。那么检测的时候，对应时间过来的值，若是出如今平原地带，就是明显的异常了。

GRBT 算法

GRBT 算法，咱们会同时提取时序数据的统计学特征，以及它的时间戳特征。它的用途场景与 KDE 和 iForest 相比，有更普遍的普适性，突变的和业务的都能用。

能够看到这个算法原理，和前面 iForest 比较像，由于都是决策树森林。不过 iForest 是每次部分抽样迭代，而 Boosting 是每次根据上一次迭代的结果来从新选取分界点。

可是这是一个监督学习，想用好，须要训练样本里有必定的异常点标注。

有这么多不一样的算法针对不一样的场景，运维人员根据实际的区别，选用不一样的算法，就能够达到比较好的算法覆盖了。

日志易后续也会继续研究指标数据的类型自动判断，尽可能减小运维配置选取算法的工做量。

2.3.2日志异常检测

除了指标的异常，还有就是日志的异常。前面提到，最多见的日志告警就是关键字匹配。不过，大多数系统的研发，不会把日志写的那么规范。

2016 年，中科院《软件学报》发过一篇国防科大的《大规模软件系统日志研究综述》，里面引用了很多国内外的调查分析。其中有几条数据蛮有趣的：

日志代码的更新频率比其余代码要快约1倍；

约四分之一的日志修改是把新的程序变量写入日志；

约一半的日志修改是对日志消息静态文本的修改。

这些研究通常都是基于大型分布式项目，好比 Hadoop、OpenStack 等。企业内部的系统开发，状况应该会比这些著名的项目要严重的多。因此，你们输出日志的时候，很难作到特别规范，日志格式常常在变更……

因此，依赖关键字或者固定的某种正则表达式提取，在长期运行的场景下，是不足以作到日志异常检测的，这时就须要 AI 算法来帮忙。

层次聚类获得日志模式

日志易的思路，是采用层次聚类。

先对日志进行最基础的分词和类型判断，而后聚类合并。聚类能够用最长子串，也能够用文本频率等等。聚类里，不一样的部分就用通配符替换掉。相似这张示意图，把 8 条日志，先合并成 4 个日志格式，合并成 2 个，再合并成 1 个。

在研究领域，咱们通常把这种日志格式的树状结构，叫模式树。

固然咱们实践的时候，不用真的算到最顶端，通常来讲，模式数量收敛速度差很少了，或者模式里的通配符数量差很少了，就能够停下来了。

日志模式的用法

获得日志模式，具体怎么用呢？通常来讲，有两种用法，故障定位和异常检测。

故障定位

一种是故障定位的时候。好比咱们查错误日志，单纯用关键词，可能出来几百上千条。你要一个一个看过去，翻好几页，耗时就比较长了。若是内容字不少，还可能看漏了。

模式 树的信息，能够直接查看匹配关键字的日志的模式状况，可能就只有那么三五条信息，一眼就能够看完，很快就能够知道问题在哪，就能够进行下一步了。

异常检测

另外一个用途，就是把获得的，加载到日志采集的实时处理流程里，进行异常检测，提早发现问题，这时候，咱们除了模式，还能够检测参数，检测占比。

上图是一个最简单的示例，3 条日志，获得的模式是*are<NUM>，而后咱们同时能够检测符合这个模式的日志，前边的只能是 we 或 you，第三位只能落在平均值为 93.三、标准差为 9.4 的正态分布区间内。

而后日志采集进来，先检测一下这个模式是否是合法的。若是合法，再检测一下各个参数位置的取值是否是合法的。若是依然合法，再检测一下这段时间这个模式的日志数量，和以前相比是否是正常的。

这么三层检测下来，至关于把模式异常、数值异常、时序指标异常融合到了一块儿。

这张截图就是日志异常检测的一个历史列表。能够看到，哪怕在 INFO 级别，也是可能出现你历来没见过的古怪日志的，这就须要密切关注了。

固然，由于日志量特别大，因此他的训练样本很容易错过一些正常状况，因此上线初期，咱们须要一些迭代以及标注的优化过程。把初始样本不断丰富起来。

前面说了不少 AI 算法：如何来发现异常，定位异常。可是很惋惜，定位异常这件事情，目前很难作到能找出很是理想的根因的程度。通常的作法，是依赖于云平台、容器平台的指标采集，作到定位出某台机器有问题，具体仍是要登录机器分析。

咱们从日志的角度，能够定位到某台机器的一段日志有问题，可是也不算找到 100% 的根因了，还须要后续查询分析。

因此，作一个智能日志中心，咱们也还须要提供更全面的统计分析和快速查询的能力，来完成对全局的、细节的运行状态的观测，以及对变化的即时捕捉。

3、日志分析实践与案例

3.1业务交易的实时统计分析

对应前面说的 VAE 算法，咱们说他最适合的就是监控业务交易量这类指标。

咱们能够经过仪表盘的可视化效果，对业务交易量的各个不一样维度，进行很是细致的统计分析。这样有什么变更的时候，一眼就能看到。

固然，因为交易分析的常见维度比较少和明确，后续也能够经过决策树算法，来自动定位哪些维度的异常更明显地形成了变化，好比某个省某个运营商某个手机型号打开慢之类。

从实践来讲，这种基于性能优化目的的根因分析，即便分析出来，后续的优化成本也比较高，极可能从性价比考虑，会放弃掉。

交易量指标仍是像这样用来作实时统计和监控比较多。

3.2业务监控-多层业务指标钻取

若是是业务结构比较复杂的场景，可能单看最终用户层面的交易维度不足以定位故障。咱们还须要从内部的业务流转关系来调查问题。这时候，就能够用拓扑图来观测系统运行状态。

在运行状态出异常的时候，经过钻取跳转，把每层的状况和调查路径串联起来。哪怕很基础的运维人员，也能够熟练地按照高级工程师定义好的路径排查问题。

3.3业务监控-调用链展现分析

业务分析的另外一个层面，是针对用户的分析，相似如今很流行的 Tracing 调用链系统。

对于智能日志中心来讲，Tracing 数据也是能很好支持的。在这个基础上，能够作到很好的展现。

日志易提供了标准的调用链表格，还提供了循序图分析。这是业界比较少见的方式，但对研发人员很友好，由于系统设计的时候，循序图是研发人员很熟悉的方式。

3.4用户端监控－DNS/CDN 日志分析

除了系统内部，还能够从 DNS 和 CDN 厂商获取日志，甚至包括收集本身的手机 App 日志，来了解、监控端到端的状况。

以上截图，展现了 10TB 级别日志量的实时返回码趋势分析、各站点缓存率分析、各站点响应时长分析、流量峰值分析，以及用户行为轨迹分析、高频请求客户分析、热门站点分析、域名与运营商关系分析等。

此外，基于这些日志能够实现性能监控、故障排查等，也能够跟第三方厂商的计费作二次核算。

以上文字版根据《大咖·来了》第3期《海量日志分析与智能运维》整理，回放连接：http://aix.51cto.com/activity/10011.html?dk=wz