IT运维分析成新趋势

随着近几年大数据技术的兴起，业内开始把大数据技术应用到IT运维上进行分析，进而产生了IT运维分析ITOA。把大数据技术应用到IT运维上分析的目的是提高数据质量和效率，以及可用性监控、应用性能监控、故障根源分析、安全审计等方面的指标。根据权威的调查机构Gartner预测，到2017年15%的大企业会积极使用ITOA，尽管2014年这个数字只有5%，日志易首席执行官陈军表示ITOA是新生事物，正在被市场逐步接受。

多源的数据支持

ITOA将大数据技术应用在运维数据的分析上，数据的来源就非常重要。ITOA的数据来源主要分为四方面：第一是机器数据、服务器、网络设备产生的数据，简言之就是日志;第二是通信数据，如今网络普及，后台的设备很多都是大型的分布式系统，都有网络的通信;第三是代码级别进行统计分析，例如通过PHP、JAVA这些字节码来插入统计分析的代码，进而统计函数调用情况、堆站的使用情况等，从代码级别来进行统计分析会呈现更加精细化的成果，也可称为数据;第四是探针数据，例如全国用户访问IDC的延时是多少，必须在全国布点并发起模拟用户的请求探测，进行端到端延时方面的度量。

美国有一家运作ITOA的公司，他们做了一项用户调查来统计四种数据来源使用情况，其中日志的使用比例非常高，达86%，网络抓包达93%，插入代码数据是47%，探针数据是72%。日志与网络抓包占的比例非常高，占总体的80%-90%，这充分显示了日志数据采用的重要性。

日志无所不在，所有服务器、网络设备、应用系统都会产生日志，不同的应用输出的日志完整性与可用性不同。通信数据从网络流量统计的信息非常全面，但也有局限性，一些事件未必触发网络通信，如果没有触发网络通信的话就不会产生网络流量，也就没法做出统计。

数据潜入代码的使用比例较低，它的优势在于可以进行代码级别的精细监控，能看到代码的执行情况，但它也存在一定的侵入性。插入代码，执行时已经改变了原来程序的执行流程，每次执行都会插入代码，插入的代码可能会带来性能问题，降低被检测程序的性能。另外，还有安全、稳定性的顾虑，插入代码有没有把一些敏感信息窃取，插入的代码是不是足够稳定，如果插入代码崩溃则会导致被监测程序的一系列崩溃。

探针数据是用来模拟用户请求，完成端到端监控，可以从手机访问到服务器端到端的延时，但并不是真实的用户度量，业界希望度量到用户真正的延时情况，而不是模拟。例如像腾讯、百度类似的移动应用厂商，已经有数以亿计的终端用户，他们可以直接在手机应用端做真实的用户度量，可以看到真实用户的访问情况。2008年汶川地震的时候腾讯QQ客户端实时监测到汶川地区用户QQ掉线，马上知道那里发生了重大事故，做到了真实的网络度量。

海量日志的“前世”与“今生”

日志，学术性的说法是时间序列机器数据，因为它是带时间戳的机器数据，由网络设备、服务器产生，并包含IT系统很多信息，其中涉及服务器、网络设备、操作系统、应用软件，甚至包括用户、业务的信息。日志反映了事实数据，不管是数据中心还是企业发生的一切都会被记录下来。通过统计分析日志，不同系统之间的通信也可以通过日志传递信息。

日志呈现非结构化特征，如果要进行分析就要转化为结构化，一条日志包含的信息非常多，从统计分析的角度就会得出更多有价值的信息。日志可以用到哪些场景？首先是运维监控，保证系统的可用性，如果出现故障，能够及时地追溯根源并及时知道问题。

其次是应用性能监控，主要是得知性能的情况，例如网站的运转速度，缓慢的原因等，这些均属于应用性能监控。数据中心还有一条很重要的原则就是安全，要保证数据中心的安全，防止黑客的入侵。这可以用在安全审计方面，主要是安全信息事件管理、合规审计、发现高级持续威胁APT等。

日志如此重要，包含了那么多重要信息，以前怎么处理日志值得探讨。过去中小型公司不太重视日志，大型的企业正开始重视日志。企业日志没有集中管理，散落在各台服务器上，出了问题就登录到各台服务器上用脚本命令、用VI去查看日志，其中不乏一些水平高的运维工程师用AWK写一些脚本分析程序去分析日志，但是这样的做法也有问题。因为登录到各台服务器，这些服务器都是生产服务器，一不小心的错误操作可能会导致事故。

另外有的运维工程师把日志当做垃圾，看到磁盘空间达到极限，首先做的事情就是删除日志，删除日志后如果发现有些故障需要分析又找不到日志。后来业界开始重视日志，他们用数据库存储日志，这也是如今一个比较普遍的做法。原则上讲，数据库是用来存结构化数据的，日志是非结构化的数据，数据库有固定的Schema，为了让表的格式最大限度的灵活化，数据库就定义了三列，其中第一列是产生日志的机器IT地址，第二列是时间戳，第三列是日志本身的信息，把整个日志的文本当做一个字段放到数据库中，并没有针对日志中的信息进行抽取进行分析。现在产生的日志越来越多，每台服务器一天产生几GB甚至几十GB的数据，一个数据中心上千台服务器一天可能产生几TB的数据，数据库没办法适用TB级的海量日志。

如今，Hadoop出现后业界开始用Hadoop处理日志。首先Hadoop是批处理的框架，不够及时。用Hadoop处理分析都是今天看昨天的数据，或者是看几个小时之前的，最快也只能看到几十分钟之前的。要想看几秒钟之前的，Hadoop是做不到的。Hadoop的查询，虽然有Hef（音）这样的东西来做查询，但Hef的查询也非常慢，所以Hadoop基本是用来做数据的离线挖掘，没办法做在线数据分析。后来又开始出现了Storm、Spark，但这些都是使用框架，后来出现NoSQL，但没办法全文检索。可见在海量日志的处理方面还有很多可挖掘与突破的地方。

随着互联网的飞速发展以及Web日志数据的爆炸式增长，海量日志数据的处理越来越受到人们的关注。对这些海量日志的数据挖掘，可以从中分析用户的行为特征，获取用户属性，也可以发现用户访问网站页面的模型与访问习惯，为网站管理员优化网站页面设计提供有效依据，但这只是未来发展方向之一。