从发现到定位，去哪儿网一站式可观测平台

个人简介 肖 双 基 础 架 构-基 础 平 台 技 术 负 责 人 2018年加入去哪儿网，目前负责去哪儿网CI/CD、监控平台和云原生相关平台建设。期间负责落地了去哪儿网容器化平台建设，协助业务线大规模应用迁移至容器平台，完成监控系统Watcher2.0的改造升级和根因分析系统落地。对监控告警、CI/CD、DevOps有深入的理解和实践经验。 打造更便捷的观测平台 目录 如何更快的发现故障 微服务架构下，如何辅助开发快速定位 打造更便捷的观测平台 打造更便捷的观测平台 打造更便捷的观测平台 需要尽可能多的记忆指标名 打造更便捷的观测平台-去哪儿网资源管理 打造更便捷的观测平台-应用空间 打造更便捷的观测平台-应用空间 打造更便捷的观测平台-应用空间 •单机指标下钻 •聚合排序 打造更便捷的观测平台-应用空间 •打通CMDB•动态模版•支持下钻单主机 打造更便捷的观测平台-应用空间 •打通DB元数据•实例下钻•动态模版 打造更便捷的观测平台-应用空间 •统一管理报警•报警实时追踪统计•批量处理 如何更快的发现故障 如何更快发现故障-故障数据分析 如何更快发现故障-现状 采集使用Graphite协议 之前TSDB采用的Graphite的Carbon+Whisper，Whipser因为空间预分配策略和写放大问题，会导致磁盘IO高以及磁盘空间占用过多。 当前监控系统，无论数据采集还是报警都是分钟级设计，采集使用Pull模式，定时每分钟拉取。 指标的采集和格式都是遵循Graphite协议，而建设秒级指标时必须考虑其兼容性 如何更快发现故障-采集器Client端现状 问题： 1.调度器固定的每分钟调度生成数据快照2.指标仓库只支持分钟级数据的存储 如何更快发现故障-采集器Client端改造指标仓库方案1： 1.参考Prometheus的模式Client不做快照只做数据累加或记录，由Server端在拉取时做默认的增量计算优点：客户端节省内存缺点：1.采集架构改动过大，且可能存在数据精度问题2.拉取时做增量计算对Server端压力太大指标仓库方案2：1.客户端多份数据计算和存储，生成多快照优点：1.采集架构改动小，没有数据精度问题, server压力小缺点：1.会多占用一部分内存优化：1.使用Tdigest做数据采样，内存占用量可接受 如何更快发现故障-采集器Server端现状 问题：1.任务量大时通过MQ派发耗时长2. Python做大量聚合计算时，CPU消耗高 如何更快发现故障-采集器Server端改造 •以APP维度调度•Worker自调度•支持分钟级和秒级配置和采集 如何更快发现故障-存储改造-选型 VictoriaMetrics1 优点： 优点： 1.高性能，单机读写可达千万级指标2.每个组件都可以任意伸缩3.原生支持Graphite协议4.部署简单5.社区活跃度高，更新迭代快 1.高压缩比，高性能2.可伸缩3.支持Graphite协议以及部分聚合函数 缺点： 1.部署维护复杂2.社区活跃度低3.更新迭代慢 缺点：1.针对Graphite聚合读场景下，性能下降严重 如何更快发现故障-存储压测 主机信息 •CPU: 32C•内存: 64G•磁盘:3.2TSSD 压测问题： 1.单指标查询性能良好，但是聚合指标，尤其是大量聚合指标且带有聚合函数查询时性能下降严重，甚至会超时。 如何更快发现故障-存算分离 如何更快发现故障-效果 订单故障发现时长 3Min降低到1Min之内 微服务架构下，如何辅助开发快速定位 辅助开发定位-微服务化后定位难 辅助开发定位-自动链路关联 辅助开发定位-应用异常分析 •应用维度异常数据 •关联事件、报警、日志、中间件状态 辅助开发定位-应用详情 •入口/出口详情•依赖状态详情•异常日志概览•JVM状态概览•其他异常信息概览 辅助开发定位-事件关联 •图维度的事件订阅 •事件自动聚合拆分 总结和未来规划 总结和未来规划 T h a n k s 荣誉出品