目录：
- IT 运维分析（IT Operation Analytics）
- 日志的应用场景
- 过去及现在的做法
- 日志搜索引擎
- 日志易产品介绍
一
IT 运维分析
1、IT 运维分析
1.1 从 IT Operation Management (ITOM) 到 IT Operation Analytics (ITOA)
IT运维分析，即IT Operation Analytics，简称ITOA，是个新名词。以前IT运维是ITOM，IT Operation Management ，IT 运维管理。这两年大数据技术开始普及，把大数据技术应用于IT运维，通过数据分析提升IT运维效率与水平，就是ITOA。
1.2 大数据技术应用于IT运维，通过数据分析提升IT运维
ITOA主要用于：
- 可用性监控
- 应用性能监控
- 故障根源分析
- 安全审计
1.3 Gartner估计，到2017年15%的大企业会积极使用ITOA；而在2014年这一数字只有5%。
2、ITOA的数据来源有以下四个方面：
1.1 机器数据（Machine Data）：是IT系统自己产生的数据，包括客户端、服务器、网络设备、安全设备、应用程序、传感器产生的日志，及 SNMP、WMI 等时间序列事件数据，这些数据都带有时间戳。机器数据无所不在，反映了IT系统内在的真实状况，但不同系统产生的机器数据的质量、可用性、完整性可能差别较大。
1.2 通信数据（Wire Data）：是系统之间2~7层网络通信协议的数据，可通过网络端口镜像流量，进行深度包检测 DPI（Deep Packet Inspection）、包头取样 Netflow 等技术分析。一个10Gbps端口一天产生的数据可达100TB，包含的信息非常多，但一些性能、安全、业务分析的数据未必通过网络传输，一些事件的发生也未被触发网络通信，从而无法获得。
1.3 代理数据（Agent Data）：是在 .NET、PHP、Java 字节码里插入代理程序，从字节码里统计函数调用、堆栈使用等信息，从而进行代码级别的监控。但要求改变代码并且会增加程序执行的开销，降低性能，而且修改了用户的程序也会带来安全和可靠性的风险。
1.4 探针数据（Probe Data），又叫合成数据（Synthetic Data）：是模拟用户请求，对系统进行检测获得的数据，如 ICMP ping、HTTP GET等，能够从不同地点模拟客户端发起，进行包括网络和服务器的端到端全路径检测，及时发现问题。但这种检测并不能发现系统为什么性能下降或者出错，而且这种检测是基于取样，并不是真实用户度量（Real User Measurement）。
拥有大量客户端的公司，如BAT，会直接在客户端度量系统性能，做Real User Measurement，通常不需要模拟用户检测。
3、ITOA 四种数据来源使用占比
美国某ITOA公司的用户调研发现，使用这四种不同数据来源的比例为：Machine Data 86%, Wire Data 93%, Agent Data 47%, Probe Data 72%。这四种数据来源各有利弊，结合在一起使用，效果最好。
4、日志：时间序列机器数据
通常结合日志与网络抓包，能够覆盖大部分IT运维分析的需求。日志因为带有时间戳，并由机器产生，也被称为时间序列机器数据。
它包含了IT系统信息、用户信息、业务信息。
日志反映的是事实数据：LinkedIn（领英）是非常著名的职业社交应用，非常重视用户数据分析，也非常重视日志。
它的一个工程师写了篇很有名的文章：
- “The Log: What every software engineer should know about real-time data's unifying abstraction”, Jay Kreps, LinkedIn engineer
附：中文翻译：深度解析LinkedIn大数据平台（http://www.csdn.net/article/2014-07-23/2820811/1）
LinkedIn的用户数据挖掘基于日志，公司内部有专门的部门处理所有的日志，各模块的日志都被采集，传送到这个部门。
著名的开源消息队列软件Kafka就是LinkedIn开发，用来传输日志的。
以Apache日志为例，包含了非常丰富的信息：
- 180.150.189.243 - - [15/Apr/2015:00:27:19 0800] “POST /report HTTP/1.1” 200 21 “https://rizhiyi.com/search/” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0” “10.10.33.174” 0.005 0.001
里面包含的字段：
- Client IP: 180.150.189.243 Timestamp: 15/Apr/2015:00:27:19 0800 Method: POST URI: /report Version: HTTP/1.1 Status: 200 Bytes: 21 Referrer: https://rizhiyi.com/search/ User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0 X-Forward: 10.10.33.174 Request_time: 0.005 Upstream_request_time:0.001
可见，日志是非结构化文本数据，如果分析，最好把它转换为结构化数据。
上面就是抽取了各个字段，把日志结构化了，结构化之后，统计、分析就很方便了。
二
日志的应用场景
1、运维监控：
包括可用性监控和应用性能监控 (APM)
2、安全审计：
包括安全信息事件管理 (SIEM)、合规审计、发现高级持续威胁 (APT)
3、用户及业务统计分析
三
过去及现在的做法
1、过去
过去对日志是不够重视的，比如：
1.1 日志没有集中处理
- 运维工程师登陆每一台服务器，使用脚本命令或程序查看
1.2 日志被删除
- 磁盘满了删日志，或者日志回滚
- 黑客入侵后会删除日志，抹除入侵痕迹
1.3 日志只做事后追查
- 没有集中管理、实时监控、分析
1.4 使用数据库存储日志
后来开始集中管理日志，但使用数据库存储日志有什么问题？
- 无法适应TB级海量日志
- 数据库的schema无法适应千变万化的日志格式
- 无法提供全文检索
我见过使用数据库存日志的，数据库就三列：产生日志的服务器IP、时间戳、日志原文。没有对日志字段进行抽取。如果抽取，不同日志有不同字段，数据库无法适应，而且，数据库无法提供全文检索。
2、近年
近年开始使用Hadoop处理日志，但Hadoop是批处理，查询慢，不够及时。Hadoop适合做数据离线挖掘，无法做在线数据挖掘 OLAP (On Line Analytic Processing)。后来又有Storm、Spark Streaming这些流式处理架构，延时比Hadoop好不少，但Hadoop/Storm/Spark都只是一个开发框架，不是拿来即用的产品。也有用各种NoSQL处理日志的，但NoSQL是key-value store，不支持全文检索。
3、现在
我们需要日志实时搜索分析引擎，它有三个特点：
- 快： 日志从产生到搜索分析出结果只有几秒的延时 Google、百度的新闻搜索也只能搜索5分钟之前的新闻
- 大： 每天处理 TB 级的日志量
- 灵活： Google for IT， 可搜索、分析任何日志，运维工程师的搜索引擎
简而言之，这是Fast Big Data，除了大，还要快。
四
日志搜索引擎
1、日志管理系统的进化：
2、日志易：日志实时搜索分析平台
1.1 可接入各种来源的数据
- 可接入服务器、网络设备、操作系统、应用程序的日志文件，数据库，甚至恒生电子交易系统二进制格式的日志。
1.2 企业部署版及SaaS 版
SaaS版每天500MB日志处理免费，https://www.rizhiyi.com/register/
五
日志易产品介绍
它的主要功能有：日志搜索、告警、统计、关联分析（关联不同系统的日志）。用户可以在Web页面配置解析规则，抽取任何日志的任何字段，也开放API，对接第三方系统，供客户或第三方二次开发。
采用了高性能、可扩展分布式架构，可支持20万EPS (Event Per Second), 每天数TB日志。
日志易还是个可编程的日志实时搜索分析引擎，用户可以在搜索框编写SPL（Search Processing Language，搜索处理语言），使用各种分析命令，通过管道符把这些命令串起来，组成上百行的脚本程序，进行复杂的分析。
这就是李彦宏在云计算刚出现的时候说的“框计算”。给大家看一个例子：某省移动公司做的业务分析↓
Q & A
Q1：您说的可编程是ES的表达式？能讲一下实现了那些表达式，我们能做些什么功能？
A1：transaction (事务关联）、eval（算术表达式）、stats（统计）、sort（排序）等等。https://www.rizhiyi.com/docs/howtouse/transaction.html 发布了部分命令的使用指南。
Q2：为什么hadoop不行，这个产品能行，跟ELK有什么区别？
A2：Hadoop实时性差。ELK功能很有限，权限管理很差。日志易有非常丰富的用户分组、日志分组、基于角色的权限管理。
Q3：请问需要提前对业务日志做格式改造吗？
A3：不需要，用户在日志易的Web管理页配置解析规则，就可以抽取日志的字段了。
Q4：不同日志的怎么关联起来分析吗？
A4：不同的日志需要有共同的字段，如ID，来做关联。
Q5：权限管理自己实现，用web控制，ES索引控制就好了，还有其他权限？
A5：主要是哪个人能看哪条日志里的哪个字段，而且要做到很灵活，方便管理，日志易在中国平安有上百用户在同时使用，几百种日志，增加一个用户，他有什么权限，能看哪些日志，要很方便管理。
Q6：Nosql spark Kafka flume怎么样？
A6：这还是批处理，而且不支持全文检索。
Q7：每天6TB的数据，需要多少个elk的节点？然后是否需要增加一些ssd来做处理？
A7：取决于服务器的性能，近百台服务器吧，有SSD当然更好。
Q8：企业版数据采集，分享一下你们的经验！
A8：企业版就是部署在客户的环境，日志易只提供工具，不碰用户的数据。采集可以使用Linux自带的rsyslog agent，也可以使用日志易提供的agent，日志易提供的agent可以压缩、加密，压缩比1：15。
Q9：是否方便展示一下这个系统的架构？
A9：
Q10：你们对es做的改造能实现不同的业务数据按任意的字段进行关联分析吗？
A10：只要不同业务的日志包含了相同的字段，就可以关联分析。
Q11：日志易跟 Splunk 有什么大的区别？
A11：最大的区别是Splunk在检索的时候抽取字段，日志易是在索引之前抽取字段。所以日志易的检索速度比Splunk快。
Q12：SaaS版的架构能介绍下吗？日志易是如何做到数据隔离的？
A12：SaaS环境下，每个租户有自己的子域名，各租户登陆到自己的子域名。内部有权限控制、管理。
Q13：看你们的介绍有使用spark-streaming，那它在系统中是用来做什么功能呢？
A13：抽取字段，把日志从非结构化数据转换成结构化数据。
Q14：你们和SumoLogic比的区别或亮点是什么？
A14：SumoLogic有一些功能，如Log Reduce等，日志易还没有实现，SumoLogic是纯SaaS，日志易同时支持部署版和SaaS。
