导语 | 930 变革后, 公司明确了 "开源协同, 自研上云" 的公司技术战略, 通过自研业务上云, 整合资源使用, 推动架构能力互补, 促进自研业务与云产品协同发展, 同时实现产业互联网发展战略和促进腾讯云业务做大做强. 公司也专门成立了组织架构单元大力推动公司级业务上云. 为了响应这个号召, 分布式日志系统 (鹰眼) 也在积极探索将原有业务迁入云端的方案.
目录
一, 鹰眼平台介绍
二, 上云的背景
三, 组件上云架构优化和云上组件选型
四, 上云之后的变化
五, 后续架构的演进, 监控体系的完善.
一, 鹰眼平台介绍
鹰眼是是由 PCG 技术运营部负责运营负责的海量级分布式实时监控和日志分析系统, 支持多语言的上报.
域名是: http://log2.oa.com/
鹰眼的数据上报:
鹰眼的数据上报是通过 ATTA 提供的, ATTA 支持多语言的上报(JAVA,Python,C++ 等), 上报之后, 鹰眼从 ATTA 系统拉取数据最终写入到 ES, 通过 ES 的倒排索引机制, 快速查询功能, 写入功能等.
使用 ES 的倒排索引机制, 百亿数据秒级查询返回的能力, 鹰眼提供了以下功能:
1. 实时日志查询服务数据上报到 atta 之后, 开发可以通过鹰眼及时查询到日志, 定位问题, 运维可以通过鹰眼提供的数据统计界面实时查询到业务的运行情况.
2. 数据分析能力: 鹰眼数据入库后, 用户可以通过 API 直接调用, 进行 OLAP 分析.
3. 错误日志告警服务.
程序如果出现错误之后, 可以按照鹰眼规范来上报错误日志, 鹰眼进行分词, 根据不同的错误码进行分钟级别的告警.
4. 通过 grafana 对上报到鹰眼的数据进行实时的分析告警.
(由于 ES 不支持大并发查询, 所以无法对超大数据进行实时分析)
二, 上云的背景
930 调整, 成立新的云事业群, 内部成立 "技术委员会", 启动 "开源协同" 和 "业务上云" 的两大战略方向.
在架构演进中, 鹰眼团队上云能得到什么好处? 上云的价值是什么?
1, 业务价值
聚焦业务, 提升研发效率
加快技术换代, 保持技术优势(传统互联网 vs 云时代)
使用更好的云开源组件服务(可用性, 稳定性, 文档 API...)
计算资源重用, 弹性伸缩, 优化成本
标准化 CI/CD 流程
2, 工程师价值
扩宽技术视野, 避免闭门造车
掌握的技能更有价值
输出优秀组件到云, 提高影响力
3, 腾讯云价值
为客户输出业务上云经验
帮助腾讯云打磨云组件
三, 组件上云架构选型
为了保证业务的延续性和架构的演进, 数据导入过程中的主体流程并没有太大改变, Kafka 直接使用到云上的 CKAFKA,ES 直接使用到云上的 ES.
ES 和 Kafka 直接使用云上组件, 其他组件需要进行重构.
重构 LogSender:
生产者程序写入 Kafka 性能瓶颈特别大, 高峰期丢数据特别严重.
生产者程序写数据流程如下:
读取 BOSS 订阅 ->IP 解析 ->写入 Kafka.
IP 解析性能瓶颈: 之前生产者程序是 C++ 版本, 经过打印日志, 发现高峰期 IP 解析耗时特别严重. 排查代码, 发现 IP 解析加锁了. 所以高峰期丢数据特别严重.
将 IP 解析改为二分查找算法来进行 IP 定位, 然后取消锁, 解决.
Kafka 性能瓶颈问题: 由于我们生产者程序, 一个程序会读取很多很多个 topic, 然后写入到 kafka, 我们尝试, 使用一个 producer 和多个 producer 发送, 性能都提升不起来.
经过源代码排查, 发现 kafka 发送时, 会根据 topic 分区来锁队列, 当这个队列满的时候, 就会发送一批消息出去. 所以解决方案为, 每个 BOSSID 应该有独立的发送客户端.
1. 数据量大的, 有多个 kafka 客户端
2. 数据量小的一批 topic, 可以共用一个 kafka 生产者.
优化之后: 在数据量非常大的时候, 因为程序性能原因, 会导致一分钟单节点最多只能处理 13 万条左右的数据. 改进后, 单节点能处理 55w 条左右的数据. 性能提升 4 倍.
Kafka 选型:
Kafka 整体来说, 高版本比低版本支持的功能更多, 如事务, 磁盘间的数据转移等, 写入性能并不会下降. 此处选型选的最高版本.
当然 ckafka 并没有给我们选择版本的机会, 客户端写入的时候还是得注意下和 kafka 服务端版本一致, 避免不必要的问题.
如低版本的客户端写入高版本的 kafka 时, 如果使用数据压缩, 则服务端接受到数据后, 会解压, 然后再按照对应的格式压缩(如果版本一致, 则不会有此动作), 增加服务端的运行成本.
Kafka 上云之后, 单机性能能达到 400MB/s, 而我们自建的 kafka, 单机性能最多达到 100MB/s, 性能提升 4 倍.
重构 Hangout:
ES 写入部分, 业界有很多组件, 最出名的是 logstach, 由于性能不够, 我们自己重新开发了一套读取 kafka 写入 ES 的组件.
组件 | 单机测试 (BX1) | 备注 |
---|---|---|
Logstash | 30000 | 后端日志采集这一层 logstash 是用 jruby 来编写的,大家都知道像 jruby 这样的动态语言其实比较适合做 web 网站的快速开发(ror),像日志采集的后端应用,需要负责日志的采集和解析,尤其像解析日志会很耗 cpu 的,这样数据量一大很容易碰天花板 |
Heka | 12000 | 对比 logstash,其处理数据过程,对机器性能消耗较少,‘体重较轻’,但是其官方公布的测试数据,直接 stdout 输出,且中间无太多 fiter,encode 过程,单 heka 实例处理速度不过是 30000 条 / s |
自研 hangout | 200000 | 1. 通过多线程读取不同的 Kafka 分片,将客户端进行分组,充分利用 CPU 资源,将写入速度达到 10w/s.2. 通过 Bulk request routing 机制,将每一批次的数据使用同一个 route 值,ES 服务端接收时,会把这一批次的数据统一发送到一个节点上,可以减少网络传输压力(之前 ES 需要把一批次数据打散之后发送),充分利用磁盘顺序读写的能力,增大写入性能到 20w/s |
核心优化点介绍:
由于磁盘 IO 的大幅减少, 能在极限优化下继续提升性能 2 倍以上.
整体来说, ES 写入提升性能 6 倍左右.
ES 选型:
ES 低版本支持 tcp 写入和 http 写入两种方式, 高版本只支持一种 http 写入方式. 实测发现有如下区别:
1. TCP 写入比 HTTP 更快.
2. 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 机制, 保证数据链路的完整性.
来源: https://www.qcloud.com/developer/article/1656290