一、AIOps与智能日志中心1.1AIOps的五个层次要说智能日志中心，首先要了解什么是智能运维。目前，智能运维在行业的应用主要分为以下五个层次。第一关最简单，只要你有尝试的想法，到网管监控系统，得到一个监控指标曲线，然后尝试异常检测。第一层没有成熟的单点应用。当有成熟的单点应用时，才算达到了第二个层次。第二层次必须有一定的基础设施建设作为前提。当单场景模块能够串联起来形成流程化的AI运维，就达到了第三个层次。目前行业基本处于从一、二级向二、三级努力的阶段，距离四、五级还有很长的路要走。众所周知，现在AI应用强大，技术成熟，能够广泛应用的模块基本上只有两个——语音识别和人脸识别。语音和人脸识别的快速发展，主要得益于国内市场的需求，以及国内人口基数大下的广泛数据资源。运维领域数据较少，信息比较碎片化，导致AIOps发展缓慢。LogEasy在五年前开始做日志分析的时候，主要得益于海量的日志数据和AI算法的应用，实现了智能化的日志分析。目前，LogEasy智能日志中心处于AIOps五个级别中的Level2和Level3之间。1.2智能日志中心简介为了帮助您实现更高级的AIOps能力，LogEasy打造了智能日志中心。下图是智能日志中心的全景架构图。我们都知道，对AI来说重要的是数据。因此，首先我们要具备尽可能多类型的数据采集、处理和分析能力。LogEasy支持Linux、Windows、AIX、HPUX等多种平台的数据采集，还可以从ODBC、Syslog、APM甚至是手机APP中嵌入的数据采集数据，再配合一些CMDB数据，处理工单数据，非常方便在业务运维层面实现关联分析。摄取后，我们有几十种ETL方法来规范化日志。日志本身是非结构化的，日志分析需要格式化数据。做完ETL之后，可以很方便的进行后续的分析。这个环节会涉及到一些数据脱敏和业务日志拼接。对于一些时间戳设计不合理的日志，LogEase会自动补全，以方便后续的分析工作。查资料的时候，业界主流的开源方案是ES。但是由于ES开源引擎是一个通用的搜索引擎，很难满足一些特殊的日志处理需求。采用Java开发，在内存消耗和性能方面有很大的优化空间。面对海量的日志数据，ES往往显得力不从心。基于以上原因，LogEasy开发了比通用引擎快5倍以上的Beaver搜索引擎，保证海量数据的实时访问。我们还有上百条SPL指令用于统计分析，针对不同场景的算法也有很多。搜索引擎可以说是AIOps的大脑。我们有LogEasy智能日志中心，以及基于日志的智能运维应用Lynxee、Galaxee、DataFactory。安全审计、业务关联分析等解决方案也基于智能日志中心实现。智能日志中心可对接大屏显示、告警推送、脚本按需执行、公共数据API和第三方平台。这部分可以说是AIOps的手笔。以上这些共同构成了整个智能日志中心，我们也可以将其视为AIOps的中控（或中台）。LogEasy拥有上百种不同类型的数据采集分析方案，可直接导入安装，如Cisco、F5、天融信等网络设备日志，Oracle、MySQL等数据库日志，Nginx、Apache等中间件日志，等。这些内置的数据收集和分析解决方案可以节省数据收集和处理的时间。我们在实践中发现，一个运维数据中心花费在数据采集和处理上的时间超过70%。真正的处理完成后，分析过程还是很快的。这与人工智能80%的工作是数据清洗的AI定义是相当吻合的。2.AIOps场景及围绕日志的算法原理介绍2.1AIOps场景谈到AIOps场景，我们可以从成本、质量、效率三个方面进行规划，如下图所示：在质量保障方面，以往的异常检测需要运维工程师根据自己的经验进行判断和分析。我们需要做的就是利用人工智能来实现这个目标。故障的出现总是一个征兆，可能表现为延迟逐渐增加，响应逐渐变慢。我们可以根据这些先兆和历史数据制作模型，以预测即将发生的异常。成本管理和效率提升面临的情况更加复杂。成本管理面临成本优化、资源优化、容量规划、性能优化等复杂场景。效率提升涉及高度复杂的智能变更、智能问答、智能决策、运力预测等，以双十一运力预测为例，需要结合历史流量等因素综合分析进行预估。即便如此，估计值往往与实际情况大相径庭。在现阶段，质量保证仍然是最关键、性价比最高的部分，也是最先可以智能化的部分。我们的智能日志中心目前正专注于这个方向。具体来说，在质量保障方面，运维人员希望做到的是预警、第一时间定位、第一时间修复。在“日志+算法”的AIOps实践中，具体过程为以下三个步骤：1.快速故障检测：即基于多种算法的异常预测；2、问题归因定位：即通过日志方式洞察罕见的错误信息；3、辅助维修决策：即通过多方位显示系统状态，加快决策速度。2.2AIOps快速发现故障快速发现故障，第一时间报警。告警的本质是告诉运维人员两件事：第一，有问题；第二，问题有多严重。我们直接从日志中产生告警，或者通过统计分析将其转化为时序指标，然后对告警进行监控。通过整合告警的优先级和重要性，拟合一个服务的健康度，让用户对系统状态一目了然。一般来说，监控系统会有两种告警：一种是关键词匹配告警，一种是采样指标阈值比较告警。匹配关键字的严重程度是匹配warning、critical等；阈值的严重程度是定义多个阈值范围。例如CPU大于80%，则发出中危告警；CPU大于120%，则发出高危告警。在智能日志中心，两种告警都支持。从日志、时序指标的监控告警，到服务的健康度和故障定位，LogEasy都有一套完整的监控流程，是智能日志中心的重要组成部分，位于引擎的上层。报警部分仍然是基于质量保证和AI算法。2.3AIOps问题归因定位2.3.1指标异常检测《SRE》是近几年很火的一本书，有一个概念值得推荐，就是所谓的“黄金指标”。无论是主机设备层面，还是应用服务层面，亦或是集群、端到端等，都可以从延迟、流量、错误、饱和度这四个最关键的角度来衡量其健康状况。在LogEasy中，我们可以通过SPL语句将不同的日志数据快速转换成对应的指标数据。只需更换红字的过滤条件，即可实现全面的指标数据覆盖。有了指标数据，接下来要考虑的是如何对指标进行智能检测，根据历史情况智能发现问题。由于指标种类繁多，很难有一个通用的算法。因此，LogEasy根据不同场景的需要，启用了不同的算法。下面简单介绍一些算法的原理。CVAE算法我们都知道VAE是深度学习的一种。一般在网上搜索这个算法的解释，都是关于如何做图像识别的。该指标是一条非常简单的曲线，所以我们将曲线以滑动窗口的形式切割成小曲线，并将它们组合在一起形成特征矩阵，然后进入多层编码解码，反复迭代得到更好的模型.为了提高效果，可以在训练数据中主动加入一些噪声误差。然后在实际检测时，我们将测试数据编解码得到的仿真曲线的一小段分布与实际数据进行对比，看是否存在严重偏差。由于模拟曲线呈正态分布，因此该偏差为3Sigma。该算法非常适合强周期指标检测。一般来说，大量人群的行为产生的数据，比如商务拜访，是非常适合的。我们在这方面还有一个创新：我们加强了对时间特征的处理。我们知道，人的行为必然有一个循环。今天和昨天，这个星期一和上个星期一，每个月的第一天，每年的春节，每年的618，双十一等，都会在算法学习行为上得到加强。iForest算法第二种是iForest算法，它是一种专门用于异常检测的随机森林算法变体。适用于一些与时间相关性不强的指标，如主机的CPU、内存等，数据本身分散性较大，没有规律可循。主要的担心可能是它不会偏离太大。这样的指标很多，要求算法的检测速度足够快。KDE算法第三种是KDE算法，它针对的是一类特殊的场景。我们知道某些服务并非全天候运行24/7。例如，股票市场每天9:00开市，15:00收市。休市时，证券公司相关系统的业务指标完全为零。收盘和开盘这两个阶段是截然不同的，普通算法几乎肯定会在这两个过渡时刻做出虚假报告。同理，理财等金融场景也很多。周末两天没有业务输出也是情理之中。因此，我们根据一天的维度，为一天中的每个时间点选择其周围的几个点组成一个集合，进行核密度分析，然后将一天中的所有点组合起来，得到最终的KDE模型。这个模型有点类似于3D地图上由无数正态分布堆积而成的山脉。然后在测试的时候，如果时间对应的值已经过去了，如果出现在平原区域，明显是不正常的。GRBT算法GRBT算法，我们会同时提取时间序列数据的统计特征及其时间戳特征。与KDE和iForest相比，其使用场景适用范围更广，可用于变异和业务。可以看出这个算法的原理和之前的iForest类似，因为都是决策树森林。而iForest是每次局部采样迭代，而Boosting是每次根据上一次迭代的结果重新选择分界点。但这是一种有监督的学习。要想用好，需要训练样本中存在一定的异常点。针对不同的场景有很多不??同的算法。运维人员可以根据实际差异选择不同的算法，以达到更好的算法覆盖率。LogEasy未来会继续研究指标数据类型的自动判断，尽量减少运维配置选择算法的工作量。2.3.2日志异常检测除了指标的异常，还有日志的异常。如前所述，最常见的日志警报是关键字匹配。但是大部分系统的开发并没有把日志写的这么规范。2016年，中国科学院《软件学报》发表了一篇国防科技大学的文章《大规模软件系统日志研究综述》，其中引用了国内外许多调查和分析。其中一些数据还挺有意思：日志代码的更新频率比其他代码快1倍左右；大约四分之一的日志修改是将新的程序变量写入日志；大约一半的日志修改是对日志消息静态文本的修改。这些研究一般都是基于大型的分布式项目，比如Hadoop、OpenStack等，企业内部的系统开发应该比这些大名鼎鼎的项目认真得多。所以，你在输出日志的时候，很难做到特别规范，而且日志格式经常变化……所以，对于长时间运行的场景，靠关键字或者固定的正则表达式抽取是不够的。对于异常检测，需要AI算法的帮助。Hierarchicalclusteringgetlogmodelogeasy的思路是使用hierarchicalclustering。先对日志进行最基本的分词和类型判断，然后进行聚类和合并。聚类可以使用最长子串，或者文本频率等。在聚类中，不同的部分用通配符代替。类似这张图，8条日志先合并成4种日志格式，然后合并成2种，再合并成1种。在研究领域，我们一般称这种日志格式的树结构为模式树。当然，我们在练习的时候，并不是真的需要数到最上面。一般来说，当模式个数的收敛速度相差无几，或者模式中的通配符个数相差无几时，我们就可以停下来。日志模式的使用获取日志模式，如何使用？一般来说，有两种用法，故障定位和异常检测。故障定位一是故障定位时间。例如，如果我们查看错误日志并简单地使用关键字，可能会出现数百或数千个条目。你必须一张一张地看，翻好几页，要花很长时间。如果内容字数较多，可能会遗漏。模式树的信息，可以直接查看日志匹配关键字的模式。可能只有三五条信息，看一眼就能知道问题出在哪里，就可以进行下一步了。异常检测的另一个目的是将获取的数据加载到日志采集的实时处理流程中，进行异常检测，提前发现问题。这时候除了众数，我们还可以检测参数和检测比。上图是最简单的例子。有3个日志。得到的pattern是*are
