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

毛咏伟 2025-04-25 14:31:49

本文根据毛咏伟老师在〖2024 DAMS中国数据智能管理峰会-上海站〗线上分享演讲内容整理而成。

分享概要

一、携程可观测平台介绍

二、可观测数据治理实践

三、架构升级助力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、日志查询层设计

日志查询层的设计思路与Metrics类似，采用多个集群并通过统一查询代理服务整合为一个数据源。用户提交查询时，系统会解析SQL，根据查询时间段等信息进行SQL改写和拆分，然后查询对应集群的数据。例如，7月和8月的数据分别存储在两个集群中，系统会分别查询并合并结果后返回。

日志查询层还具备以下能力：

缓存机制：包括元数据缓存和查询结果缓存。元数据缓存用于快速定位集群信息，提升查询效率。

智能分析与拦截：系统能够提取用户SQL中的信息，识别并禁用低效查询（如模糊查询），避免对集群产生过大压力。

跨集群日志迁移工具：为解决高峰期日志量不均和磁盘容量不均的问题，系统会自动进行数据搬迁，均衡节点数据。通过算法计算出需要缩减和搬迁的数据量，并利用均衡算法完成数据迁移，最终实现磁盘用量均衡，节省成本。

3、统一Agent采集

携程在Agent采集层面也实现了统一。我们将机器上安装的Agent整合为一个服务，统一收集系统级、内核级指标以及机器上的系统日志、安全日志和自定义日志。所有可观测性数据都通过统一Agent采集并上报。

统一Agent的优势包括：

指标命名与格式统一：便于后续存储和分析。

集中管控：可以统一下发监控策略。

安全合规能力：采集安全日志，满足安全审计要求。

4、数据治理与价值落地

目前携程统一Agent的装机覆盖率已达99%以上。

整体思路包括：

统一查询与存储：通过统一的查询和存储架构，提升数据管理效率。

治理能力：在查询层和写入层提供治理能力，优化数据质量。

数据分类管理：区分优质数据和低效数据。优质数据用于业务分析和AIOPS落地，低效数据进行归档或回收，节省成本。

四、案例实践与思考

1、AIOPS能力的两大支柱

在携程的AIOPS实践中，我们将AIOPS依赖的能力归结为两种：运维之眼和运维之手。AIOPS平台需要依赖可观测性平台提供的基础数据，并对数据质量提出要求。同时，它通过标准化的API实现自动化操作，并结合大模型进行实践。

2、实践案例分享

1）磁盘故障自动处理

在日常运维中，磁盘故障是常见问题。AI助手通过监控数据发现故障磁盘后，会自动调用相关API卸载磁盘，并将其从集群中移除，确保不影响业务运行。待磁盘修复并完成数据同步后，再将其重新拉入集群。这一过程完全自动化，适用于场景固化、影响面可控的场景，显著提升了工作效率，解放了人力。

2）智能告警实践

智能告警实践分为三个部分：

数据采集：由通用观测平台负责监控数据的抓取和推送。

配置中心：AIOPS提供统一的规则配置界面，用户可通过该界面设置告警规则。AIOPS存储规则并定义契约，针对用户配置的规则进行定制化训练。

智能引擎训练：用户只需设置告警敏感度（如上升或下降）和告警类型，无需配置具体阈值。AI智能告警会基于历史数据进行分析，训练完成后，当曲线出现异常（如成功率下跌）时，自动触发告警。

3）故障定位分析

故障定位分析依赖于可观测性数据中的指标和Trace数据。Trace数据提供了应用之间的调用关系，而指标数据提供了报错信息。当故障发生时，通过分析报错最多的应用及其调用关系，可以快速定位问题源头。

例如，若某个应用的报错集中且影响多个下游应用，即可判断该应用为故障点，并进行快速恢复，如故障回退等操作。

3、AIOPS助手与大模型应用

1）AIOPS助手

在产品右侧，我们提供了AIOPS助手，用户可以通过交互式问答获取帮助。例如，当可观测性平台出现报错信息时，点击AI助手即可分析具体的异常信息，并提供修复建议。

2）大模型应用

规则解释：对于新手用户，AIOPS助手可以解释告警规则的触发条件、通知对象和执行频率，帮助用户更好地理解和配置规则。

故障总结与复盘：在故障处理群中，AIOPS助手可以对故障发生到结束期间的对话文本进行总结，提取关键信息。

此外，它还可以对故障复盘报告进行分析，提供改进措施建议。

辅助排障：结合可观测性平台提供的变更信息、发布信息和相关数据，AIOPS助手可以进行交互式问答，辅助用户进行故障排查。例如，用户可以查询应用的接口耗时情况或最近的发布记录。

4、未来展望

目前，我们的AIOPS小助手已经能够处理一些固定场景的故障发现与自愈，并结合大模型提供辅助人工决策的能力。未来，我们希望在故障预测和根因分析方面进行更多实践，进一步提升运维效率和智能化水平。

dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn

运维相关活动推荐

汇集2025年讨论度最高的运维议题，XCOPS智能运维管理人年会将于5月16日在广州举办。大会精选以DeepSeek为代表的大模型与AIOps深度结合、全栈可观测性能力建设、金融级Agent智能运维体应用、云原生下的降本增效与质量保障等干货案例，就等你扫码一起来探讨↓

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

降本的Kubernetes何时成了“成本刺客”？

YouTube如何利用MySQL支撑24.9亿用户？

人肉运维100次后，年底出了P0级故障……

关于国产数据库我不得不说

分库分表，可能真的要退出历史舞台了！