周昕毅：AI驱动下的可观测平台架构升级实践
AI驱动下的携程可观测平台架构升级实践 演讲人：周昕毅 目录 01携程可观测平台介绍 02 可观测数据治理实践 03架构升级助力AIOPS 04 案例实践与展望 携程可观0测1平台介绍 Abouttrip.com -为用户提供一站式旅行服务的网站 -应用数量: 1w+ -实例数量(虚拟机+容器): 40w+ -每分钟新增Metric数量: 10亿+ -每日新增日志存储: 1PB+ 网站当前有没有“问题”？ Metric -系统性能指标 -应用性能指标 -业务埋点指标 -日志聚合指标 Logging -系统日志 -应用日志 -业务日志 -负载均衡日志 -第三方系统日志 Tracing -事件上下文信息 -函数级别调用栈 -应用调用关系 聚合场景化 “问题”在哪里 “问题”为什么出 现 “问题”的上下文 监控告警 -硬件/OS异常 -应用级别异常 -业务指标异常 故障处理 -提供“上帝视角” -提升故障处理效率 -基于历史经验自动解决故障 根因定位 -确定故障影响范围 -全链路追踪 -专家系统的数据依赖 快速发现 加速定位 根本解决 AIOps&可观测数据 硬件资源 基础软件 应用软件 可观测数据采集 可观测数据存储 AIOps智能化平台 智能决策 智能分析 AI工具链 大数据处理 监控告警 -智能告警 -告警归因 -故障定位 -故障处理 管理容量 -容量评分 -HPA/VPA配置推荐 -容量预测&压测分析 管理变更 -变更风险检查 -自动刹车 -智能化发布 AIOps辅助决策层 数据 算法 根据应用Metric报错数据和应用调用链Trace数据自动分析当前故障关联关系，提升根因定位效率 微服务架构 -应用数量快速增长 -应用调用关系复杂 云原生技术 -HPA(分钟级交付数千容器) -时间序列数据库的基数膨胀 1-5-10目标 -1分钟发现需要秒级告警 -快速定位依赖可观测体系 可观测系统稳定性 -一站式平台打通多个监控系统 -监控数据延迟导致误告警 -容量规划&指标治理体系 数据及时性 -海量新增日志秒级写入 -日志丢失率控制 -全链路传输实时性 查询效率 -Metric查询毫秒级响应 -1hLogging查询秒级响应 -日志平均保留天数>7 携程可观测平台一站式产品入口 Metric统一查询层 日志统一查询层 自研Tracing系统 MetricDB1 Clog系统 CAT系统 MetricDB2 ClickHouse 多指标联动 统一元数据 冷热分层 OTEL接入 Metric治理 日志归档 全局报表 可观测数0据2治理实践 -新增日志Senario:平均每月50+新增场景 -存量日志场景保留天数持续增加(14->30->90…) -日志容量峰值日增>1PB -业务自然增长造成的日志增加…最理想情况：） -存量日志需要延长时间应对客诉处理、故障分析、审计和合规需求(Top100日志平均保存时长为98天) -做加法容易，做减法很费劲，研发普遍采用详尽的日志记录策略、为了确保后续排障时能有效定位 -存储字段不断增加，大量场景需要保存请求报文和访问报文，极端场景下单个报文字段长度超过20万字符 -ClickHouse压缩率较高，是平均单价较低的一种存储介质，相对而言容易出现滥用的情况 Logging日志治理实践 从分散到统一 -统一查询、统一存储 -统一元数据 -公司内推进日志使用最佳实践 日志查询治理 -用户SQL智能改写 -查询QPS限制、时间范围限制 -大表扫描限制 -查询历史回顾 Loggig最佳实践 -遵循日志统一规范 -设置合理的保留天数 -设置合理的发送阈值 -超过阈值时有合理的采样策略 日志存储治理 -本地磁盘+分布式存储 -冷热分离技术方案 -表级别Quota -租户级别Quota 可观测性数据膨胀-告警数量持续增长的问题 2024年初 2024年底 MetricInsert 112million/s 150million/s MetricQuery 4000query/s 5000query/s TriggerCount 15w 18w -严重的告警信息被低优先级告警信息淹没 -“狼每天都来”，工程师对告警敏感性降低 可观测性数据膨胀-告警治理手段 告警分级 -P0/P1/P2/P3 -告警定期review -及时响应率 -P0/P1告警处理时效性要求 告警降噪 -告警聚合能力提升 -自动抑制和收敛机制 -控制单位时间内告警数量 Oncall机制 -引入Bot协助处理 -告警自愈能力提升 -故障响应及处理方法沉淀 可观测性数据膨胀-Metric高基数问题 Metric-name Label-names Label-values Cardinality ipaddress 10.0.0.1/10.0.0.2/10.0.03… HPA场景下会持续增加 hostname CTN-01,CTN-02,CTN-03…. request_duration_seconds containerid axxxx,bxxxx,cxxxx 极端情况:应用有异常每 30秒重启一次， containerid数量会持续 累积增加 appid 10001,10002,1003… 监控工具功能升级 -增加指标聚合能力 -引导用户进行聚合配置 -原始数据降维，收敛指标维度 -MetricFederation建设 容量规划 -Metric存储集群自身的监控 -关注ts数量增长 -尖峰流量应对预案 可观测性数据膨胀-Metric高基数问题解决方案 Metric指标治理 -高基数指标的识别和检测 -非法写入自动封禁 -tagvalue禁止使用随机数 -字符内容最大值限制 过滤能力 -自动识别无效的维度 -实例维度->应用维度 -不期望单靠Metric解决所有问题 平台架构升0级3助力AIOPS VictoriaMeticsDB1 统一API 元数据管理 预聚合管理 自动限流 ClickHouse VictoriaMeticsDBn VictoriaMeticsDB2 PROMXY MetricFederation查询入口 MetricFederation架构升级 日志缓存加速 SQL改写 自动封禁 -基于统计分析的不合理查询过滤 -基于规则的问题查询禁用 -平均每天拦截1.5K+不合理用户查询 -自动禁用有问题查询来源 -集群内服务器剩余空间趋同 -业务高峰期扩容服务器缩容 -“冷”“热”数据定期搬迁 系统级监控指标 -CPU -内存 -磁盘IO -网络IO -其他系统服务 内核级监控指标 -ebpfmetrics -内核异常 -系统中断情况 -硬件监控 -其他底层服务 日志统一采集 -syslog -kernel-log -安全登录日志 -auditlog -服务启停日志 Trip-All-In-One-AGENT 操作系统 硬件 网络 安全审计 格式和命名统一 使用统一的监控Agent可以确保所有采集的数据采用一致的格式和标准，便于后续的存储、处理和分析。 统一的命名规范可以减少数据混淆，确保不同来源的数据可以正确关联和对比。 集中管控 集中配置：通过统一的Agent，可以集中管理和配置监控策略，减少了分散管理带来的复杂性和错误风险。 统一策略：可以应用统一的数据采集 、存储和处理策略，确保所有数据治理措施的一致性和有效性。 安全合规 可以实施统一的安全策略，如数据加密、访问控制和审计日志，确保数据的安全性和合规性。 监控Agent在安全审计中是一个重要的环节，可以确保安全策略的收口，自动化巡检，策略覆盖度的提升落地 。 资源回收 定期归档 “低效”数据 价值落地 AIOPS平台 “优质”数据 规范治理 Tracing 统一存储 Logging Metric 统一查询 -数据采集-由可观测平台提供统一的数据抓取和推送消息队列 -配置中心-由AIOPS团队提供规则配置存储 -智能引擎训练-AIOPS团队消费消息训练时序曲线。 案例实0践4与展望 “运维之眼” -监控工具提供基础数据 -可观测平台提升数据质量 “运维之手” -自动化运维工具API调用 -运维流程workflow AIOps小助手 问题诊断 决策执行 运维操作 数据标准化 工具接口标准化 发现问题 匹配规则 自动执行 -典型场景包括：故障磁盘自动拉出集群；故障机器自动隔离；发现某类型日志自动重启应用； -规则明确、执行流程固定、影响面可控的情况，接入AIOPS助手可以显著提升工作效率、降低故 障处理时间 发现问题 智能诊断 日常运维工作中的痛点问题-RCA会议自动总结 -可观测性平台提供基础数据 -借助大模型的能力，进行高效总结 -典型场景包括：智能告警、智能变更、根因分析、容量管理 -被动式->主动式故障管理和故障防御机制 业务日志Trace 运维经验积累 告警补缺 容量管理 流程优化 告警关联 发现“冒烟点” 分析影响范围 升级处理 应用观测数据 基础监控数据 黄金三指标 “冒烟”事件 知识积累 自动变更 行为审计 故障预测 变更授权 根因分析 告警自愈 “手”“眼”合一，可观测平台持续升级，自动化工具+知识库建设形成规范 AIOps小助手 AIOps智能Agent 规则匹配自动执行 复杂场景辅助人工决策 THANKS 大模型正在重新定义软件 LargeLanguageModelIsRedefiningTheSoftware
