![]()
点击上方卡片关注我，回复“实践”，即可获得 AI Agent、RAG、多模态大模型相关的案例资料
在当今复杂的技术环境中，随着软件架构从单体向微服务和云原生的演进，企业对于可观测性的需求变得前所未有的重要。作为全球领先的在线旅游服务平台，携程面对的是海量监控数据与日志处理的挑战，这对平台的高效治理和持续稳定提出了更高的要求。在即将到来的 QCon 上海站，携程云原生研发总监周昕毅将为我们带来《AI 驱动下的可观测平台架构升级实践》的主题演讲。在会前的采访中，周昕毅分享了携程在应对这些挑战时所采用的创新解决方案，尤其是在数据采样、分层存储和统一监控 Agent 等技术手段的应用方面。他深入探讨了如何在保证系统性能与成本效益的平衡下，实现对海量数据的有效治理。此外，周昕毅还分享了携程在 AIOps 领域的领先实践，深入剖析云原生架构带来的可观测性难题，为行业提供了宝贵的技术见解。
另外，在本届 QCon 上海站，我们也设置了大模型基础设施与算力优化、AI 应用开发实践、AI 重塑技术工作流程以及云原生工程实践等专题论坛，欲了解更多精彩内容，可点击原文链接查看。
InfoQ：携程的可观测性平台现状中，您认为最突出的问题是什么？这些问题具体是如何影响平台的运维和决策的？周昕毅： 随着携程软件系统和应用的复杂性持续增加，携程可观测平台的数据量也在急剧增长。携程当下有超过 1w 个应用，实例数量 (包括物理机、虚拟机、容器) 超过 100 万个，它们产生的 Metrics 数据量每分钟超过 10 亿，所有应用和系统产生的日志量日增长超过 1PB。可观测数据包括日志、指标、追踪信息等，如何有效地收集、存储、处理和分析这些数据成为一个巨大的挑战，也是目前携程可观测平台最突出的问题。- 信息过载：大量的数据导致信息过载，运维人员难以从中提取有价值的信息。严重时会导致关键问题被掩盖，延长故障排除时间。
- 可观测平台的性能瓶颈：处理和存储大量数据需要高性能的基础设施，同时会增加机器成本和运维复杂性。如果平台性能不足，可能会导致数据延迟或丢失，影响监控数据的时效性。
- 成本增加：日志存储量日增超过 1PB，不做有效治理、每天都要额外增加 1PB 磁盘用于日志存储。
InfoQ：随着系统越来越复杂，携程的监控和日志数据是如何快速增长的？在管理这些数据方面，您遇到了哪些技术或管理上的挑战？- 微服务架构下应用和服务的数量快速增加，每个服务都会独立生成自己的监控和日志数据
- 弹性扩缩容导致容器变更频繁，IP、containerid 等维度基数增长迅速
- 更高的时效性要求（1-5-10 1 分钟发现 -5 分钟处置 -10 分钟恢复）会导致监控采集频率显著提升
- 多环境和多区域部署的要求，各环境和区域都会有独立的监控和日志数据产生
3）业务的复杂性持续增加，对于可观测性工具的依赖度越来越高4）数据量持续增加后，可观测工具自身也存在稳定性和实时性挑战InfoQ：在处理这些不断增加的监控指标和日志数据时，携程如何平衡系统性能和资源消耗的矛盾？周昕毅： 监控指标持续增加时，最常用的降本增效技术手段：数据采样和聚合；通过采样可以显著减少数据量，不同 metric 类型采用不同的采样策略，常用的采样策略是聚合某一个时间段内的平均值、最大值、最小值，可以大幅降低存储和查询的负担。日志数据有效的技术手段是建立冷热数据分层存储、定期归档的机制，将频繁访问的数据存储在快速存储介质上，而将不常访问的数据存储在较慢但更便宜的存储介质上。光靠技术手段还不够，需要建立定期 review 的机制，对于 top size 的监控指标和日志数据进行查询治理和存储治理，治理过程中将基本原则落地为巡检工具，持续巡检避免后续可能发生的资源浪费。可观测性平台作为“运维之眼”，对于网站可用性保障具备非常重要的战略意义，在可观测性平台进行资源投入是合理的，但需要确保有限的资源使用在优先级更高的业务场景之上，目前需要通过技术手段区分指标数据和日志数据的优先级，在容量达到瓶颈时有效启动降级、限流、降采样、冷存储迁移等预案。InfoQ：对于非关键性指标占用资源的问题，是否有采取措施来进行筛选和优化？如何判断哪些指标是核心的、必须实时处理的？周昕毅： 关于“如何判断哪些指标是核心的”这一问题，可以通过程序自动化识别结合人工支持录入的方式来持续更新。P0/P1 等核心监控看板以来的指标，自动设置为核心指标；部分业务场景下需要特别关注的指标，可以由研发工程、SRE 工程师手动在监控系统中设置；在可观测平台容量没有达到瓶颈时，默认所有指标都按照用户配置进行采集；否则将对于非核心指标进行降采样处理，确保有限的资源优先保障核心指标的采集、存储、展示。对于可观测性平台中的核心组件容量，进行容量规划和定期压测，包括 TSDB 的写入并发数、TSDB 单位时间内的新增 ts 数、TSDB 的查询并发数、TSDB 存储容量、消息队列并发数等，对于当前平台总体的 Metric 数量还有多少增长空间有准确的评估，避免出现核心指标持续增长时平台容量不足。行业内普遍存在监控工具分散、数据孤立的情况。携程是否也遇到了类似问题？如果有，您认为如何统一治理这些工具和数据更为有效？没有一款监控工具能够解决所有监控需求，这也造成了工具分散和数据孤岛。产品层面：携程的处理思路是在将 Metric、Logging、Trace 三大支柱融合在同一个产品中, 消除了多个监控领域的重复建设，统一多个工具的入口，缩短用户的排障工具使用路径，实现 Metric、Log、Trace 各类可观测性数据的联动。底层技术：Metric 和 Logging 数据实现统一查询、统一存储、统一治理。不同业务可以基于底层框架进行扩展，但是查询层和存储层需要收口在统一产品中，便于统一治理和资源利用率提升。InfoQ：从整个行业来看，云原生架构引发的可观测性挑战是否与携程的现状一致？您如何看待这个领域的普遍痛点？周昕毅： 云原生架构的引入带来了许多优势，典型的如弹性、可扩展性和更快的部署速度，将交付效率提升到了历史高度，对于可观测性基础设施也提出了很高的要求，在行业内很多公司都在追求效率的同时遇到了可观测性挑战，大家的问题是一样的。我认为这个痛点是暂时的，随着可观测性技术体系的持续发展，下列问题都是可以分而治之。- 被观测对象的生命周期短：容器的生命周期通常较短，可能会频繁启动和销毁。这种动态性使得传统的监控工具难以跟踪和记录系统的状态，存储到 TSDB 之后、容器 containerid、ip 等频繁变化的维度触发了 TSDB 的基数膨胀。
- 不同视角的监控需求：云原生架构涉及多个层次，包括基础设施层（如虚拟机、容器）、平台层（如 Kubernetes、OpenStack）、应用层（微服务）和网络层。每一层都需要不同的监控和日志记录方法，且需要避免循环依赖，基础设施层的监控需要和应用层的监控工具区分管理。
- 海量数据的实时处理：由于云原生系统的分布式和动态特性，生成的日志、指标和追踪数据量巨大。有效地收集、存储和分析这些数据需要强大的数据处理能力和智能化的分析工具。
InfoQ：携程是如何通过统一监控 Agent 来提升可观测性数据治理的？这个过程中遇到了哪些困难，具体是如何解决的？周昕毅： 携程应用和服务主要通过框架 SDK 埋点的方式记录 Metric、Logging、Tracing 数据，除应用之外，操作系统、硬件、安全、网络设备等的监控 Metric、日志 Logging 数据均是通过携程自研的 Hickwall Agent 进行统一采集上报到存储系统和消息队列进行后续的统一处理。统一监控 Agent 采集的主要对象包括：系统级监控指标：CPU、内存、磁盘、网络 IO；内核级监控指标：ebpf 采集指标、内核异常 metric；系统日志：syslog，messages，kernel-log；安全日志：ssh 登录日志，audit 日志，进程启动日志等。携程统一监控 Agent 对于可观测性数据治理有很多帮助，主要包括如下：统一格式：使用统一的监控 Agent 可以确保所有采集的数据采用一致的格式和标准，便于后续的存储、处理和分析。统一命名规范：统一的命名规范可以减少数据混淆，确保不同来源的数据可以正确关联和对比。集中配置：通过统一的 Agent，可以集中管理和配置监控策略，减少了分散管理带来的复杂性和错误风险。统一策略：可以应用统一的数据采集、存储和处理策略，确保所有数据治理措施的一致性和有效性。统一安全策略：可以实施统一的安全策略，如数据加密、访问控制和审计日志，确保数据的安全性和合规性。监控 Agent 在安全审计中是一个重要的环节，可以确保安全策略的收口，自动化巡检，策略覆盖度的提升落地。携程在建设统一 Agent 过程中遇到的困难主要包括：1）需要支持多平台: 携程内部所有使用的 OS 都需要适配对应的 Agent 支持；2）Agent 升级困难：Agent 版本升级需要多个运维支持团队配合，全网升级一轮耗时很长，缺乏统一管控。后续携程引入了 Agnet 自升级机制，通过一个 Guardian 客户端对于监控日志 Agent 进行健康监控和版本升级统一控制。3）需要引入防呆机制：Agent 全网机器都有部署，需要对于一些极端异常情况进行防呆设计。监控 agent 应能够自动发现系统中的资源和服务，并自动配置监控参数，减少人为配置错误。当监控 agent 检测到自身配置或运行状态异常时，应具备自我修复能力，如重新加载配置或重启自身。4） Agent 健壮性：监控 agent 应能够优雅地处理各种错误情况，如网络中断、数据收集失败等，并记录详细的错误日志以便排查。agent 需要设置合理的资源使用限制（如 CPU、内存）以防止监控 agent 自身消耗过多资源影响被监控系统的性能。5）性能持续优化：优化数据收集和传输机制，确保监控 agent 高效运行，不对被监控系统造成过多负担。支持批量处理和压缩传输监控数据，减少网络带宽消耗和系统负载。InfoQ 在 Metrics 和 Logging 数据治理方面，携程采取了哪些创新性措施？这些措施如何帮助优化数据质量和系统性能？日志数据统一存储、统一查询，目前使用的是 Clickhouse 作为携程日志平台的存储层；对于 Clickhouse 的查询请求收口到统一查询 API。基于日志统一查询 API 的能力，可以实施日志查询治理，包括用户 SQL 的智能化改写兼容不同版本的 Clickhouse；限制查询 QPS，确保后端 Clickhouse 性能和响应时间在可控范围内；限制最长查询时间范围，比如超过 180 天的查询请求直接返回错误、避免长时间占用资源；目前统一查询层每日平均拦截 1500 次用户不合理的查询请求，如下图所示，开启自动拦截之后、集群有效 QPS 显著下降。最佳实践包括: 遵循日志统一规范；设置合理的日志保留天数；设置合理的单位时间内发送条目数；超过阈值是有合适的采样策略。Clickhouse 集群选择本地磁盘 + 分布式存储扩展的模式，落地冷热分离技术方案，设置表级别的 Quota 和租户级别的 Quota 值，推动租户自助进行日志治理。Clickhouse 选择使用 zstd 压缩模式，降低磁盘空间使用率；统一使用批量插入的模式、一次写入多条日志，降低集群 IO 压力；工具本身提供指标聚合能力，并引导用户进行指标聚合的配置；原始数据进行针对性降维，收敛指标维度的数量；推进 Metric Federation 建设，提供指标数据联邦查询的能力完善 Metrics 存储和写入集群自身的监控，关注 ts 数量的增长，对于 Metrics 数据尖峰流量有应对预案高基数指标的自动识别和检测机制建立，对于非法写入进行智能化封禁，推进合理的 metrics 写入规范（比如 tag 和 value 禁止使用随机数），对于单个指标的字符长度做限制自动识别无效的维度、自动降维；推动用户关注应用和服务维度的监控，实例维度的 metric 仅保留最重要的部分；在 Logging 数据和 Metrics 数据治理过程中，有一个相同的关注点，“不要期望仅靠 logging 数据、不要期望仅靠 Metrcis 数据来解决所用问题”，Logging、Metrics、Tracing 三大支柱是互相补充、彼此备份的，需要在治理过程中从解决实际需求的角度出发、选择最优的监控方案。就可观测数据治理后的主要收益来说，首先是数据准确性和完整性：减少错误和异常数据，提高监控数据的准确性和完整性，“误报”是监控工具最大的敌人，通过数据治理可以降低误报，利用有限的资源将监控价值最大化；其次是查询和分析效率提升：减少无效查询，优化数据存储和处理流程；最后是系统稳定性和性能提升：减少数据采集和处理对系统性能的影响，提高系统的稳定性和性能。InfoQ：物化视图和分层存储技术在携程的可观测平台中具体是如何应用的？这些技术如何有效地提升数据处理的时效性和可靠性？周昕毅：ClickHouse 的物化视图（Materialized Views）技术在携程可观测平台中的使用：日志预聚合: 常用的日志聚合是按照每小时的请求数、错误数、平均响应时间，也可以按特定维度（如用户、地理位置、服务类型等）进行分组聚合，生成预先计算的统计数据主要收益一方面是可以加速查询：通过预聚合减少查询时的计算量，减少实时查询时的 CPU 和 I/O 资源消耗从而显著提高查询性能，提高系统的整体响应速度；另外一方面是支持更长的查询范围：写入量较高的日志表，一般只能支持天级别、小时级别的查询，通过物化视图技术，可以为重要的日志表增加更长的保留天数。1）性价比考量：物化视图会占用额外的存储空间，需要根据实际需求权衡存储成本和查询性能，优先处理高 QPS 查询的表，不能用于全部的日志表。2）准实时更新：物化视图的更新是异步的，需根据业务需求调整更新策略。3）数据准确性比对：需要定期维护和管理物化视图，保障其数据准确性。分层存储技术的概念是指将数据分为多个层次，每个层次使用不同的存储介质和策略。例如，在热数据层，存储最近和频繁访问的数据，通常使用高性能的存储介质（如本地 SSD 磁盘）；在冷数据层，存储较少访问的历史数据，通常使用成本较低的存储介质（如本地 HDD 磁盘）；在归档层：存储很少访问但需要长期保存的数据，可能使用更低成本的存储介质（比如磁带）或云存储。Clickhouse 日志表天然适用于基于 timestamp 做冷热存储分离的逻辑，如下列建表语句所示：CREATE TABLE logs_hot(timestamp DateTime, level String, message String)ENGINE = MergeTree()PARTITION BY toYYYYMM(timestamp)ORDER BY timestampTTL timestamp + INTERVAL 1 MONTH TO VOLUME 'cold'SETTINGS storage_policy = 'hot_to_cold';
超过一个月的日志由于业务需求不能删除，但可以定期迁移到冷数据存储层做归档。分层存储技术落地的收益主要在于降低日志存储单价，延长日志存储时间，极大增加了可观测平台中日志存储的可扩展性。InfoQ：可观测性数据质量是 AIOps 成功的关键，携程如何通过度量工具来保证数据的准确性？在提升数据质量的过程中，有哪些具体的实践经验可以分享？周昕毅： 高质量的可观测性数据（包括 Metrics、Logging、Tracing 数据）是 AIOps 成功的关键因素之一。携程通过如下方式来保证数据的准确性：- 多个数据源交叉验证监控，从系统维度和应用维度的 metrics 数据做交叉校验
为了提升可观测性数据质量，主要要如下几个方面出发：- 提升数据收集端的实时性，持续优化统一监控 Agent 性能
- 减少数据传输链路，部分场景采用 writer 直写 TSDB 的模式
- 存储引擎持续优化，根据场景选择合适的存储引擎 (如 TSDB 选择 VictoriaMetrics, 日志场景使用 Clickhouse)
- 推进数据治理，制定和实施数据治理策略，确保存量数据的高质量
- 建设采集层、传输层、存储层的度量工具，确保数据的完整性
- Metric 数据统一查询，建设 Metric Federation 联邦查询层
- Logging 数据统一查询，推动日志查询治理，确保可观测性资源消耗在核心监控链路
InfoQ：对于其他企业在进行可观测平台架构升级时，您会建议他们优先从哪些方面着手改进？有无哪些具体的技术路径可以参考？周昕毅： 建议简化技术栈，同质化工具尽量合并，Logging、Metric、Tracing 不同场景明确分类不要混用；监控和日志进行中优先级划分，优先保障高优先级日志和监控数据的完整性和实时性。具体技术路径可以从可观测平台的各个不同组件的定位和技术架构角度出发，供大家参考：- 数据采集层：使用统一的监控 Agent 用于系统层 Metric 和日志收集；使用统一的 SDK 用于应用埋点。
- 数据存储层：选择合适的 TSDB 存储引擎和日志存储数据库，可以有多套存储应对不同的业务场景，但是需要统一写入、统一查询、统一治理。
- 数据分析和可视化：使用统一的用户侧产品，将 Logging、Metric、Tracing 数据进行统一展示、实现数据联动，构建直观的可视化仪表盘，展示关键指标和日志信息，并持续运营维护。
- 自动化运维和智能化运维：实现监控和告警的自动化处理，减少人为干预和操作失误，同时进行 AIOPS 技术落地与探索，使用机器学习等 AI 技术，自动检测异常和预测系统问题。在持续优化可观测性数据质量的前提下，AIOPS 落地将会更加便捷，收益更高。
InfoQ：您认为未来 AIOps 在运维中的发展趋势是什么？智能化的运维工具将如何改变传统 SRE 团队的工作模式？周昕毅： 随着 AI 技术的不断进步和企业对高效运维需求的增加，AIOps 的发展趋势会从几个方面持续推进：AIOps 持续发展的能力包括故障检测、根因分析到自动修复，会不断减少人为干预和操作失误。AIOps 会和现有的自动化运维工具和平台融合，运维工具变得更加智能化。AIOps 利用机器学习和深度学习技术，自动检测系统中的异常行为和性能瓶颈，及时发现和定位问题。预测性防护能力提升，AIOps 通过分析历史数据和实时数据，预测系统可能出现的问题和故障，提前采取预防措施。AIOps 目前已经广泛用于容量预测的场景，未来可能发挥更大的作用，用于全栈容量预测，不局限于应用和业务场景，也包括基础设施的容量管理。AIOps 可以整合来自不同数据源的数据（如日志、指标、追踪数据），进行综合分析和关联性分析，提供更深入的洞察。通过 AIOps 平台，实现运维团队之间的高效协作和知识共享，提高问题解决的效率。同时，运维知识图谱也将持续迭代更新。传统 SRE 团队的工作内容包括业务系统的监控配置和告警处理、业务故障排除和根因分析、系统性能优化和容量规划、自动化运维和配置管理、业务系统灾备和高可用性建设等，基于上述展望，AIOps 将成为 SRE 工程师的左膀右臂，在各个领域都能提升工程师的工作效率，成为稳定性工程建设的重要助力。正是基于上述展望，可观测性平台的架构持续升级应对更多的数据增长需求和挑战显得很有必要性，一旦出现数据问题导致 AI 误判，未来可能将产生灾难性的后果。InfoQ：为了进一步支持 AIOps 的落地，可观测平台未来还需要在哪些方面进行升级？是否会考虑加入更多智能分析和自动化决策的功能？周昕毅： 本次分享中携程可观测性平台架构升级主要包含了如下几个方面：3）统一日志存储，统一 Metric 存储，存储治理上述几个方面为 AIOps 建设提供了数据支撑，未来还需要为智能分析和自动化决策提供更多助力。为了进一步支持 AIOps 的落地，未来的可观测性平台架构升级会关注如下几个方面：建设统一的自愈系统，“眼手合一”，将“运维之眼”可观测性平台产生的告警和“运维之手”自动化运维工作流平台整合在一起，在统一的平台中执行故障自愈。InfoQ：随着企业系统复杂性和数据规模的进一步扩大，您认为未来的可观测性平台应该具备哪些核心能力？这些能力是否会影响 AIOps 的进一步发展？周昕毅： 个人观点，未来的可观测性平台的核心能力包括：目前 Logging、Tracing、Metrics 数据虽然能通过应用、机器、服务等维度进行关联查询和一站式展示，但是缺乏全栈视角，需要人工进行数据关联和转换。未来基于 AI 能力可以整合日志、指标、追踪数据等多种数据源，进行综合分析和自动的关联性分析。由于系统越来越复杂，每天都产生大量的 Logging、Metrics、Tracing 数据。运维工作中比较消耗时间的一个环境是故障定位、根因分析。常用的 AIOps 技术是利用机器学习和深度学习模型，自动检测系统中的异常行为和性能瓶颈，进行智能告警和预测，这个技术方向后续还会持续升级，在智能化根因分析中发挥更大的作用。随着 AIOps 技术持续发展，对于可观测性平台数据的实时性、告警的实时性、查询的时效性要求也会越来越高，可观测性平台中实时化数据处理本来就是一个技术难点，后续实时数据处理能力将会成为可观测性平台的核心能力之一，需要持续进行架构升级迭代。周昕毅，携程云原生研发总监。毕业于同济大学软件学院，15 年以上云平台研发和运维管理相关工作经验。目前负责携程云 IAAS 基础设施的研发和运维管理、大数据基础平台和可观测性平台建设。主要研究方向是虚拟化、分布式存储、可观测性体系。10 月 18 日 -19 日，QCon 全球软件开发大会将在上海举办。从云原生工程、架构、线上可靠性、大前端、技术管理等经典内容，到 AI Agent、AI Infra、RAG 等大热的 AI 话题，60+ 资深专家共聚一堂，深度剖析相关落地实践案例，共话前沿技术趋势。大会火热报名中，详情可联系票务经理 17310043226 咨询。
![]()
极客时间企业版推出「金融科技人才培养解决方案」， 构建金融科技人才数字化能力的全景培养体系，提供一个结构化的成长路径，满足金融科技行业对于不同层级人才的需求，明确了数字化领军人才、数字化管理人才、业技融合人才、数字化应用人才、专项技术人才各层级的培养重点及形式。扫描二维码了解方案详情。- 关注「InfoQ数字化经纬」公众号，回复「案例」领取《行知数字中国数字化转型案例集锦》。
- 关注「InfoQ数字化经纬」公众号，回复「进群」加入数字化读者群交流。
