且听书吟

  • 首页
  • 关于
  • 留言
  • 友链
  • 笔记
  • 代码
且听书吟

OneAPM 工作两年总结

2017-10-17

告警系统的开发,我们和 Ai 一样,经历了几个阶段,版本迭代的时间点也基本一致。整个开发过程中,我们最核心的问题其实不在于告警功能本身,而是其衍生的产品设计和开发设计。

和 Ai 一样,初期的告警实现特别简单。当时来自 IBM 研究院的吴海珊加入 OneAPM 团队,带来了 Cassandra 存储,我们当时用的比较早,是 2014 年 2.0 版本的 Cassandra,我们在充分压测之后,对它的数据存储和读写性能十分满意,基于它开发了初版告警(草案)。

初版告警的实现原理极其简单,我们从 Kafka 接收要计算的告警指标数据,每接收到一条指标数据,都会按照配置的规则从 Cassandra 中查询对应时间窗口的历史指标数据,然后进行计算,产生警告严重或者是严重事件。然后将执行的告警指标写入 Cassandra,将告警事件写入 Kafka。(看下一页)

所以你会发现初版的告警,从设计上就存在严重的 Cassandra 读写压力和高可用问题。

你会发现,每从业务线推送一条指标数据,我们至少要读写两次 Cassandra。和同时期的 Ai 架构相比,Ai 对 HBase 只有写入瓶颈,但读取,因为量不高,反而没有瓶颈。(回上页)

这里是我们和 Ai HBase的对比总结。我们初版的设计和 Ai 一样都需要全量地存储指标数据,而且 Cassandra 的存储分片本身是基于 Partition Key 的方式,数据必须基于 Partition Key 去查询,我们对于计算指标,按照 业务系统、应用 ID、时间 作为 Partition Key 去存储。很意外的是几乎和 HBase 同时出现了读写瓶颈。而且比较尴尬的地方也和 Ai 类似,因为 Partition Key 的定义,完全无法解决写入热点问题。

所以我们首先想到的是,对于当前的告警架构进行优化,我们有了上述的新架构设计。但是在评审的时候,我们发现,我们做的正是一个典型的分布式流式处理框架都会做的事情,这些与业务逻辑关系不大的完全可以借助现有技术实现。

由于这个时期(15年)公司整体投产大数据,我们自然把眼光也投入了当时流行的大数据计算平台。

首先,对于初版的架构,我们需要保留的是原有的计算数据结构和 Kafka 的写入方式,对于核心的告警计算应用需要去改造。

我们需要实现的是基于单条数据的实时流式计算。需要能分布式水平扩展。能按照规则分组路由,避免热点问题。需要有比较好的编程接口。

1 2 3 4 5 6 7 8 9 10 11 12
10
评论 (2)
再想想
  • ricky.li

    感谢博主,收获很多,个人觉得整个架构重点在关注数据流式处理和存储,为什么不考虑用类似influxdb等时序数据库引擎实现呢?

    2022-05-25 回复
  • xzy

    雨帆大佬,这篇文章写的是非常好啦。小弟还有些不懂的地方,可以求个认识么?邮箱是QQ也是微信。

    2019-08-15 回复
随机文章
  • 五月迷失记
  • 碎花布裙
  • 寂寞的疼痛
  • 给你一个家的感觉
  • 樱花烂漫
  • 遇见
近期评论
  • 公子扶苏发表在《友人帐》
  • wu先生发表在《写给十年后的自己》
  • 雨帆发表在《留言板》
  • 大葱发表在《友人帐》
  • 大葱发表在《写给十年后的自己》
  • 小鱼发表在《关于我》
文章标签
人生 同人 回忆 小说 影评 思考 悠久之翼 情感 成长 文字 时光 未来 杂思 梦想 爱情 童年 记忆 随想 青春 高考
Copyright © 2011-2023 且听书吟. Designed by nicetheme.
萌ICP备 20200318号