（案例篇）日志易：IT运维分析及海量日志搜索的实践之路（下）

客户案例

案例一：某大型综合金融机构

这是一个大型的综合金融机构，总部就在深圳，也是中国最大的。

他们之前需要逐台去登录服务器：没有办法集中查看日志;没有办法对海量日志进行挖掘和用户行为分析; 没有办法做多维度的查询，比如时间段、关键词、字段值;而且没有办法进行日志的业务逻辑分析和告警。

使用日志易产品后：建起日志云，在内部建立了一个私有云来处理日志，已经接入了一百多个应用，每天新增的日志量是8TB。做了日志云之后的好处是省去了登录服务器的操作，能够快速地查看，降低登录服务器的人为误操作的概率。对金融系统来说，这些生产线上的服务器是非常关键的。如果每个运维工程师都登录到生产线上的服务器去查看日志，一不小心，一个误操作，可能就影响了生产线上的应用，导致一次事故。上线日志易产品后，就禁止运维工程师登录服务器去看日志，所有看日志就在它内部的日志易云上来看，解决了需要日志统一管理的痛点。而且可以进行多维度的查询，提高定位异常原因的效率，可以对日志数据进行数据挖掘、用户行为分析，可以对系统的健康指数每天出报表。

现在很多用户用日志易，主要的一个功能是每天出报表给老板看，因为之前是用Hadoop，Hadoop是第二天出报表，用了日志易之后是当天6点钟的时候就可以出报表，让老板下班前看到当天的情况。而且可以事先告警，只要一出错，就马上告警，而不是事后去追查这个问题。

案例二：中移动某省分公司

用来分析营业厅业务办理的Web的日志，这里就用了SPL搜索处理语言，营业厅里面一笔交易是经过多个子系统的，每一个子系统都会产生日志。用了之后，就把一笔交易的每一笔子系统产生的日志给串起来，串起来之后还原成一笔交易，分析一笔交易的延时情况、响应情况。

图1 SPL示意图

图1 中的SPL就是在搜索框里写的，这还是比较短的，它搜索的字段就是“json.url”，通过管道符把前面搜索的结果传给后面的事务命令。因为不同子系统的日志都传给命令了，这个命令执行的操作是找ID，因为每一笔操作都是有一个独立ID的，根据这个ID把这一笔交易在不同子系统上产生的日志都串起来。串起来之后排一个顺序，是以查询作为起点，传入参数，事务命令的参数有stamp，还有ends，一笔事务是从查询开始的，以提交作为结束。但是如果一直不提交也会超时，超时的时间是30分钟，如果30分钟都不提交，就认为这笔事务超时了，这样就不会无限地等下去。通过这样一个事务的命令，把这个交易给串起来。

图2 业务日志数据串联

图2就是串起来之后的结果，这是我们的界面，这就是在搜索框里刚才写的搜索处理语言的程序，出来的结果就把这些交易全都串起来，一笔缴费业务，营业员所有操作都一目了然。它还得监控这些营业员，看这些营业员各自的效率怎么样。每个步骤所需要执行的时间都排好，包括网络处理时间、服务器处理时间，都排好序。这就是我们在中国移动山东省分公司做的一个案例。

案例三：国家电网

日志易产品主要用在安全信息事件管理，因为终端信息安全是日志的调查、分析、取证，它要到各省分公升去做审计，快速排查日志里的问题。