携程新一代监控告警平台Hickwall架构演进_系统监控与告警系统 - CSDN文库

134 浏览量更新于2023-03-03 评论收藏 332KB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源评论

资源推荐

携程新一代监控告警平台携程新一代监控告警平台Hickwall架构演进架构演进

架构演进概述

为了更好地了解 Hickwall 在核心架构方面的设计，我们首先将 Hickwall 第一代的架构和现有架构进行比较。

Hickwall 最初的研发是在 2015-2016 年，当时我们调研了业界知名的开源监控系统。

比如 Graphite，拥有非常好的生态，但是集群配置复杂，每个指标都采用一个文件存储，导致小文件多，iowait 高，并且使用

python 实现，性能方面不太令人满意。

再比如 OpenTSDB，基于 HBase 天然就支持分布式，但是也受限于 HBase，多维查询的时候性能比较差。而其他的监控系

统也并未非常成熟，最后我们决定使用 ElasticSearch 作为存储引擎。下图是第一代的核心架构图。

在这个架构中监控数据从 Proxy 进来，经过格式整理、数据补全、限流后发送到 Kafka。Donwsample 消费 Kafka 中的原始数

据进行时间维度上的聚合，聚合成 5m、15m 等时间维度的数据点之后写入到 Kafka。Consumer 消费 Kafka 中的原始数据和

聚合数据写入到 ES，通过 API-Server 提供统一的接口给看图和告警。

因为 ES 的查询性能无法满足 Trigger 高频率的拉取需求，我们另外增加了 Redis 用来缓存最近一段时间的数据用于告警。这

套架构初步实现了监控系统的功能，但是在使用过程中我们也发现以下几个问题：

1.组件过多。运维架构追求的是至简至稳，过多的组件会增加部署和维护的难度。另外在团队人员变动的情况下，新成员进来

无法快速上手。

2.数据堆积。Consumer 消费 Kafka 出现问题，容易导致 Kafka 中数据堆积，用户将无法看到线上系统的当前实时状态，直到

将堆积的数据消费完。按照我们的实践经验，数据堆积的时间往往会有几十分钟，这对于互联网企业来讲是个非常大的问题。

3.数据链条过长。监控数据从 Proxy 进来到 Trigger 告警需要依次经过 6 个组件，任何一个组件出现问题，都可能导致告警漏

告或误告。

为了解决这些问题，我们研发了 Hickwall 的第二代架构，使用自研的 Influxdb 集群取代了 ES 作为存储引擎，如下图。

在这个架构中监控数据从 Proxy 进来分三路转发，第一路发送给 Influxdb 集群，确保无论发生任何故障，只要 Hickwall 恢复

正常，用户就能立即看到线上系统的当前状态。

第二路发送给 Kafka，由 Downsample 完成数据聚合后将聚合数据直接写入到 Influxdb 集群。第三路发送给流式告警，这三

路数据互不影响，即使存储和聚合都出现问题，告警依然可以正常工作，确保了告警的可靠稳定。

Influxdb 集群设计

ES 用于时间序列存储存在不少问题，例如磁盘使用空间大，磁盘 IO 使用多，索引维护复杂，写入和查询速度慢等。

而 Influxdb 是排名第一的时间序列数据库，能针对时间范围进行高效的查询，支持自动删除过时数据，较低的使用和维护成

本。只是早期的 Influxdb 不够稳定，bug 比较多，直到 2017 年底。我们经过测试确认 Influxdb 已经足够稳定可以交付生产，

本内容试读结束，登录后可阅读更多

下载后可阅读完整内容，剩余3页未读，立即下载

评论0

weixin_38576922

粉丝: 6
资源: 904

会员权益专享

图片转文字

全年可省5，000元立即开通

最新资源

资源上传下载、课程学习等过程中有任何疑问或建议，欢迎提出宝贵意见哦~我们会及时处理！点击此处反馈