陈浩然, 携程无线技术高级总监, 负责无线委员会和无线基础工程团队
刘李丰, 携程无线基础服务和平台总监
作为 2017 年携程无线技术平台化的另一重点项目, 全新 APM 平台改变了原有性能监控平台的设计思路, 转为从全球化维度进行性能监控, 以满足公司在新业务场景下的端到端性能监控需求
携程无线 APM 历史
提到携程原有的无线 APM 平台, 不得不提 UBT 平台 UBT (User Behaviour Tracking) 平台最初的目的是用于收集用户行为, 其网络通道是自建的通道服务, 和业务服务通道相隔离刚开始一些性能相关的数据也通过 UBT 通道上传至后端处理, 后期为了提高性能数据采集的实时性, 把性能数据和普通用户行为数据进行区隔, 所有性能数据都会实时上传至后端
最初的性能监控是围绕网络性能展开, 以服务为主维度进行监控 (图 1), 这是以当时对业务服务进行集中优化为背景的
图 1 早期实时网络性能监控
为了方便 Dev 开发人员跟踪某个服务的性能数据, 又按照版本和服务维度按照小时级聚合网络性能数据 (端到端成功率平均耗时和耗时分布, 见图 2), 这样每个版本服务的性能优化效果很清晰:
图 2 小时级数据聚合
其他的监控数据还包括网络服务请求和响应数据大小服务错误类型分布以及服务耗时细分 (图 3-5), 也是为具体服务的性能优化提供数据依据:
图 3-5 多种维度数据聚合
后期我们又增加了定位启动页面加载等各类性能指标的监控, 对当时的性能优化和日常运维提供了充分依据
新 APM 平台
2017 年下半年公司的国际化业务开始加速, 原有的监控维度已不能满足技术场景的需要, 我们调整了设计思路并参考了商业 APM 的设计, 最终决定自研开发满足携程全球化业务场景的新 APM 平台
我们将携程 App 核心性能指标集中为 8 类: 网络性能崩溃启动加载定位图片 CRNIM 和 VoIP(图 6), 基础维度包括系统平台和 App 版本
图 6 新 APM 平台
网络性能
网络性能是重中之重, 所以需要从不同维度进行监控:
1. 基础网络性能
对端到端网络服务成功率, 平均耗时和访问量进行监控 (图 7), 并且提供全球热门国家和热门城市细分维度
图 7 基础网络性能
2. 网络性能组合分析
提供不同维度下的网络性能组合分析, 可以从国家城市运营商接入方式这几个方面实现组合监控, 方便发现多种组合条件下的问题 (图 8)
图 8 网络性能组合分析
3. 网络入口性能
提供携程不同网络入口的性能聚合监控, 为全球网络入口的优化提供依据 (图 9)
图 9 网络入口性能
4. 全球网络诊断 (拨测功能)
通过 App 端实现对目标站点的性能拨测和诊断, 包括 DNS 解析 TCP 连接 SSL 握手 TraceroutePing 类型数据都可以采集, 由于涉及特殊功能, 暂不公开更多细节
崩溃
App 崩溃监控在业界已经非常成熟, 难度在于崩溃数据的采集和分析能力 (图 10)
图 10 App 崩溃采集
启动加载
对 App 的冷启动时长 Android 安装后首次启动时长和 Android Bundle 启动加载时长进行监控
定位
对 App 的经纬度定位和城市定位的成功率平均耗时和请求量进行监控
图片
对 App 的图片下载成功率平均耗时和下载量进行监控, 和网络性能类似提供了全球热门国家和城市的细分维度
CRN
对使用携程 CRN 框架开发的 RN 模块加载数量和平均耗时进行监控, 为 CRN 优化提供依据
IM 和 VoIP
这两项都属于业务型技术指标的监控, 例如对各类 IM 消息和 VoIP 通话的成功率平均耗时和请求量进行监控, 也提供全球热门国家和城市的细分维度
从设计思路上可以看出新 APM 平台把重心放在全球化维度和 App 核心体验性能两方面, 上线后已经通过 APM 发现一些热点地区的性能问题, 未来我们会逐步分享相关优化实践
APM 技术细节
目前新 APM 平台已实现 100 + 种的 Metric 监控, 日处理数据量约 100 + 亿, 日写入 ES(Elastic Search) 数据量 100+G 其处理流程如下图所示:
图 11 APM 处理流程
App 客户端数据采集
Storm 流式计算, 对数据进行滤噪和聚合
计算数据写入, 以及进一步的归集
ES 数据存储
看板展示各种维度的组合数据
更多技术细节:
技术方案选型
APM 主要基于时序数据的存储和查询我们没有采取目前比较流行的 InfluxDB, 尽管在写入速度数据存储以及查询响应上, 都要优于 ES 我们采取 ES, 主要是从携程 ES 平台运维成熟度查询复杂度和系统数据量三个方面来综合考虑, ES 方案比较适合当前的技术场景
数据量大情况下的 Trade Off
维度组合多, 单单网络服务请求就可以划分为客户端版本平台网络类型国家城市等, 按照 10 个版本, 2 个平台, 4 种网络类型, 200 个国家, 1000 个城市来计算维度, M = 10 x 2 x 4 x 200 x 1000 = 16,000,000, 按照每分钟一个 Data Point, 写入量就达到约 30W / 秒, 这个数据写入量量对系统压力是非常大的
针对这个问题, 我们采取 2 种方式进行数据处理:
降维: 不是每一种监控都需要这样的模型, 有的我仅仅是看国家, 不关注客户端版本, 那我们就可以把客户端版本这个维度去掉
部分采样: 比方说城市维度, 全球有上万城市, 对于监控来说, 按照 80/20 原则, 我们采集 20% 热门城市进行监控
噪音过滤
噪音数据会对监控造成比较大影响, 比如 HTTP 请求时间, 遇到奇点数据值会达到 30 秒以上 (因客户端超时设置等影响), 这类数据在进入 ES 前, 先进行滤噪对于各种需要滤噪的数据进行配置, 在 Storm Extract 数据时进行数据处理
结束语
技术平台自身需要生命力, 相信 APM 平台也会随着业务重心的发展发生变化, 希望我们的 APM 方案能够对大家有借鉴价值, 也欢迎大家和我们交流自己的 APM 设计思路和技术方案
来源: https://juejin.im/entry/5aa1f63651882555784d8869