干货 | 携程监控系统Hickwall演进之路

作者简介

 

大伟，携程软件技术专家，关注企业级监控，日志，可观测性领域。

一、背景

监控领域有三大块，分别是Metrics，Tracing，Logging。这三者作为IT可观测性数据的三剑客，基本可以满足各类监控、告警、分析、问题排查等需求。

Logs：我们对于Logs是更加宽泛的定义，即记录事物变化的载体，包括常见的访问日志、交易日志、内核日志等文本型以及GPS、音视频等泛型数据。日志在调用链场景结构化后其实可以转变为Trace，在进行聚合、降采样操作后会变成Metrics。

Metrics：是聚合后的数值，相对比较离散，一般有name、labels、time、values组成，Metrics数据量一般很小，相对成本更低，查询的速度比较快。

Traces：是最标准的调用日志，除了定义调用的父子关系外（一般通过TraceID、SpanID、ParentSpanID），一般还会定义操作的服务、方法、属性、状态、耗时等详细信息，通过Trace能够代替一部分Logs的功能，通过Trace的聚合也能得到每个服务、方法的Metrics指标。

近年来，可观测性这个概念如火如荼，可以看作是对监控的一次大升级。CNCF也发布了OpenTelemetry标准，旨在提供可观测性领域的标准化方案。那么相比传统的监控告警，监控和可观测性有啥区别和联系呢？个人理解，可观测性能够以更加白盒的方式看透整个复杂的系统，帮助我们更好的观察系统的运行状况，快速定位和解决问题。

简单理解，监控和可观测性的关系。监控告诉我们系统的哪些部分是正常工作的，可观测性告诉我们那里为什么不工作了。监控侧重宏观，可观测性包括微观能力。监控是可观测性的子集。

图1

近些年，随着携程集团对线上故障1-5-10目标的提出（即第1分钟发现故障，第5分钟定位故障，第10分钟解决故障），对监控系统提出了更高的要求。监控系统最重要的三个特点可以定义为，系统稳定性，数据及时性，数据精准性，三者缺一不可。

携程监控系统 Hickwall 是一个企业级的指标监控告警系统，兼容了业界的 Prometheus监控标准，覆盖携程所有的指标监控数据，包括系统层和应用层。主要目标是实现指标数据的采集、接入、存储、展现，并在此基础上配置告警和通知，告警治理等，同时为第三方平台提供第一手的监控数据和告警事件。

二、遇到的问题

随着业务不断膨胀，系统规模的持续扩大，Hickwall遇到了一些问题：

• 高基数查询，指标维度过多，导致整体查询慢，用户体验不佳。

• 云原生的监控方案缺乏，需要支持开源PromQL业界标准，Prometheus SDK指标接入。

• 监控粒度粗，一些毛刺无法洞察，需要提高数据采样粒度。

• 告警系统多，技术方案杂，难维护，产品使用上用户到处找入口，规则和阈值定义不一样，很困惑。

• 监控数据延迟，导致误告警。

• 告警多，重复告警，缺乏治理。

• 容器大规模HPA带来的指标基数膨胀问题。

三、主要的演进

针对上述问题和痛点，Hickwall过去两年进行了一些针对性的优化和演进。

3.1 云原生监控

1）TSDB升级，经过三次演进，现在是基于VictoriaMetrics实现的第四代的TSDB解决