IT运维分析与海量日志搜索

陈军 2015-12-18 09:49:11

12月16日,日志易创始人兼CEO陈军老师,在【DBA+社群】中间件用户组进行了一次主题为“IT运维分析与海量日志搜索 ”的线上分享。小编特别整理出其中精华内容,供大家学习交流。同时,也非常感谢陈军老师对DBA+社群给予的大力支持。


嘉宾简介
 
 

 

陈军

  • 日志易创始人兼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大数据平台(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。

 

再次感谢日志易CEO陈军老师,对DBA+社群活动给予的大力支持!

 

 

“DBA+社群”将陆续在各大城市群进行线上专题分享活动,以后每周一、周三晚上为【DBA+专业群】的固定时间,每周二、周四晚上为【DBA+各城市群】的固定时间,每周五晚上为【DAMS架构师精英群】的固定时间,欢迎大家积极加入我们。无论是内容还是形式,有好的建议我们都会积极采纳。

 

想入群的小伙伴们请关注DBA+社群微信公众号:dbaplus,回复“加群”即可。

 

 

小编精心为大家挑选了近日最受欢迎的几篇热文:

回复001,看杨志洪《【职场心路】一个老DBA的自白》;

回复002,看丁俊的《【重磅干货】看了此文,Oracle SQL优化文章不必再看!》;

回复013,看吕海波《去不去O,谁说了算?》;

回复014,看黎君原《扒一扒Oracle数据库迁移中的各种坑》;  

回复015,看郭耀龙《假事务之名,深入研究UNDO与REDO》;

回复016,看陈能技《基于Docker的开发模式驱动持续集成落地实施》;

回复017,看朱贤文《数据库与存储系统》;

回复018,看楼方鑫《数据库中间层,这样定制可能更好》;

回复019,看王佩《基于Docker的mysql mha 的集群环境构建实践》;

回复020,看王津银《互联网运维的整体理念与最佳实践》。

 

 

关于DBA+社群

最新评论
访客 2023年08月20日

230721

访客 2023年08月16日

1、导入Mongo Monitor监控工具表结构(mongo_monitor…

访客 2023年08月04日

上面提到: 在问题描述的架构图中我们可以看到,Click…

访客 2023年07月19日

PMM不香吗?

访客 2023年06月20日

如今看都很棒

活动预告