关于大数据:鹰眼海量级分布式日志系统上云的架构和实践

51次阅读

共计 2641 个字符,预计需要花费 7 分钟才能阅读完成。

​导语 | 鹰眼是由腾讯 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 机制,保障数据链路的完整性。

正文完
 0