IT 运维分析及海量日志搜索分析的实践之路

内容简介：

IT运维分析（IT Operation Analytics, ITOA）是近年兴起，其把大数据技术应用于分析IT运维产生的大量数据，数据来源主要有日志、网络流量、植入代码、布点模拟监控等。过去使用数据库处理日志无法支持大数据量，后来出现了使用Hadoop/Storm/SparkStreaming等开发框架来处理日志，及最新的使用实时搜索分析引擎来对日志进行实时处理。现如今使用Hadoop/Storm/SparkStreaming等开发框架来处理日志已经在各大公司被广泛的运用，本次演讲嘉宾将结合具体实践为大家带来如何使用实时搜索分析引擎来对日志进行实时处理。

本文为日志易创始人兼CEO陈军，在2016年GOPS全球运维大会.深圳站的演讲实录，包括介绍ITOA，比较各种日志处理技术等话题，重点讲解实时日志搜索分析引擎，比较索引阶段对日志做结构化（Schema on Write）及检索阶段对日志做结构化（Schema on Read），在搜索框里编写搜索处理语言（Search Processing Language, SPL）以灵活地支持各种业务分析，及在金融的应用案例。

陈军：

谢谢那么多人来参加这个大会，感谢这个机会。刚才前面有一位朋友问到日志分析的情况，日志易就是专门做日志分析的，我也专门讲一下日志。实际上日志只是一个方面，我今天要讲的是一个更大的话题，《IT运维分析与海量日志搜索》。

IT运维分析

“IT运维分析”是这两年新提出来的概念，过去那么多年我们一直在讲的运维，实际上讲的是运维管理，即ITOM。

而ITOA是这两年随着大数据技术的产生而产生的，它就是把大数据的技术用在IT运维产生的数据上面。

因为IT运维本身就会产生大量的数据，用大数据的技术去处理IT运维产生的数据，来提高IT运维的效率。它的用途是在可用性监控、应用性能监控、故障根源分析、安全审计这些方面。

据Gartner估计，到2017年15%的大企业会积极使用ITOA，在2014年的时候这个数字只有5%。这个报告还是基于欧美的市场，欧美IT方面的投入更大、更加精细化，在他们那里才做到明年有15%的大企业积极用ITOA。

很多公司还停留在ITOM（IT运维管理）的阶段，ITOA是一个新的阶段，要去做分析，分析之后来提升管理水平。

ITOA的四种数据来源

ITOA是把大数据的技术用在IT运维产生的数据上面，所以数据的来源就很重要，它分析些什么数据？

1 机器数据: 其实主要就是日志，服务器、网络设备产生的数据；
2 通信数据: 实际上就是网络抓包，这些流量的数据，把它抓包解包之后会产生大量的数据；
3 代理数据: 在.NET/Java这些字节码里面插入你的监控代码，去统计函数调用的情况、堆栈使用的情况，在代码这一级来进行分析，插入代码也可以获得一些程序执行的数据；
4 探针数据: 在全国各地布点来模拟用户的请求，来发起ICMP的ping、HTTP GET这种请求，对系统进行检测，看延时的情况、响应的情况。

所以，ITOA就是围绕着这四种数据来源，使用大数据的技术来做分析。

美国一家ITOA公司做的用户调查，这四种数据来源使用占比，大家可以看到：日志占86%，流量抓包占93%，代理数据占47%，拟检测占72%。这是美国一家公司做的调查，这个数据背后其实也是有理由可以解释的。

ITOA四种数据来源的比较

1、 机器数据：

日志无处不在，网络、设备、服务器、应用程序都会产生日志，比较全。但是它也有它的情况，不同的应用可能吐出来的日志包含的信息不一样，有的应用可能吐出更多的日志，包含的信息比较面；有的日志可能吐出来的日志非常少，只有出错的时候吐出日志，正常情况下都不吐出日志。所以，可能你能够获得的信息不够，日志内容的完整性和可用性不太一样。

2、 通信数据:

这个信息也非常全面，只要有通信，你就可以抓包。它的问题是什么呢？ 有一些事件未必触发了网络流量，如果没有触发网络流量，你就抓不了包。另外，有些包可能是加密的，你抓了之后解不了密，不知道里面的内容，或者里面很多应用层解析的规则你不清楚，没有办法解析，不知道它包含的意义。它用的都是二进制的，你这个解包，每一种应用你都需要专门自己开发解包的规则，去把它给解出来。

3、代理数据：

就是在字节码里嵌入你的统计分析代码来进行监控，它是一个代码级的监控分析，它是非常精细化的，精细到代码这一级，哪一个指令被调用了多少次，在这一级做统计分析。但是它有它的问题，它是具有侵入性的。当你做这种分析的时候，你已经改变了这个程序，你在原有的生产线上植入了你的代码，你植入了代码：如果稳定性有问题，可能导致进程崩溃。还有安全的问题，你植入的代码会不会把敏感的信息拿走？

哪怕解决了稳定性和安全性的问题，植入的代码每一次又会被执行，可能也会造成性能的影响。这就有点像量子力学的“测不准”原理，你观测这个量子的时候，你的观测行为就改变了它，你观测得到的东西实际上不是最真实的，并不是它原来执行的情况。

4、探针数据:

模拟用户请求，现在市面上也有一些产品。他们在全国可能有几百个节点，它布节点，不断地对你的后台服务器发起请求，来监测全国各地的用户访问你的服务的情况，包括网络的延时。它是一种模拟监控，而且是端到端的监控，好处是可以模拟从客户端一直到服务器请求到响应等来回的种类的延时。

但是它就不是真实的用户度量，现在讲监控监测都讲真实的用户度量。对于服务商来讲，他关心的是真实的用户感受到的延时，而不是一个模拟的请求。当然，模拟的请求发现慢了，可能是网络出问题了，立即要采取行动。

• 一些小的应用，因为他们没有办法在全国布点，日活量不够，那可能会用这种方式。
• 像大的应用，不管是微信，淘宝，这种每天的活跃用户都是过亿的，全国到县区这一级都有大量的用户。

其实他们是不太需要用这种探针数据去模拟用户请求的，他们直接统计真实的用户请求就知道网络状况，而且他们要做这个事情可以直接来做，不需要用第三方的应用。我记得08年汶川地震的时候，腾讯QQ的后台马上就看到汶川地区的QQ用户下线了。所以，这种大的应用直接就可以知道网络的状况。可以看到，这四种数据来源中，具有侵入性的是代理数据，日志和网络流量都是旁路的，网络也是通过镜像流量旁路来抓包的。

日志数据、通信数据、探针数据这三类对应用本身是没有产生直接影响的，但是代理数据是会对应用直接产生影响。所以，这也说明了为什么代理数据的使用百分比是比较低的，而日志和网络抓包是非常高的，也就是了这个理。

日志：时间序列机器数据

首先，它是从服务器、网络设备和应用软件这些机器上产生的，甚至现在智能设备越来越多了，传感器等这些都会产生日志。它还有一个很特别的地方是时间序列，为什么叫时间序列？日志一个很重要的东西是带时间戳，基本上我们很少见到没带时间戳的日志。我们是一个第三方的独立厂商，是卖工具给各种类型用户的，所以各种各样很奇葩的问题都会遇到，比如说：

• 有的客户日志真的没有带时间戳的，带多个时间戳的也有,一条日志里带了好多时间戳。

• 还有时间戳的格式有近百种，标准的时间戳日志是放在比较靠前的，有的是时间戳放在靠后，都有，它的位置也不固定。

日志包含的信息：

• 日志包含了IT的系统信息，比如：服务器的信息，网络设备的信息，操作系统的信息，应用软件的信息；
• 日志也包括用户的信息，用户的行为信息；

• 也可能包括业务的信息。

所以，日志反映了IT系统的事实数据。LinkIn这家公司是硅谷很有名的做职业社交的公司，它在大数据方面是走得比较前的。他们的工程师写了一篇文章叫《深度解析LinkIn大数据平台》，有中译本，在CSDN上，大家可以搜索一下。非常长，十几页，它的中文翻译跟原来的英文名称是不太一样的，你看中文的名称好象跟日志没啥关系。但是你要看它原文的名称，意思是“每一个软件工程师需要知道的实时数据的统一的抽象”。

日志是一个什么东西？

是每一个软件工程师必须知道的实时的、数据的一种统一的一种抽象，LinkIn是把日志做到极致了，LinkIn里面很多不同业务系统之间的对接都通过日志。Kafka现在是用得最广泛的消息系统。Kafka这个消息系统是在LinkIn十多年前发明的，十多年前上线，就是用来处理日志、传输日志的，把日志在不同的系统之间流转。所以，有兴趣的同学可以看一下这个文章。

越来越多的公司也意识到日志需要统一来管。我之前工作过不同的公司，公司一大了之后，内部有好多部门，不同的业务，每一个业务部门统计分析自己的业务数据，然后报给老板。这些报上来的数据可能都互相打架，这边讲得非常好，那边看出来好象不太那么好，各个部门有自己的动机和利益，统计出来的东西不完全客观。所以，有的公司老板就意识到这个问题了。

日志集中管理，不同业务部门的日志全部交给一个部门来负责，他们会成立大数据部来统一处理日志，把不同业务系统的日志对照着来看，就会更加协调，更加统一，数据更加对得上号。这个大数据部门就像国家统计局这样的角色，各省说它的GDP是多少，还得看它的用电量。从其他角度来看，日志就是非常重要的角度来看业务的情况，包括日活是多少，每天新增的用户是多少，这些全部在日志中可以看出来。

一条Apache Access日志

大家对Apache日志比较熟悉，Apache日志也是一个包含信息量非常丰富的日志。首先，它是一个文本数据，它带来了时间戳、主机名、产生这条日志的IP、字段。

我们把每一个字段抽出来：

• IP地址叫Client IP;
• 时间戳叫Timestamp;
• POST，我们给它这个字段名称叫Method;
• report叫URI;
• 这个HTTP的版本1.1，Version;
• 这个状态码是200;
• 21是字节;
• 从哪里过来访问的;
• User Agent也比较重要，客户端那边是什么操作系统、什么浏览器;
• 0.005是本台服务器响应的时间;
• 0.001是后面应用服务其的响应时间。

所以，从这一条日志中可以分析出来的东西就非常多，可以做业务分析，也可以做应用性能的监控。你的响应时间是多少就可以监控，是不是网站慢了，是不是堵了，甚至从URI这里可以看出安全审计，你是不是被安全攻击了。所以，日志包含的信息是非常丰富的。

日志的应用场景

• 运维监控：可用性监控、应用性能监控
• 安全审计：安全信息事件管理、合规审计、发现高级持续威胁
• 用户及业务统计分析

谷歌的安全做到没有内网了，它认为内网是不安全的，内网和外网是一样的，内网得做很多防护。其实APT这种技术就是认为没有内网，内网是不安全的，所以才需要APT。如果内网是安全的，我在外面放道防火墙就足够了，就像你家有个大铁门，但是小偷爬墙进来，爬窗进来，甚至挖个地洞进来，甚至现在还有无人机了，从窗户飞进来。所以，你必须得全方位地监控，全方位地监控流量和日志，做APT最重要的就是这两个数据来源。

现在及过去的做法

过去

1、很多小公司没有集中管理日志，扔在那里，觉得日志是个负担，出现问题才登录到这台服务器，用一些脚本命令，或者写一些简单的脚本程序去查一下日志，大部分公司还是停留在这样的阶段。

2、服务器的硬盘满了，首先第一件事就是去删掉垃圾。日志是有时间效应的，太久之前的日志是没有什么用的，特别是对运维工程师来讲，关心的可能就是今天的日志或者昨天的日志，出现问题了从日志里看是什么问题。对安全工程师来讲，这个日志需要的时间就要长了，有些渗透攻击可能是几个月、一年之前发生的，得去查。黑客如果入侵了系统，聪明一点的黑客第一件事可能就是删除日志，把自己入侵的痕迹抹除掉，因为他的登录行为都在日志中反映出来。

3、日志在过去只做事后的追查，没有实时的监控分析。出现错误不能预先知道，都是已经知道错了，然后到日志去找原因，日志没有作为一种监控的手段，只是用来作为追溯根源的手段而已。

4、一些公司开始意识到日志的重要性了，开始把日志管起来，但是管的方法不对，用数据库来管日志。

其实市面上也有一些所谓的日志管理分析产品都是基于数据库的，基于数据库有什么问题呢？
首先，这些日志越来越多，可能海量的日志每天上TB。

我们现在日志易在生产线上跑，在乐视跑每天新增日志量是20TB。

这样一种日志的量，你用数据库是根本没有办法处理的，而且数据库是用来处理结构化数据的，非结构化数据是没有办法处理的。

所以，我看过一些用数据库处理日志的产品，数据库有所谓的表格式，但是这个表就三列： IP地址，产生日志的主机名、时间戳，日志文本信息。所以，他没有对日志做任何的字段抽取，又不支持全文检索，有时候搜一条日志得把整条日志的信息写全了才能搜出来，否则搜不出来所以，数据库处理日志是一种非常落后、过时的方法。

近年

随着大数据技术的出现，就出现了像Hadoop这样的框架了，大部分互联网公司目前都是用Hadoop处理日志的。但是Hadoop处理日志又有什么问题呢？Hadoop是批处理的，不够实时。用Hadoop处理日志通常是晚上处理当天的日志，第二天早上十点钟或者九点钟上班可以看到前一天的日志统计分析的情况，或者有时候要查一些东西也得跑个几小时才能看到日志的情况，而且查询也慢。

我06年到09年在Google美国总部的时候是做网页抓取爬虫。当时是每天3000台服务器的一个集群，每天爬一百多个网站。全世界的网站都爬下来了，但是不是说全部，一部分有的更新慢，有的网站几天才访问一次，有的是每天要去访问。爬这些不同的网站，出现错误的信息就千差万别、千奇百怪，都得看日志。出现了新的错误或者新加了一个功能的时候，原来的程序是处理不了的。当时我在Google，经常每天早上上班的第一件事是先看一下日志:有一些错误信息是无法确认的，不能归类的;不能归类的那部分我马上写一个小的程序，可能也就几十行;写完之后去跑，跑下来可能几十分钟甚至一两个小时，可能到下午才能出现结果。

所以，Hadoop的东西是给开发人员用的，不是给运维人员用的，它还得写程序，而且它是做离线挖掘，没有办法做在线分析。所以，对于运维工程师来说，你要让他用Hadoop，顶多用Hive来查一下。当然，每次运维工程师可能都得求助于开发工程师再改一下Hadoop的程序来处理。

后来，为了解决实时性的问题，又出现了Storm、Spark这些性能更好的流式处理，但是不管是Hadoop、Storm、Spark，它都是一个开发框架，不是一个拿来就可以用的产品。另外可能又有一些工程师用NoSql，NoSql的方案也很多，但是NoSql不支持全文检索，它不是一个搜索引擎，你只能是检索它对应的值是什么，并不能够直接搜一个日志的信息。

现在

现在我们需要一种新的技术对日志进行实时的搜索分析，就是所谓的日志的实时搜索分析引擎，它有什么特点：

• 快：日志从产生到搜索、分析出结果，只有几秒钟的延时，我马上要知道信息。日志里出现了一个错误的信息，不会像Apache出来一个500的状态码，500意味着后台的应用服务器出错了，运维工程师是最担心的，出了500的状态码马上进行告警，以前可能是用脚本写一些工具来做告警。但是你用日志实时搜索分析马上可以告诉你这个500出现了多少次。
• 大：每天要能够处理DT级的日志量。
• 灵活：它是IT工程师的搜索引擎，是所谓的Google for IT，它可以搜索分析任何的日志、日志里任何的字段。

• Fast Big Data：大而快的数据，不仅仅是一个大数据，是一个事实大数据。

日志搜索引擎

日志管理系统的进化

最早的1.0用数据库来做日志，到2.0用Hadoop或者NoSql，到3.0就是实时搜索引擎，我们现在就进入到日志3.0的阶段。

日志易亮点

• 日志易就是一个可编程的日志实时搜索分析平台。
• 搜索处理语言（SPL）
  有一个搜索框，光有一个搜索框让你搜东西太基本了，我们是运维工程师，我们具备一定的脚本编程能力，它的可编程在哪里？日志易可以在搜索框里编写脚本语言。我们实现了脚本语言的搜索处理语言，它包括管道服务。你有多个命令，用管道服务把这些命令串起来，跟你在Linux脚本里面命令行写脚本一样，有很多小的命令执行单元操作，再用管道服务把这些单元操作给串起来。所以，写这种SPL的脚本就可以完成这种复杂的查询付息。
  这样，这个产品就变得非常灵活强大了，用户的业务是千差万别、千变万化的，我们不需要把业务定制到产品里，而是提供基础的平台，让用户直接在搜索框里去写脚本语言来做这种定制化，就可以适应不同的应用场景。任何的应用场景都可以在搜索框里写这种脚本程序，这种脚本程序可能是几十行，甚至是上百行的脚本程序，来进行复杂的分析处理。
• 日志易可以接入多种的数据来源:可以是日志文件;可以是数据库里的;甚至我们给券商做的恒生电子交易系统，它产生的日志是二进制格式的，我们调用了恒生电子交易系统提供的Java API来把它解码成文本格式。
• 我们提供企业部署版，也提供SaaS版，SaaS版是每天上传500MB的字节处理免费，欢迎大家试用，在我们的网站上有。

日志易功能

• 搜索。
• 告警。基于搜索结果，某个字段出现了多少次，可以去告警；
• 统计。进行统计分析，可以进行事务关联，不同系统产生的日志可以关联起来。
• 配置解析规则，识别任何日志。

刚才前面的演讲，有一位同学问到日志多种多样，要不要对日志归一化、统一日志格式？当然，如果你能够说服开发人员去改系统去统一日志格式是最好的，但是现实的现有的系统没有人愿意去改，就没有办法去统一日志的规格。日志易强大的地方是可以让用户在Web界面上配置解析规则，来抽取里面的字段，把日志从非结构化数据转成结构化数据，就可以对每个字段进行统计分析，非常强大灵活。任何格式的日志我们都可以把它从非结构化数据转成结构化数据；

这里讲的是日志进入日志易系统时就抽取字段做结构化，是所谓的Schema on Write，好处是日志在入库前做结构化预处理，检索速度快，不好的地方是不够灵活，用户可能在检索日志的时候，才确认需要抽取什么字段。为了适应这种场景，日志易也实现了Schema on Read，支持检索阶段使用SPL的Parse命令，抽取用户想要的字段，非常灵活。日志易同时支持Schema on Write 及 Schema on Read，由用户根据使用场景决定使用哪种方式，非常灵活、强大。

• 安全攻击自动识别的功能；
• 开放API，可以让用户在上面做二次开发，对接第三方系统；
• 高性能、可扩展分布式系统。现在在乐视那里跑到每天20TB，每秒钟峰值达到100万条的处理量。

因内容文字限定，本文未完结，剩余内容请看本账号文章《日志易：IT运维分析及海量日志搜索的实践之路（下）》