vlambda博客
学习文章列表

鹰眼海量级分布式日志系统上云的架构和实践

导语 | 鹰眼是由腾讯PCG技术运营部负责的海量级分布式实时监控和日志分析系统,为响应公司战略要求,将原先的业务迁移上云,最终产生了可喜的变化。本文将介绍分布式日志系统(鹰眼)的整体上云方案,希望与大家一同交流。

一、鹰眼平台介绍


鹰眼是由PCG技术运营部负责的海量级分布式实时监控和日志分析系统,支持多语言的上报,域名为: http://log2.oa.com/
鹰眼的数据上报是通过ATTA提供的,ATTA支持多语言的上报(JAVA,Python,C++等),上报之后,鹰眼从ATTA系统拉取数据最终写入到ES,通过ES的倒排索引机制,快速查询功能,写入功能等。
鹰眼海量级分布式日志系统上云的架构和实践
使用ES的倒排索引机制,百亿数据秒级查询返回的能力,鹰眼提供了以下功能:
1. 实时日志查询服务数据
实时日志查询服务数据上报到ATTA之后,开发可以通过鹰眼及时查询到日志,定位问题,运维可以通过鹰眼提供的数据统计界面实时查询到业务的运行情况。
鹰眼海量级分布式日志系统上云的架构和实践
2. 数据分析能力
鹰眼数据入库后,用户可以通过API直接调用,进行OLAP分析。
鹰眼海量级分布式日志系统上云的架构和实践
3. 错误日志告警服务
程序如果出现错误之后,可以按照鹰眼规范来上报错误日志,鹰眼进行分词,根据不同的错误码进行分钟级别的告警。
鹰眼海量级分布式日志系统上云的架构和实践
4. grafana实时分析告警
通过grafana对上报到鹰眼的数据进行实时的分析告警。 (由于ES不支持大并发查询,所以无法对超大数据进行实时分析)
鹰眼海量级分布式日志系统上云的架构和实践

二、上云的背景


公司战略调整,成立新的云事业群,内部成立“技术委员会”,启动“开源协同”和“业务上云”的两大战略方向。
在架构演进中,鹰眼团队上云能得到什么好处?上云的价值是什么?
1. 业务价值 
  • 聚焦业务,提升研发效率 ;

  • 加快技术换代,保持技术优势(传统互联网 vs 云时代);

  • 使用更好的云开源组件服务(可用性、稳定性、文档API…);

  • 计算资源重用,弹性伸缩,优化成本 ;

  • 标准化CI/CD流程。
2. 工程师价值 
  • 扩宽技术视野,避免闭门造车 ;
  • 掌握的技能更有价值 ;
  • 输出优秀组件到云,提高影响力。
3. 腾讯云价值 
  • 为客户输出业务上云经验 ;

  • 帮助腾讯云打磨云组件。

三、组件上云架构选型


为了保证业务的延续性和架构的演进,数据导入过程中的主体流程并没有太大改变,Kafka直接使用到云上的CKAFKA,ES直接使用到云上的ES。
鹰眼海量级分布式日志系统上云的架构和实践
ES和Kafka直接使用云上组件,其他组件需要进行重构。
1. 重构LogSender
生产者程序写入Kafka性能瓶颈特别大,高峰期丢数据特别严重。
生产者程序写数据流程: 读取BOSS订阅->IP解析->写入Kafka。
(1)IP解析性能瓶颈
之前生产者程序是C++版本,经过打印日志,发现高峰期IP解析耗时特别严重。排查代码,发现IP解析加锁了。所以高峰期丢数据特别严重。 解决方法是: IP解析改为二分查找算法来进行IP定位,然后取消锁,解决。
(2)Kafka性能瓶颈问题
由于我们生产者程序,一个程序会读取很多很多个topic,然后写入到Kafka,我们尝试,使用一个producer和多个producer发送,性能都提升不起来。
经过源代码排查,发现Kafka发送时,会根据topic分区来锁队列,当这个队列满的时候,就会发送一批消息出去。所以解决方案为,每个BOSSID应该有独立的发送客户端。
  • 数据量大的,有多个Kafka客户端

  • 数据量小的一批topic,可以共用一个kafka生产者。

鹰眼海量级分布式日志系统上云的架构和实践
优化之后:在数据量非常大的时候,因为程序性能原因,会导致一分钟单节点最多只能处理13万条左右的数据。改进后, 单节点能处理55w条左右的数据。  性能提升4倍。
2. Kafka选型
Kafka整体来说,高版本比低版本支持的功能更多,如事务,磁盘间的数据转移等,写入性能并不会下降。此处选型选的是最高版本。
当然CKAFKA并没有给我们选择版本的机会,客户端写入的时候还是得注意下和Kafka服务端版本一致,避免不必要的问题。
如低版本的客户端写入高版本的Kafka时,如果使用数据压缩,则服务端接受到数据后,会进行解压,然后再按照对应的格式压缩(如果版本一致,则不会有此动作),增加服务端的运行成本。
Kafka上云之后,单机性能能达到400MB/s,而我们自建的Kafka,单机性能最多达到100MB/s,性能提升4倍。
3. 重构Hangout
ES写入部分,业界有很多组件,最出名的是Logstach,由于性能不够,我们自己重新开发了一套读取Kafka写入ES的组件。

鹰眼海量级分布式日志系统上云的架构和实践

核心优化点如下所示:

由于磁盘IO的大幅减少,能在极限优化下继续提升性能2倍以上。 整体来说,ES写入提升性能6倍左右。
4. ES选型
ES低版本支持TCP写入和HTTP写入两种方式,高版本只支持一种HTTP写入方式。实测发现有如下区别:
  • TCP写入比HTTP更快;

  • HTTP写入更稳定一点,TCP写入是直接写到节点上面的,容易出现负载不均衡,HTTP更容易通过数据节点节点进行负载均衡。
因此我们采用了云版本ES 6.8.2。  
上云之后的效果:
  • 平均写入1TB数据,云下需要 80核,256G内存 12TB磁盘 (BX1机型);

  • 云上需要  3 * (16核 64GB 5TB硬盘 );

  • 平均节省资源1倍左右。

四、上云之后的变化


ES/Kafka上云之后,统计有50多个ES集群,12个Kafka集群.
1. 工作量的减少
如果不上云的话,搭建这些集群平均一个ES集群需要20台机器,从申请机器,到机器初始化,磁盘RAID,安装ES,平均每个ES需要3-4人/天,则搭建成本就已经需要200多人(62*3-4)/天了,还没有谈到集群运维成本,远远超过鹰眼团队的人力。
2. 成本的减少
上云之后,伴随着各个组件的优化,整体性能提升至少2-3倍,所需要的资源同比会减少2-3倍、每年节省成本至少2kw。
3. 工作更加聚焦
上云之后:
  • 鹰眼聚焦于写入性能优化,大大提升了写入效率;

  • 监控体系的建立,数据上报到ATTA之后,就进行数据对账,及时发现数据的延迟给出告警;

  • 在新功能开发上,基于ES支持隔天查询,如果当日数据暴涨之后,通过建立备份索引的机制增大写入量。


五、后续架构演进


1. 监控体系建设
核心模块既要有日志,也要有监控,不同模块的监控维度对应起来,让核心的模块,日志和监控都有,当业务出现异常时,及时调出发生异常的基础数据(如CPU/Mem等),指标数据,日志数据等进行完整的监控体系的建设。
2. 架构持续升级

目前自研Hangout写入只能保证at least once,但是无法保证exactly once。尝试通过flink的checkpoint机制,保证数据链路的完整性。