【第九期金融CIO论坛】日志易陈军：智能运维与海量日志分

2017年5月25日下午，由中国新一代IT产业推进联盟指导，CIO时代学院、《金融电子化》杂志社联合主办，日志易、亚联信息作为战略合作伙伴，CIO时代APP承办，“第九期金融CIO论坛”活动在上海成功举行。近三十位金融业界的专家、技术大咖、金融CIO班学员欢聚一堂，就本次研讨主题“双模式IT背景下的金融科技创新”展开了最新探讨和深度分享。日志易创始人兼CEO陈军在活动上分享了题为《智能运维与海量日志分析》的主题演讲。以下为演讲实录：

大家下午好。今天讲的双模IT也离不开日志，因为机器学习、人工智能也非常火热，我讲一下智能运维，智能运维也离不开日志的数据源的分析AIOp，智能运维的核心就是机器学习+大数据。我们知道运维有三大模块，服务台、自动化、监控，这三大模块核心就是用机器学习和大数据来分析服务外面的这三大模块。

智能运维的架构有数据的采集、存储和分析，分析是深度分析，在运维方向和其他的一些人工智能不同的地方是它是实时性的，上面展现的就是可视化和自然语言。可视化就是把很多运维的数据用各种生动的图表表现出来，对于自然语言，现在很多运维系统实际上还是通过键盘、鼠标来交互，未来的运维系统可能就是通过自然语言，比如说直接用声音告诉它你想做什么，查什么东西，比如说过去10分钟才能查出出了什么故障，以后问这种问题，它会直接告诉你，通过自然语言进行人机交互。上面提供的服务一个是商业价值信息的仪表盘，还有运维中心，还有就是DevOps，跟传统的运维管理连接起来。我们可以看到，IT运维的进化，从最早的十几年前，就是稳定模式下的这种叫IT Operation Management运维管理，还有就是通过大数据技术产生ITOA，再到下一步把人工智能、机器学习的算法用到运维上就是智能运维（AIOp）了。

从故障处理的进化来讲，原来是事后的根源出了故障再排查故障，用几分钟、几个小时或是几天找到故障，通过人工来判断，到现在能够做到这种用大数据技术做实时的发现，秒级的延时，或是做一些实时的检测，只要故障一发现就马上报警，未来通过机器学习、人工智能的技术做到事前的预警，另外就是容量规划，我们预测明天或是下一周的容量，来进行相应的规划。

讲到IT运维的分析，它是用大数据的技术应用在IT运维上面，数据源就非常的重要。Gartner有一个预测，2017年15%的大企业会积极使用ITOA，而2014年只有5%。所以Gartner在这些新技术领域还是有很大的指导作用。ITOA因为是用大数据的技术处理运维产生的数据，所以这个数据源非常重要，基本上有四种数据源，一种就是日志，机器数据；第二种就是网络抓包产生的数据；第三种就是在代码里面插入自解码来进行代码级的监控；还有一种就是模拟检测。美国有一家ITOA的公司对客户做过调查，有86%的客户是用日志，从日志这个角度来分析，93%用网络抓包，47%是插入代码，72%用模拟检测。这个也能说明道理，因为日志是无处不在的，但是它的局限性就是不同的应用输出的日志的内容完整性和可用性不一样，这是它的局限性。网络抓包也是信息非常全面，网络抓包的局限性如果是本机内部没有产生通信的话，这个网络抓包也没有办法获得信息，因为一些事件还没有触发网络流量你就没有办法抓包。而监控代码的及时性安全性有保障的话，性能会有一些损耗。探针数据，可能是全国各地几百个数据中心发出请求让你检测这个网络服务器的延时，但是它不是真实的用户度量，我们说运用性能监控，度量真实用户的情况，真正用户访问你？耐净蚴鞘褂檬只鶤PP访问的时候他体验的延时是多大，这个更重要，但是探针数据只是一个模拟。

我们看一下日志，日志是我们非常重要的数据资产，它里面包含的信息非常多，IP地址，时间，请求的方法，各种各样的信息都包含在里面。日志可以做安全审计，可以用在运维监控，用在回溯取证，业务分析等方面。我们双模IT也需要分析日志，特别传统模式的话用日志做一些统计分析和数据溯源，敏捷开发的话DevOps更需要从日志及时发现故障根源。比如做灰度发布，当你发布灰度的时候就密切关注应用的情况，如果有出现错误异常需要马上发现，马上修复对这个监控更加依赖，监控主要的方式就是通过日志，从日志里面发现有没有异常，这个DevOps对日志使用提出了更高的要求。

安全方面呢，因为这些日志没有集中管理，黑客进入系统之后会马上删除日志，把他运行的痕迹抹除掉。现在日志的量越来越大，每天的量都是TB级，过去是用数据库存日志，但是我们知道数据库是存结构化数据的，现在很多日志是非结构化数据，所以它没有办法满足这种海量检索的需求。

近年来，随着大数据技术的出现，最常见的就是用Hadoop来处理日志，但是它延时比较大，可能会有几十分钟的延迟，也比较慢，它主要是做离线挖掘，而不能做在线分析。后来又出现Storm、Spark这样非常强大的分析框架，但是它不是拿来就可以用的产品，另外用NoSQL存日志，但是它不支持全文检索。我们面临的问题，也就是日志需要满足的要求一个是多样性，处理各种各样格式的日志，而且不需要对日志系统进行改造。一个需要快，就是日志从产生到搜索分析出结果希望仅仅有几秒钟的延迟，有问题马上发现，每天可以处理TB级的日志。还有一个就是灵活，我们希望是像百度谷歌一样的搜索引擎，日志里面任何的字段都可以搜索出来。另外就是叫做大数据，我们讲的多了它叫既快又大的实时的大数据，通过这样的技术来处理日志。

我们可以看到，日志系统的进化从最早的数据库存储日志把它叫日志的1.0，数据库我们看到是没有办法满足日志的非结构化数据的，到日志2.0用Hadoop，但是它是开发框架，必须有一个开发团队才可以做到这个事情，而且是批处理，实时性差，不支持全文检索。日志3.0我们就是希望实时、灵活、全文检索。日志4.0我们就是希望机器学习，人工智能都用在日志上。

日志应用场景－营销及电商平台

日志应用场景－安全分析

日志应用场景－机器学习、智能运维

讲到机器学习，智能运维用到日志的就是异常检测和容量规划。这是我们用来做机器学习的案例，大家可以看到这里搜索框写搜索语言的脚本，这个日志已经从非结构化数据转化为结构化数据，这里是一个表格，在后台通过机器学习实现一些函数。通过函数的预测结构生成了预测值——这个线就是预测范围。，根据它过去的数据，根据它历史数据，通过机器学习可以找出它正常的范围，然后看它目前在这个范围偏差多少，我们就可以根据不同的机器学习的算法算出来的数据，根据这些数据来看它异常的情况。

这也是找异常点，这里偏差比较大的就是异常点，也是我们用机器学习的一个案例。这些数据是运维相关的数据，因为我们除了采集日志之外，还可以采集服务器的CPU内存、硬盘网络使用情况这种性能数据，实际上这些数据也是时间序列机器数据，跟日志是类似的，都带时间戳。把日志导入日志易系统里面就可以做预测分析预测的需要对样本做切分，如果切分不对就会跟真正实际的值有偏差，图中红色的是实际值，蓝色是预测值。机器学习就是根据数据调参数，如果参数没有调好预测就不准，我们把样本参数改变之后，预测值跟实际值就非常接近。

我们还可以做报警的自动关联，当数据中心出现故障的时候，比如说一个服务器一个网络设备一个端口断掉，这个网络设备会发出告警，服务器连接的设备发出告警，上面的程序跟外面没有连接也会发出告警，然后我们就把日志易系统跟这些设备连接起来，就知道网络的情况，分析调用链。现在都是微服务，一个流程可能有多个服务的调用，我们可以通过日志分析来关联起调用，来做调用链的分析，哪个服务调用了哪个服务，把调用链分析出来。我们也在一个客户那里做过交易的分析，一笔交易会经过多台服务器，多个子系统，每个子系统都会产生日志，我们把这笔交易在多个子系统产生的日志关联起来，还原成一笔交易来做精细化的监控，特别是现在微服务，微服务把原来得大系统拆成一个一个小系统，对监控的要求更高了，我们也可以通过日志监控这些微服务。这就是日志易关联分析做的一些工作。