周昕毅-AI 驱动下的可观测平台架构升级实践.pdf

1、AI驱动下的携程可观测平台架构升级实践演讲人：周昕毅目录01携程可观测平台介绍02可观测数据治理实践03架构升级助力AIOPS04案例实践与展望01携程可观测平台介绍About -为用户提供一站式旅行服务的网站-应用数量:1w+-实例数量(虚拟机+容器):40w+-每分钟新增Metric数量:10亿+-每日新增日志存储:1PB+可观测性数据有哪些Logging-系统日志-应用日志-业务日志-负载均衡日志-第三方系统日志Metric-系统性能指标-应用性能指标-业务埋点指标-日志聚合指标Tracing-事件上下文信息-函数级别调用栈-应用调用关系“问题”在哪里“问题”为什么出现“问题”的上下文网

2、站当前有没有“问题”？聚合场景化可观测性数据有什么用监控告警-硬件/OS 异常-应用级别异常-业务指标异常故障处理-提供“上帝视角”-提升故障处理效率-基于历史经验自动解决故障根因定位-确定故障影响范围-全链路追踪-专家系统的数据依赖快速发现加速定位根本解决AIOps&可观测数据可观测数据采集可观测数据存储硬件资源基础软件应用软件AIOps智能化平台智能决策智能分析大数据处理AI工具链携程AIOps实践数据算法AIOps辅助决策层监控告警-智能告警-告警归因-故障定位-故障处理管理容量-容量评分-HPA/VPA配置推荐-容量预测&压测分析管理变更-变更风险检查-自动刹车-智能化发布携程AIOp

3、s实践-根因定位根据应用Metric报错数据和应用调用链Trace数据 自动分析当前故障关联关系，提升根因定位效率可观测平台面临的挑战有哪些微服务架构-应用数量快速增长-应用调用关系复杂云原生技术-HPA(分钟级交付数千容器)-时间序列数据库的基数膨胀1-5-10目标-1分钟发现需要秒级告警-快速定位依赖可观测体系可观测系统稳定性-一站式平台打通多个监控系统-监控数据延迟导致误告警-容量规划&指标治理体系数据及时性-海量新增日志秒级写入-日志丢失率控制-全链路传输实时性查询效率-Metric查询毫秒级响应-1h Logging查询秒级响应-日志平均保留天数7携程可观测平台介绍携程可观测平台一站

4、式产品入口Metric统一查询层日志统一查询层自研Tracing系统Metric DB1Metric DB2统一元数据Metric治理Clog系统ClickHouse冷热分层CAT系统日志归档多指标联动OTEL接入全局报表02可观测数据治理实践携程日志系统架构可观测性数据膨胀-日志量持续增长的问题-新增日志Senario:平均每月50+新增场景-存量日志场景保留天数持续增加(14-30-90)-日志容量峰值日增 1PB可观测性数据膨胀-日志量持续增长原因分析-业务自然增长造成的日志增加 最理想情况：）-存量日志需要延长时间应对客诉处理、故障分析、审计和合规需求(Top100日志平均保存时长为9

5、8天)-做加法容易，做减法很费劲，研发普遍采用详尽的日志记录策略、为了确保后续排障时能有效定位-存储字段不断增加，大量场景需要保存请求报文和访问报文，极端场景下单个报文字段长度超过20万字符-ClickHouse压缩率较高，是平均单价较低的一种存储介质，相对而言容易出现滥用的情况Logging日志治理实践从分散到统一-统一查询、统一存储-统一元数据-公司内推进日志使用最佳实践日志查询治理-用户SQL智能改写-查询QPS限制、时间范围限制-大表扫描限制-查询历史回顾日志存储治理-本地磁盘+分布式存储-冷热分离技术方案-表级别Quota-租户级别QuotaLoggig最佳实践-遵循日志统一规范-设

6、置合理的保留天数-设置合理的发送阈值-超过阈值时有合理的采样策略可观测性数据膨胀-告警数量持续增长的问题-严重的告警信息被低优先级告警信息淹没-“狼每天都来”，工程师对告警敏感性降低2024年初2024年底Metric Insert112 million/s150 million/sMetric Query4000 query/s5000 query/sTrigger Count15w18w可观测性数据膨胀-Bigeyes告警中台建设可观测性数据膨胀-Bigeyes告警中台建设可观测性数据膨胀-告警治理手段告警分级-P0/P1/P2/P3-告警定期review-及时响应率-P0/P1 告警处理