陈军
日志易创始人兼ceo
拥有17年it及互联网研发管理经验，曾就职于cisco、google、腾讯和高德软件，历任高级软件工程师、专家工程师、技术总监、技术副总裁等岗位。
负责过cisco路由器研发、google数据中心系统及搜索系统研发、腾讯数据中心系统和集群任务调度系统研发、高德软件云平台系统研发及管理，对数据中心自动化运维和监控、云计算、搜索、大数据和日志分析具有丰富的经验。
他发明了4项计算机网络及分布式系统的美国专利，拥有美国南加州大学计算机硕士学位。
演讲实录
目录：
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的用户数据挖掘基于日志，公司内部有专门的部门处理所有的日志，各模块的日志都被采集，传送到这个部门。
著名的开源消息队列软件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日志处理免费
五日志易产品介绍
它的主要功能有：日志搜索、告警、统计、关联分析（关联不同系统的日志）。用户可以在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。
<b></b>
<b>本文来自云栖社区合作伙伴"dbaplus"，原文发布时间：2015-12-18</b>