携程新一代监控告警平台携程新一代监控告警平台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 已经足够稳定可以交付生产，
评论0