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

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



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


　　从故障处理的进化来讲，原来是事后的根源出了故障再排查故障，用几分钟、几个小时或是几天找到故障，通过人工来判断，到现在能够做到这种用大数据技术做实时的发现，秒级的延时，或是做一些实时的检测，只要故障一发现就马上报警，未来通过机器学习、人工智能的技术做到事前的预警，另外就是容量规划，我们预测明天或是下一周的容量，来进行相应的规划。
　　讲到IT运维的分析，它是用大数据的技术应用在IT运维上面，数据源就非常的重要。Gartner有一个预测，2017年15%的大企业会积极使用ITOA，而2014年只有5%。所以Gartner在这些新技术领域还是有很大的指导作用。ITOA因为是用大数据的技术处理运维产生的数据，所以这个数据源非常重要，基本上有四种数据源，一种就是日志，机器数据；第二种就是网络抓包产生的数据；第三种就是在代码里面插入自解码来进行代码级的监控；还有一种就是模拟检测。美国有一家ITOA的公司对客户做过调查，有86%的客户是用日志，从日志这个角度来分析，93%用网络抓包，47%是插入代码，72%用模拟检测。这个也能说明道理，因为日志是无处不在的，但是它的局限性就是不同的应用输出的日志的内容完整性和可用性不一样，这是它的局限性。网络抓包也是信息非常全面，网络抓包的局限性如果是本机内部没有产生通信的话，这个网络抓包也没有办法获得信息，因为一些事件还没有触发网络流量你就没有办法抓包。而监控代码的及时性安全性有保障的话，性能会有一些损耗。探针数据，可能是全国各地几百个数据中心发出请求让你检测这个网络服务器的延时，但是它不是真实的用户度量，我们说运用性能监控，度量真实用户的情况，真正用户访问你的网站或是实用手机APP访问的时候他体验的延时是多大，这个更重要，但是探针数据只是一个模拟。

　　我们看一下日志，日志是我们非常重要的数据资产，它里面包含的信息非常多，IP地址，时间，请求的方法，各种各样的信息都包含在里面。日志可以做安全审计，可以用在运维监控，用在回溯取证，业务分析等方面。我们双模IT也需要分析日志，特别传统模式的话用日志做一些统计分析和数据溯源，敏捷开发的话DevOps更需要从日志及时发现故障根源。比如做灰度发布，当你发布灰度的时候就密切关注应用的情况，如果有出现错误异常需要马上发现，马上修复对这个监控更加依赖，监控主要的方式就是通过日志，从日志里面发现有没有异常，这个DevOps对日志使用提出了更高的要求。
　过去我们日志没有集中管理，比如运维方面，出了问题之后相关日志散落在各台服务器，需要运维人员登录到每一台服务器使用脚本查看日志。这中间还需要审批流程，批准之后运维人员才可以登录，同时生产服务器，特别是金融系统的生产服务器，一个不小心误操作可能会产生新的故障，且没有办法做关联分析，做分析只能做简单的搜索统计，没有办法满足复杂分析，更没有实时监控和报警，比如程序出错无法做到实时报警。



　　安全方面呢，因为这些日志没有集中管理，黑客进入系统之后会马上删除日志，把他运行的痕迹抹除掉。现在日志的量越来越大，每天的量都是TB级，过去是用数据库存日志，但是我们知道数据库是存结构化数据的，现在很多日志是非结构化数据，所以它没有办法满足这种海量检索的需求。
　过去我们日志没有集中管理，比如运维方面，出了问题之后相关日志散落在各台服务器，需要运维人员登录到每一台服务器使用脚本查看日志。这中间还需要审批流程，批准之后运维人员才可以登录，同时生产服务器，特别是金融系统的生产服务器，一个不小心误操作可能会产生新的故障，且没有办法做关联分析，做分析只能做简单的搜索统计，没有办法满足复杂分析，更没有实时监控和报警，比如程序出错无法做到实时报警。



　　安全方面呢，因为这些日志没有集中管理，黑客进入系统之后会马上删除日志，把他运行的痕迹抹除掉。现在日志的量越来越大，每天的量都是TB级，过去是用数据库存日志，但是我们知道数据库是存结构化数据的，现在很多日志是非结构化数据，所以它没有办法满足这种海量检索的需求。
　　我们可以看到，日志系统的进化从最早的数据库存储日志把它叫日志的1.0，数据库我们看到是没有办法满足日志的非结构化数据的，到日志2.0用Hadoop，但是它是开发框架，必须有一个开发团队才可以做到这个事情，而且是批处理，实时性差，不支持全文检索。日志3.0我们就是希望实时、灵活、全文检索。日志4.0我们就是希望机器学习，人工智能都用在日志上。


　　如何对日志进行强大、灵活的分析



　　怎么对日志进行强大灵活分析呢，一个是建立一个统一的日志管理平台，把所有的日志收集起来。深圳某大型综合金融集团就是建起日志云，就把集团的所有IT的日志都收到这个日志云上面，也开发了集团日志管理平台，这样的话禁止工程师登录到生产服务器查看日志，只能在这个平台上分析统计日志，这是日志领域在国内做的非常领先的，在一个集团的级别建起统一的管理。把这个日志统一管理起来之后后面做的就可以很多，对日志进行分析。



　　我们日志产品对标的美国一家公司，它已经做了十年了，它的日志产品功能已经做了比如搜索处理语言，为什么要提供搜索处理语言？用户分析的场景都不一样，各种各样的场景，怎么样让这个场景非常强大适应各种场景，一种可能就是你做定制化开发，每次有一个新的功能过来研发团队就去改代码，另外一种做的比较好的做法就是搜索处理语言。



　　我们现在是在搜索框里面实现了搜索语言，用户在搜索框里面做搜索处理语言的脚本，这个脚本跟Linux的命令类似，通过管道服务串起来，管道左边的输出作为右边的命令的输入，把子命令嵌入进来，这个类似于SQL，但是它比那种语言更强大，可以在这个搜索框里面写脚本编程。



　　另外我们对日志分析之后，日志本身是非结构化数据，你如果分析，对各个字段进行统计和做BI或是机器学习都要做结构化，把这个字段搜索出来，什么时候你抽取这个字段，基本有两种方式，一个叫Schema on read，就在日志接入时就对日志字段理解，进行结构化，并提取出需要的字段。但你查询或日志分析的时候发现某个字段是你要分析的，但是没有抽取，没有做结构化，那就没有办法分析，就等于需要把日志重新入库，不够灵活。另外的一个叫Schema on write，在你分析的时候需要什么字段就抽取什么字段，入库的时候不需要理解这个日志的字段，它的好处就是非常灵活，不好的地方就是你没有做处理，分析的时候才出，这个分析查询的时间会比较大。我们是两种都支持，通常客户是把这两种方式结合在一起来用。



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

　　这个就是我们一些应用场景，比如我们保险公司和银行有营销和电商平台，可以分析它网站的访问日志，可以把它这些访问情况全部都显示出来，包括客户端用的什么操作系统，什么浏览器，包括访问次数，哪些运营商过来的，从哪些地方，我们有非常准确实时更新的IP地址库，我们可以精确到哪些区县进行访问的这些实时信息。



　　日志应用场景－安全分析
　　另外一个场景用在安全领域，这是一个真实的网站被黑客攻击导致网站无法道路，我们拿到日志大概2000万条，如果没有一个强大的工具从这2000万条里面找出攻击的根源是非常困难的，我们从这2000万条日志里面快速检索过滤，就把这个范围缩小到3600条日志，然后再进一步的根据一些关键词来搜索和分析，就找到攻击的根源。它是利用了什么漏洞，实际上它上传了PHP的文件，利用PHP的漏洞攻击这个网站，也找到了攻击的地址，非常快的找到这个根源，对安全来讲非常有用。这是安全分析的情况，知道时间点，攻击的IP地址，做了什么操作，从日志里面把这些信息都挖掘出来。



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

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

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

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

　　日志易2014年推出来，已在很多大企业都得到应用，包括像中国银行、国家电网、南方电网、中石油、中石化、中移动、中国电信、格力电器、上汽通用等都用到我们的系统，银行像新疆农信，华夏银行，保险公司像国联人寿等等都用到我们的系统，我们公司也入选北京中关村前沿技术企业，中关村有36家高科技企业入选，北京有三四万家高科技创业公司，能入选大概是千分之一的比例。我们产品主要用在日志分析及安全使用上。这是我们的微信号希望得到大家的关注，谢谢。