本文根据〖2016 全球运维大会•深圳站〗现场演讲嘉宾分享内容整理而成。
讲师简介：陈军
17年IT及互联网研发管理经验，曾就职于Cisco、Google、腾讯和高德软件，历任高级软件工程师、专家工程师、技术总监、技术副总裁等岗位。他发明了四项计算机网络和分布式系统的美国专利，拥有美国加州大学计算机硕士学位。
导言
陈军：谢谢那么多人来参加这个大会，感谢这个机会。刚才前面有一位朋友问到日志分析的情况，日志易就是专门做日志分析的，我也专门讲一下日志。
实际上日志只是一个方面，我今天要讲的是一个更大的话题，《IT运维分析与海量日志搜索》。
IT运维分析
“IT运维分析”是这两年新提出来的概念，过去那么多年我们一直在讲的运维，实际上讲的是运维管理，即ITOM。
而ITOA是这两年随着大数据技术的产生而产生的，它就是把大数据的技术用在IT运维产生的数据上面。
因为IT运维本身就会产生大量的数据，用大数据的技术去处理IT运维产生的数据，来提高IT运维的效率。它的用途是在可用性监控、应用性能监控、故障根源分析、安全审计这些方面。
据Gartner估计，到2017年15%的大企业会积极使用ITOA，在2014年的时候这个数字只有5%。这个报告还是基于欧美的市场，欧美IT方面的投入更大、更加精细化，在他们那里才做到明年有15%的大企业积极用ITOA。
很多公司还停留在ITOM（IT运维管理）的阶段，ITOA是一个新的阶段，要去做分析，分析之后来提升管理水平。
ITOA的四种数据来源
ITOA是把大数据的技术用在IT运维产生的数据上面，所以数据的来源就很重要，它分析些什么数据？
机器数据: 其实主要就是日志，服务器、网络设备产生的数据；
通信数据: 实际上就是网络抓包，这些流量的数据，把它抓包解包之后会产生大量的数据；
代理数据: 在.NET/Java这些字节码里面插入你的监控代码，去统计函数调用的情况、堆栈使用的情况，在代码这一级来进行分析，插入代码也可以获得一些程序执行的数据；
探针数据: 在全国各地布点来模拟用户的请求，来发起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界面上配置解析规则，来抽取里面的字段，把日志从非结构化数据转成结构化数据，就可以对每个字段进行统计分析，非常强大灵活。
任何格式的日志我们都可以把它从非结构化数据转成结构化数据；
安全攻击自动识别的功能；
开放API，可以让用户在上面做二次开发，对接第三方系统；
高性能、可扩展分布式系统。现在在乐视那里跑到每天20TB，每秒钟峰值达到100万条的处理量。
案例
案例一：某大型综合金融机构
这是一个大型的综合金融机构，总部就在深圳，也是中国最大的。
他们之前需要逐台去登录服务器：
没有办法集中查看日志;
没有办法对海量日志进行挖掘和用户行为分析;
而且没有办法做多维度的查询，比如时间段、关键词、字段值;
而且没有办法进行日志的业务逻辑分析和告警。
在之后：
建起日志云，在内部建立了一个私有云来处理日志，已经接入了一百多个应用，每天新增的日志量是8TB。
做了这个之后的好处是省去了登录服务器的操作，就能够快速地查看，降低登录服务器的人为误操作的概率。
对金融系统来说，这些生产线上的服务器是非常关键的。
如果每个运维工程师都登录到生产线上的服务器去查看日志，一不小心，一个误操作，可能就影响了生产线上的应用，就导致一次事故。
上了日志易之后，就禁止运维工程师登录服务器去看日志，所有看日志就在它内部的日志易云上来看，解决了需要日志统一管理的痛点。
而且可以进行多维度的查询，提高定位异常原因的效率，可以对日志数据进行数据挖掘、用户行为分析，可以对系统的健康指数每天出报表。
现在很多用户用日志易主要的一个功能是每天出报表给老板看，因为之前是用Hadoop，Hadoop是第二天出昨天的报表，用了日志易之后是当天6点钟的时候就可以出报表，让老板下班前看到当天的情况。
而且可以是事先告警，只要一出错，就马上告警，而不是事后去追查这个问题。
案例二：中移动某省分公司
用来分析营业厅业务办理的Web的日志，这里就用了SPL搜索处理语言，营业厅里面一笔交易是经过多个子系统的，每一个子系统都会产生日志。
用了之后，就把一笔交易的每一笔子系统产生的日志给串起来，串起来之后还原成一笔交易，分析一笔交易的延时情况、响应情况。
这就是在搜索框里写的，这还是比较短的，它搜索的字段就是“json.url”，通过管道符把前面搜索的结果传给后面的事务命令。
因为不同子系统的日志都传给命令了，这个命令执行的操作是找ID，因为每一笔操作都是有一个独立ID的，根据这个ID把这一笔交易在不同子系统上产生的日志都串起来。
串起来之后排一个顺序，是以查询作为起点，传入参数，事务命令的参数有stamp，还有ends，一笔事务是从查询开始的，以提交作为结束。
但是如果一直不提交也会超时，超时间的时间是30分钟，如果30分钟都不提交，就认为这笔事务就够了，就超时了，这样就不会无限地等下去。通过这样一个事务的命令，把这个交易给串起来。
这就是串起来之后的结果，这是我们的界面，这就是在搜索框里刚才写的搜索处理语言的程序，出来的结果就把这些交易全都串起来，一笔缴费业务，营业员所有操作都一目了然。
它还得监控这些营业员，看这些营业员各自的效率怎么样。
每个步骤所需要执行的时间都排好，包括网络处理时间、服务器处理时间，都排好序。
这就是我们在中国移动山东省分公司做的一个案例。
案例三：国家电网
主要用在安全信息事件管理，因为终端信息安全是日志的调查、分析、取证，它要到各省分公升去做审计，快速排查日志里的问题。
合作客户
Q&A
Q：我有几点疑问，第一，站在运维的角度，日志管理只是运维中的一部分，在我看来，它的价值是可以集中管理，可以集中查看。另外，把我平常查看日志里面，我要搜keywords，根据我的经验去发现问题，最重要的是业务要产生价值。
那么，从这一点来看，假如说拥有日志易，肯定要通过API对接，把我的经验放在这个平台上，形成规则，这样的一个思路。日志易API是不是开放的？
陈军：非常好的问题，日志易对标的是美国的一家公司叫做Splunk，那家公司做了十几年，那家公司上面有五百多个应用，已经做成了平台，比如Cisco的日志是一个应用，某个防火墙的日志又是一个应用，它的上面好多应用。
回答你刚才问的这个问题，日志易也开放了这种API，把运维工程师的经验积累下来，它可以基于API来开展一些应用。
另外，你的一些经验，可能是通过SPL，写了就可以保存下来，共享给其他同事，他们就直接点击保存搜索，就来运行你之前写的SPL这个脚本处理语言，来分析出同样的结果，来做同样的分析。
Q：第二个问题，刚才举到乐视的例子，一百万条数据，这一百万条数据是产生数据完之后，多长时间我就可以索引到它？
陈军：只有大概几秒到十几秒。
Q：无论是在线版本还是离线版本都可以，是吧？
陈军：都可以。
Q：你好，我是华为公有云运维的，我们接触到两种类型：一种是Splunk，它号称自己是没有schema，它是后分析；还有一种是ELK，ELK是事先分析schema。事先分析可能统计比较快。不知道日志易是哪种流派？
陈军：非常好的问题，这是设计上就需要考虑的问题，其实也是我们反复想的一个问题。
两个流派，一种叫Schema on Read:
一种叫Schema on Write，在写的时候就要有schema，Splunk 这种叫做Schema on Read，在读的时候、查询的时候才会产生schema，才会做结构化，这样的好处是非常灵活。
日志进来之前你不知道该抽取什么字段，你不知道它的schema就把它做全文索引存下来了，然后检索分析的时候再去抽取字段，做schema，灵活。
灵活，任何东西都有代价，代价是检索非常慢，一次检索可能是几十秒钟，甚至几十分钟都有，因为你在检索的时候才去做这个schema。
另外一种ELK，叫做Schema on Write，你写的时候就先把schema给抽出来，再做索引，就不够灵活。可能检索的时候发现原来抽的字段是不对的，得把这个日志重新搞一遍，很麻烦。
但是它的好处是检索非常快，几秒钟就检索出来了，分析出来了。
日志易目前是Schema on Read，但是我们也在开发Schema on Write。
其实这些东西都是可配置的，系统设计的一个理念是去实现这个机制，把这个策略交给用户，用户自己可以选Schema on Read还是Schema on Write，我们两种都支持它，其实两种都有它的好处，都有它的坏处，用处自己做评判，自己做选择。
现在这个东西比较新，还得不断培育教育这个市场，他们用得还没有上升到那么高级的水平，大部分Schema on Write是可以接受的。
但是也有一部分已经反映不够灵活，这种少量比较高级的用户用到比较高阶的阶段了，Schema on Read的要求了。
Q：乐视的20TB，每天是多少主机?
陈军：几十台可以处理这样的数据量，产生就非常多了，我们有Agent，集中管理几千个Agent，这个Agent可以对日志进行限流、压缩、加密、脱敏等等。
Q：在Java里面有一个Eclipse报错，这个不是看一条一条的，是上下多少行，这种您是怎么处理的？
陈军：这个很简单，我们配解析规则，而且这些解析规则是内置的，都不用用户去配的。
这个Eclipse非常多行，但是它都有特征，有空了多少格、有缩进，都有规则，根据规则把多行日志归成一条日志，它虽然是多，但是它是一条日志。