2023年7月9日发(作者：)

⽇志易：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的阶段。⽇志易亮点⽇志易就是⼀个可编程的⽇志实时搜索分析平台。有⼀个搜索框，光有⼀个搜索框让你搜东西太基本了，我们是运维⼯程师，我们具备⼀定的脚本编程能⼒，它的可编程在哪⾥？⽇志易可以在搜索框⾥编写脚本语⾔。我们实现了脚本语⾔的搜索处理语⾔，它包括管道服务。你有多个命令，⽤管道服务把这些命令串起来，跟你在Linux脚本⾥⾯命令⾏写脚本⼀样，有很多⼩的命令执⾏单元操作，再⽤管道服务把这些单元操作给串起来。所以，写这种SPL的脚本就可以完成这种复杂的查询付息。这样，这个产品就变得⾮常灵活强⼤了，⽤户的业务是千差万别、千变万化的，我们不需要把业务定制到产品⾥，⽽是提供基础的平台，让⽤户直接在搜索框⾥去写脚本语⾔来做这种定制化，就可以适应不同的应⽤场景。任何的应⽤场景都可以在搜索框⾥写这种脚本程序，这种脚本程序可能是⼏⼗⾏，甚⾄是上百⾏的脚本程序，来进⾏复杂的分析处理。⽇志易可以接⼊多种的数据来源:可以是⽇志⽂件;可以是数据库⾥的;甚⾄我们给券商做的恒⽣电⼦交易系统，它产⽣的⽇志是⼆进制格式的，我们调⽤了恒⽣电⼦交易系统提供的Java API来把它解码成⽂本格式。我们提供企业部署版，也提供SaaS版，SaaS版是每天上传500MB的字节处理免费，欢迎⼤家试⽤，在我们的⽹站上有。⽇志易功能搜索。告警。基于搜索结果，某个字段出现了多少次，可以去告警；统计。进⾏统计分析，可以进⾏事务关联，不同系统产⽣的⽇志可以关联起来。配置解析规则，识别任何⽇志。刚才前⾯的演讲，有⼀位同学问到⽇志多种多样，要不要对⽇志归⼀化、统⼀⽇志格式？当然，如果你能够说服开发⼈员去改系统去统⼀⽇志格式是最好的，但是现实的现有的系统没有⼈愿意去改，就没有办法去统⼀⽇志的规格。⽇志易强⼤的地⽅是可以让⽤户在Web界⾯上配置解析规则，来抽取⾥⾯的字段，把⽇志从⾮结构化数据转成结构化数据，就可以对每个字段进⾏统计分析，⾮常强⼤灵活。任何格式的⽇志我们都可以把它从⾮结构化数据转成结构化数据；这⾥讲的是⽇志进⼊⽇志易系统时就抽取字段做结构化，是所谓的Schema on Write，好处是⽇志在⼊库前做结构化预处理，检索速度快，不好的地⽅是不够灵活，⽤户可能在检索⽇志的时候，才确认需要抽取什么字段。为了适应这种场景，⽇志易也实现了Schema onRead，⽀持检索阶段使⽤SPL的Parse命令，抽取⽤户想要的字段，⾮常灵活。⽇志易同时⽀持Schema on Write 及 Schema onRead，由⽤户根据使⽤场景决定使⽤哪种⽅式，⾮常灵活、强⼤。安全攻击⾃动识别的功能；开放API，可以让⽤户在上⾯做⼆次开发，对接第三⽅系统；⾼性能、可扩展分布式系统。现在在乐视那⾥跑到每天20TB，每秒钟峰值达到100万条的处理量。因内容⽂字限定，本⽂未完结，剩余内容请看本账号⽂章《⽇志易：IT运维分析及海量⽇志搜索的实践之路（下）》⽇志易提供部署版产品，SaaS版产品在阿⾥云的体验⼊⼝：简介：⽇志易专注⽇志分析领域，产品做得像Google搜索引擎⼀样强⼤、灵活、易⽤。⽬前，⽇志易产品已成功应⽤于⾦融、能源、运营商及互联⽹等诸多⾏业，其中⾦融客户包括中国银⾏、新疆农信、鹏华基⾦及第三⽅⽀付公司等；能源⾏业客户已囊括国家电⽹、南⽅电⽹、中⽯油、中⽯化等国内知名企业；移动、电信等国内主流运营商以及⼩⽶、乐视、⽹宿科技等诸多明星互联⽹企业均已牵⼿⽇志易——⽬前⽇志易⼤客户已达百余家。⽇志易对运维⽇志及业务⽇志进⾏实时采集、搜索、分析及可视化等，⽤于运维监控、安全审计、业务数据分析，最终发掘出数据价值。