注册 / 登录

千亿级实时日志分析系统-腾讯鹰眼系统的技术演进之路

分会场:  质量管理/智能运维/DevOps

分享时间: 2017年11月9日 - 12日

案例来源 :

案例讲师

陈敏

腾讯科技有限公司 高级架构师

陈敏,高级工程师,2007年加入腾讯,服务于腾讯网,腾讯微博,腾讯新闻客户端,腾讯视频业务,从事DevOps开发与架构设计10年, 在基于海量数据的业务监控告警,质量管理,问题定位工具,自动化运营平台方面有丰富的经验。面对高可用性业务,高实时性要求,以及腾讯海量用户每天产生的几千亿的数据量,引进业界实时大数据处理框架如spark,storm,elasticsearch, kafka,并结合自身应用特定进行优化,在长期实践中积累了丰富的经验,真正的经受了大数据的考验。 目前正致力于智能运维方面的开发研究工作。

扫描二维码分享案例

所在软件研发中心介绍

--

 

建议该分享案例适用范围:

DEVOPS ElasticSearch ES优化 日志搜索

 

为什么这个案例值得分享?

ElasticSearch是目前业界流行搜索引擎,很多大的互联网公司都有比较成功的应用,在ES优化方面有各自的特点,本案例也是根据自身业务特定进行的一些优化,可以值得同行借鉴。

 

 

案例简述

 

长期以来,日志一直是软件开发中问题定位的重要手段,互联网业务,海量用户数据,分布式服务,多层次调用给日志定位带来了很大的挑战。本案例介绍了基于ES(elastic search) 搭建的日志实时查询集群的应用实践,通过对ES系统优化,参数优化,配置优化,源码优化,以及日常管理监控, 满足了每天上千亿行数百T的日志量级别下,即席查询(3秒左右)的要求。

 

案例目标

 

长期以来,日志一直是软件开发中故障和问题定位的重要手段,腾讯视频,腾讯新闻业务,上亿海量用户数据,分布式服务数百个节点,多层次调用给日志定位带来了很大的挑战,单机查日志已经不适应要求,而集中日志,每天产生上千亿行数百T的日志,存储,即席查询都要求一个强大的系统来支撑,我们的目标正是建立这样一个系统。

 

成功(或教训)要点

 

本项目经历过几年的架构变迁,最早的基于sphinx搜索引擎,用内存换速度,当数据量增长几倍后,成本已经无法控制,可维护性也越来越差;后来基于分布式数据库,成本是控制住了,但数据量高峰时,部分数据读写冲突锁表严重,导致查询速度不可控;到后来采用了ElasticSearch,几个大的问题都解决了,ES的高性能,高扩展,高可用性,以及ES项目本身高速发展,社区的活力,给我们带来了很大的信心,通过对ES各方面的优化,我们实现了我们的目标。

 

案例ROI分析

 

海量数据要做到实时查询,硬件成本是比较高的,查询响应越快,需要资源相对越多,这也需要我们对数据进行分类,集群分级进行管理,根据用户使用频率和要求, 提供分级的响应能力,从而达到性能和成本的平衡。

 

案例启示

 

很多问题的解决,我们都可以借鉴一些优秀的开源项目,这可以避免我们从头造轮子,节省了大量的人力成本。
在开源项目选型方面,同类解决方案往往有很多选择,而很多开源项目,往往放大了它的优点,缩小了它的不足,再加上网上各种分享吹的天花乱坠,
我们很容易迷惑,在我们尽最大努力各方面调研后,选择了一个相对好的方案,而只有在使用时才能真正知道它里面的坑的深浅,这需要我们有能力针对自身项目特点进行源码上的优化和二次开发,形成结合业务的平台,才能最大保证项目可控性和团队可持续发展。

 

案例在团队中的意义

 

ElasticSearch是目前业界流行搜索引擎,很多大的互联网公司都有比较成功的应用,在ES优化方面有各自的特点,本案例也是根据自身业务特定进行的一些优化,可以值得同行借鉴。