过去，日志是没有集中处理的，出了问题之后运维工程师登录到每一台服务机或者用脚本命令或者程序查看日志，然后硬盘满了这个日志就被删除。黑客入侵系统之后首先就是删除日志来抹去入侵痕迹。而且通常日志只做事后追查没有事中监控和分析。后来一些公司也管理日志，但是用了错误的方法来管理日志，就是用数据库管理日志。数据库是一种不适当的方法来处理日志的，因数据库是针对结构化数据的，而日志是非结构化数据，而且也没办法适应每天产生TB级海量日志。而且数据库都有所谓的Schema，就是表格式，日志的格式是千变万化的，当你日志格式换了一种之后，这个数据库又不适用了，而且数据库没有办法提供全文检索。

 

　　我看到市面上有一些用数据库来处理日志的解决方案，他们数据库的表格就三列，第一列是主机的IP地址，第二列是时间戳，第三列是日志本身。他没有对日志进行结构化、抽取字段，来进行分析处理。

 

　　近年来随着大数据技术出现，开始用Hadoop处理日志。其实现在大部分公司处理日志都是用Hadoop来处理。Hadoop有什么问题？它是批处理框架，不够及时，没有办法做实时分析，查询也很慢。所以Hadoop更多用于数据离线挖掘，无法做在线的分析。后来又出现更快的技术，比如说用Storm、Spark Streaming

 

　　技术做流式处理。但不管是哪个都是一个开发框架，不是拿来就可以用的产品。所以通常BAT都是用这些框架来处理日志，一些大银行他们如果想用这种技术处理，通常就是找外面的公司，变成做项目的形式来给他们提供框架，结合他们的业务来开发。后来又有些用NoSQL的存储方案处理日志，但是NoSQL又不支持全文检索。

 

　　现在我们需要对日志进行实时搜索分析，需要实时搜索分析引擎。就是把搜索的技术用在日志上。我们知道搜索是非常方便的，当你碰到什么问题打开百度或Google就可以搜出来，我们希望对日志也是一样，你想查某一个字段，什么用户在什么时间做了什么操作，我们希望给它搜出来，所以日志搜索引擎有什么特点？一个是快，日志从产生到出结果只有几秒钟延迟；二是要大，每天能够处理TB级日志；三是灵活，运维工程师用的Google，可以搜索分析任何日志。这样的技术就是，Fast Big data。大数据讲的多了都是Big Data。这个是实时的大数据，是Fast Big Data。

 

　　日志系统的进化。从1.0用数据库，前面讲了数据库很多问题，不适合日志。到2.0用Hadoop、NoSQL，但Hadoop是开发框架，你得养起一个开发团队来做这样的事情。到3.0是拿来就可以用的实时搜索分析引擎。

 

　　日志易亮点，他是可编程的日志实时搜索分析平台。这里还多了一个可编程，可编程是什么意思呢？因为我们碰到，在不同用户内，他的业务场景千变万化，一种就变成做项目，把客户的需求解决方案做进我们的产品里面，但我们是希望有一种更方便的做法，我们是在搜索框，日志易实现了搜索处理语言，叫做“Search Processing Language, SPL”，它是类似于一种脚本语言，它用管道把多个命令给串联起来，然后在搜索框里写SPL脚本可以完成复杂的查询分析，这样的话用户的各种千变万化的场景都可以通过在搜索框里写SPL程序来实现。在搜索框了写SPL程序可能是几十行甚至是几百行的一个非常复杂的脚本程序。就是说日志易是提供一个基本的平台产品，通过日志易的售前工程师或者合作伙伴来给客户做部署实施，完成复杂的分析。而且可以接入各种来源的数据，包括像恒生电子交易系统这种二进制的数据也可以接入，我们有部署版也有SaaS版。

 

　　我们在处理非结构化数据时，一个很重要的概念，一种是Schema on Write，一种是Schema on Read。就是说你在什么时候对这个数据进行结构化，一种就是数据进来，入库之前结构化，这种叫Schema on Write。就是预处理，先结构化。这种的好处就是你在检索时会非常快，但是不好的地方就是不够灵活。当你检索时你会发现要抽取某些字段，要做这样的结构化跟你原来入库时的结构化不一样的时候，那你就没办法做了。另外一种是Schema on Read，就是说在检索时才去做结构化，这样就非常的灵活，检索之后你知道需要看什么字段、需要做什么分析，检索时才来做这个事情。它不好的地方是处理时间会比较长一点。而日志易是同时支持这两种，日志易实现了机制，把策略留给用户，用户可以选择Schema on Write或者Schema on Read的策略。

 

　　日志易的功能非常多，有搜索、告警、统计，让用户自己配置解析规则，可以识别任何日志。配置解析规则可以在日志进来入库之前配，也可以在检索时配，可以做安全攻击的自动识别，我们还开放API对接第三方系统，而且日志易是个高性能、可扩展分布式系统。乐视已经使用了日志易，做到索引性能每秒钟100万条。我们内部测是500万条。每天新增日志量是20TB。检索时一千亿条的日志我们可以在60秒之内完成检索。

 

　　所以用日志易做事件分析的优势，可以做细粒度的数据分析、秒级回馈、可视化的统计各种报表，完备的全量日志管理，可以把所有日志管理起来。

 

　　下面我们看一些金融领域的使用场景。这是某大综合金融机构用的。他们有600多个业务系统，每天产生几十TB日志，在运维过程中就面临这种问题，他以前没有集中管理日志，出了问题之后工程师登录到服务器去查看日志，但这些生产服务器你随便让运维工程师登陆上去，风险是非常大的。一个误操作可能就导致故障。所以使用日志易之后，就把日志全部集中管理起来，从下半年开始他就不准工程师直接登录到服务器查看日志，用日志易建立起日志云，所有查看日志都在这里看，这样就避免风险。而且登录到服务器上查询的方式也非常原始，没有办法进行多维度查询，无法进行日志和业务逻辑分析和告警。

 

　　我们在那里部署是两地三中心。三个机房，三个日志易集群，我们可以让他们在一个页面登陆，同时查看三个数据中心的所有日志。所以这个是他的数据量，现在接入的已经超过10TB，到6月底20TB全部接进来，而且接进来的服务器量也非常大。这是它的网络拓扑结构。他现在已经接入160多个业务系统，600多个接入了160多个，每秒钟是30万条日志。这个就是他们的日志云，所以我们也为大客户提供定制化的服务。我们把产品页面也按照他们的要求，改成他们的颜色。而且这个日志云其实就是用日志易来搭建的，这个就界面，一小时产生将近8亿条日志处理，这个就是日志，这个是页面，这边就是抽取的字段，几秒钟之内就可以把8亿条日志查询出来。这个是告警分析，针对他的业务进行各种告警分析。其中一个案例就是他们用F5做负载均衡，F5不小心就产生IP地址漂移，会有两个重复的IP地址，这会造成非常严重的故障，通过日志易可以马上发现这种IP地址冲突，几秒钟就进行告警，运维工程师马上去解决这个问题。

 

　　这个是对他的交换机关键字进行告警。比如说交换机链路down掉了，风扇坏掉了，这些马上都可以进行告警。这些就是告警的都标红了，马上标红、马上告警。这是我们在他那里部署了400多个agent，日志易实际上是一个旁路的系统，就是说不需要对客户的业务系统做任何的改造，它的业务系统还是写日志到他本地的日志文件，然后我们的agent会去监控这个日志文件，把日志文件增量的部分读上来。日志易的agent可以做加密、压缩、流控，还有脱敏，比如说他的日志里面包含了信用卡号码、帐户信息，可以做脱敏，把这些字符串给替换掉。而且日志易是提供一个页面统一来管理上千个agent。就是说你不需要登录到各台服务器去对接agent去做配置、升级，只需要在一个页面上管理上千台agent。

 

　　这个是监控。使用情况，使用日志易的情况。调用来源、调用量接口、处理时间这些指标。这里就是他们的一些统计分析的报表。日志易可以每天出报表、每周出报表，这个其实也是很多人员需要的，其实做运维是挺苦逼的，可能没出事的时候老板不知道他的存在，出了问题找运维工程师了，运维工程师被老板找的时候都是出问题的时候，那这些运维工程师怎么让老板知道他平时干了些什么？作为一个CIO怎么知道手下每天都在工作，那么通过出报表、通过出日报，我们甚至邮件发送这些日报，可以让CIO知道每天运维部门都在做什么，每天系统都被调用了多少次，这些统计分析都会有。

 

　　这也是故障的使用情况。这里就是我们的agent部署的情况，部署agent采集的情况。甚至我们还可以把日志归档到NAS系统里面去，因为他的日志在我们的系统里留7天的时间，超过7天的就可以归档到NAS系统，甚至可以归档一年的。比如说像券商行业，证监会要查一年之前的日志也可以从归档的系统里面调出来，进行查询分析。

 

　　这是另外一个客户，某股份制银行。他用来做行为日志的分析，手机银行。这是他们的日志。我们可以通过分析手机银行的，一个是资源的使用情况还有用户的行为。这个是他的XML日志的格式，这里面可以做用户日志的分析。还有服务追踪日志的分析，因为这家银行的手机客户端实际上在银行里面是用的非常广泛，他需要及时的监控这些性能，包括CPU使用情况都可以通过日志来分析。这是CPU的使用率。所以就是说日志易除了从日志上分析，我们也可以抓取系统性能的数据，就是服务器的CPU、内存、硬盘使用情况都可以抓上来分析。还有出错了也可以进行告警分析。就是说一出错，事中马上告警，而不是说事后追查。这也是手机银行的展示情况，我们可以展示上下文各25条，因为对出现问题以后，事中分析要发现问题，你得看上下文的日志，我们把上下文的日志集中起来，上下25行，就非常容易找到问题的根源。这个是我们对日志进行分组、权限管理，我们可以对用户分组、日志分组，不同的用户组对应着不同日志组的权限，这样的话加一个新的用户或者日志进来就非常方便。

 

　　这个是日志易的一些定时任务，执行定时任务自动做统计。这个也是定时任务的统计分析的结果。这些是报表，看机器的负载使用情况的报表。另外还有响应时长的报表。这个是成功失败比例的变化趋势。这个是告警监控。这个是报表。这个是仪表盘，仪表盘可定制。这个也是仪表盘。

 

　　下面一个是另外一家股份制银行使用日志易的案例。他们一个应用的部署情况。这是他们的日志，他一笔完整的交易涉及到600多行日志、4000多个字节，需要进行合并。因为一笔交易经过多个不同的子系统，每个子系统都产生日志，而且这些日志都散开了，需要把它合起来才能通过日志来分析交易。而且日志多线程打印，一笔完整的日志是交叉打印的，全都乱了，就是说没有日志易这样一个工具，人眼根本没办法去看和分析。

 

　　这是他另外一个业务，也是交叉打印，但我们可以通过一些ID来识别。他这个就通过一些ID来把日志关联起来。这个是故障定位的日志。这个就是我们怎么样来通过日志进行故障定位。这个是出来的页面情况，我们通过关联把日志聚合起来了，就可以看到一笔交易情况，自动关联。通过流水号把它关联起来。一个是通过流水号查到相关的日志全部都在一起集中展现，来分析。

 

　　这是某大基金的交易日志的分析。他这个交易日志也非常复杂，各个步骤一笔交易经过多个子系统，每个子系统的情况，而且中间有些信息还是缺失的，我们也都能够，在 缺失信息不完整的情况下帮他把这个东西分析出来。也是要进行多行的合并。这个就是我们进行分析出来的报表，他需要知道每一笔交易延时，0-50毫秒的有多少，50-500毫秒的有多少，500毫秒以上的有多少，要进行统计分析，要对每台服务器上面的情况进行分析。还有每台服务器的操作时长的趋势进行分析。

 

　　这是中国移动的，中国移动某省分公司，要分析营业厅的缴费情况。营业厅办理每一笔业务也是需要经过多台服务器，多个子系统，每个子系统都产生日志，他需要把多个子系统的日志还原成一笔交易，来看这笔交易总的延时是多少，每一个子系统的情况是怎么样。通过日志易，这就是一条SPL的程序，就是说搜索这个字段，这个字段的值是这个，通过管道符，通过命令，基于ID来把不同子系统产生的日志还原成一笔交易，这个交易是以查询作为开始、以提交作为结束。超过30分钟就是超时。还原出这些交易之后，这些就是还原出来的交易的日志，集中展现，可以做可视化，这个就是把交易还原之后做可视化的展现。所以这里讲了五个场景，有四个是金融行业的，有一个是运营商。

 

　　简单介绍一下日志易的情况。我们2014年成立的时候获得真格基金1400万人民币的天使投资，去年又获得红杉资本6000万元的A轮的融资。我们团队基本上都是来自于BAT还有360的核心研发团队，而且销售都是来自着名的外企的核心销售。也欢迎大家关注日志易的微信公众号，我们会定期发布一些情况。后面如果有什么问题的话，也欢迎大家交流！谢谢！