40w+实例、2w+应用：AI驱动下的可观测平台架构升级实践

毛咏伟2025年04月25日约 10 分钟

分享概要

一、携程可观测平台介绍

二、可观测数据治理实践

三、架构升级助力AIOps

四、案例实践与思考

一、携程可观测平台介绍

1、建设背景

携程是一家提供一站式旅行服务的网站，业务涵盖机票、酒店、度假等领域。我们拥有近2万的业务应用，实例数量（包括虚机和容器）约40万，每分钟写入的metrics数量达50亿，每日新增日志存储数据量为2PB。

携程的可观测性数据分为三类，即可观测性的三基石：Metrics指标、Logging日志和Trace调用链。

Metrics指标：涵盖系统性能指标（如内存、CPU、磁盘等）和应用指标（如请求量、错误数、响应时间等），还包括业务团队通过埋点客户端上报的业务相关指标，例如下单渠道的请求量等。

Logging日志：分为系统日志（如/var/log/message、安全日志等）、应用日志（如程序报错日志、业务相关日志，如下单日志、用户查询日志等）和第三方系统日志（如开源产品输出的日志、负载均衡器日志等）。我们会从详细日志中抽取指标，例如基于错误日志提取报错指标，并据此设置报警。

Trace调用链：与日志相关联，携程可观测性系统会在日志中埋入traceid，从而将日志与trace关联。Trace反映了微服务之间的调用关系，例如应用A调用应用B，再调用应用C，这种调用关系在trace中得以体现。

这三者相互关联，日志中可埋traceid与trace关联，日志还可抽取成指标。例如，对于耗时高的指标，可根据时间范围抽取相关配置以定位问题。

观测数据的作用主要体现在三个方面：

监控报警：针对应用级业务指标、基础硬件类OS异常等进行报警。
故障处理：结合监控三基石提供全局视角，通过关联快速定位故障，并基于历史问题实现故障自愈能力。
根因定位：与trace和metrics相关，根据应用报错及调用关系确定故障影响范围。

接下来谈谈我们面临的挑战，主要分为六个方面：

微服务架构：应用数量庞大且不断增长，调用关系每日变化，导致产生巨量可观测性数据。

云原生技术：云原生技术的HPA能力对metrics指标影响较大，HPA频繁扩缩容应用实例，产生大量新时序，给时间序列数据库带来巨大压力。携程内部默认开启HPA弹性能力，这对数据库压力尤甚。

1-5-10目标：希望实现1分钟发现告警、5分钟定位问题、10分钟修复问题。

可观测系统稳定性：数据量庞大，报警众多（包括智能报警和规则类报警），需保证平台稳定性。

数据及时性：避免因数据问题产生误报（如跌零报警）或因数据延迟导致误报警，数据及时性对监控报警至关重要，否则无法排障和定位问题。

查询效率：metrics查询需达到毫秒级响应，日志查询在1小时内需秒级响应，且日志平均存储时间要超过7天，以便用户排查线上问题。

2、携程可观测性平台架构

携程的可观测性平台以统一入口为基础，基于Grafana进行二次开发，集成了配置看板、各类图表展示以及日志和Trace查询能力。看板底层对接了Metrics、Logging、Trace三基石的观测数据，并通过统一查询层实现数据整合。

Metrics查询层：封装了底层多个时序数据库，这些数据库可能按BU、逻辑或物理划分。平台为用户提供统一数据源，用户只需输入指标即可查询对应数据。此外，查询层具备原数据管理和治理能力。

Logging查询层：底层依赖ClickHouse，支持日志的冷热分层和归档能力。

Trace系统：基于CAT系统二次开发，增加了与指标和日志联动的能力，并支持OpenTelemetry协议接入，提供全局报表分析功能。

3、AIOPS平台实践

携程的AIOPS平台主要聚焦于监控报警、容量管理和变更管理三大领域。

1）监控报警

智能报警：传统阈值报警易因阈值设置不准确而产生误报。智能报警通过分析数据曲线动态生成阈值，有效降低误报率。

故障定位与自愈：针对一些固定场景，平台具备根因故障定位能力，并可实现故障自愈。

2）容量管理

针对旅游行业的热点事件（如五一、十一、春节等），系统可对应用进行评分，提前评估容量需求并设置HPA扩缩容配置，平稳应对流量高峰。

系统还会预测未来热点事件的流量增量，为后续机器资源采购提供参考。

3）变更管理

在应用发布过程中，系统自动获取监控数据（如请求量、错误数、响应时间等），实时检测指标异常。

若发布过程中出现指标异常，系统会自动推送刹车信息，提醒用户停止发布，及时止损。

这些能力的实现依赖于底层可观测性数据以及AIOPS平台的时序检测算法。

二、可观测数据治理实践

1、日志架构与治理

1）日志架构

携程的日志架构主要由客户端日志埋点和系统机器收集的日志组成。这些日志经过日志网关推送至消息队列Kafka，再通过高效写入程序存储至日志集群。日志集群具备集群管理、元数据管理能力，并对外提供日志查询网关，支持接口和页面查询。

2）日志膨胀原因

日志数据膨胀主要源于以下几点：

业务增长：每月新增约50个日志场景，存量日志因审计或排障需求持续增加，导致日志容量日增2PB。

审计与排障需求：为满足合规要求，需延长日志保存时间。

研发习惯：研发人员倾向于记录详细日志以便问题定位，导致日志数据难以减少。

不合理接入：部分日志报文字段内容过长，存在不规范的日志打点。

存储成本问题：日志存储压缩率高，单价低，容易导致滥用。

2、治理实践

治理实践分为以下四个方面：

从分散到统一：建立统一查询层、存储引擎和日志原数据管理，推进公司内部日志最佳实践。

日志查询治理：对用户查询进行限制，包括智能SQL改写、QPS限制和对大表扫描（如模糊查询）的限制。同时，回顾过往查询记录，进行表迁移以均衡集群负担。

Loggig最佳实践：制定统一规范，设置审批流程，合理设置保留天数，并在日志发送端进行限制，通过quota策略控制发送量。

日志存储治理：采用冷热分层技术，结合本地磁盘和对象存储，设置表和租户级别的扩容策略，避免单个用户的访问影响全局查询。

3、告警治理

1）告警现状

告警数量持续增长，从年初到年底增长约30%。过多的告警可能淹没高优先级告警，降低工程师对告警的敏感度。

2）治理措施

统一告警中台：整合内部多套告警系统，统一告警通知策略，提供响应率和解决率机制，实现统一治理能力。制定统一告警级别，设置不同响应时间和处理时间要求，并建立告警升级机制。

告警配置管理：统一管理告警通知配置界面，实现告警治理闭环处理。通过统计用户对告警的响应和解决及时性，持续优化告警配置和处理机制。

告警降噪：接入告警平台后，通过聚合、自动抑制和收敛机制，减少无效告警通知，避免对用户造成干扰。

排班系统与Oncall机制：集成排班和报警中台，推行排班机制，提升Oncall文化。通过机器人协助处理，确保每个告警都有专人跟进，提高告警处理效率。

4、Metrics膨胀治理

1）问题背景

在HPA场景下，IP和内容不断变化，导致Metrics数据膨胀，对时序数据库（TSDB）性能产生较大影响。

2）治理措施

监控工具功能升级：增加指标预聚合能力，引导用户对大指标进行聚合，降低维度，排除如IP、机器等用户不关心的维度。

容量规划：建设统一查询层，统计不合理查询并进行限制，同时监控指标数量增长，推动指标治理。

Metric指标治理：通过检测程序发现高基数指标和不合理埋点，自动禁用问题指标并通知用户整改。

过滤能力：系统提供过滤能力，将数据从实例维度提升至应用维度，满足用户需求。对于无法通过指标解决的问题，推荐用户记录日志。

三、架构升级助力AIOps

1、时序数据库与统一查询入口

携程目前使用的时序数据库是开源的VictoriaMetrics。为了满足隔离和性能需求，系统根据内部BU划分了多个集群。然而，对用户而言，我们封装了一个统一的查询入口，屏蔽了底层集群的细节。用户只需选择统一数据源，即可查询所有指标数据。我们提取了指标名和字段值，作为原数据存储在ClickHouse中，并实现了统一的元数据管理。

此外，我们还提供了以下功能：

预聚合配置：针对写入数据进行预聚合，自动识别大指标并改写为预聚合指标，提升查询性能。

限流能力：限制查询频率和单个查询使用的内存，避免对系统造成过大压力。

2、日志查询层设计