引言
在教育行业数字化转型进程中,某教育头部客户的运维团队面临自建 SkyWalking 监控系统的严峻挑战。随着业务规模扩张,系统运维复杂度呈指数级增长,运维团队每月 20% 以上工作时间都消耗在监控系统自身故障处理且微服务架构下的故障排查效率极低 ,针对这一现状,该团队通过技术架构升级与优化,与腾讯云可观测平台产研团队共创,实现了从传统自建监控体系向腾讯云可观测平台的迁移,同时也为教育行业监控系统转型提供实践范例。
一、自建监控系统的核心痛点
1.1缺少关键链路埋点
在基于微服务架构的课程购买业务流程中,自建 SkyWalking 监控系统链路数据复杂,与前端性能监控联动多次出现数据缺失的现象,导致业务调用链无法完整呈现。而链路数据的缺失直接使得运维人员难以构建完整的业务调用逻辑,大大增加了故障排查难度。
例如当 C 端用户购买课程成功后,异步通知服务通过 RabbitMQ 发送学习资料,但是出现部分学习资料未发送的现象。这是由于 SkyWalking 仅仅记录了订单服务发送消息的 ExitSpan,而消费端链路完全缺失的情况,深入排查才发现,是因为 RabbitMQ 插件未启用。
1.2运维成本持续攀升
而随着该头部客户业务的不断发展,IT 团队的监控系统运维成本显著增加。在迁移上云之前,每月需投入大量的时间进行探针配置调整:或解决中间件兼容性问题,或追齐开源新版本,同时,由于前端监控与后端链路追踪数据缺乏有效整合,运维人员需通过人工方式进行日志关联分析,消耗大量人力成本。
1.3故障排查效率低下
当用户反馈页面加载缓慢等性能问题时,运维人员需在多个系统间交叉验证数据。
以某次课程详情页加载异常为例,用户反馈页面图片和视频资源加载不全,运维人员需先在自建前端监控系统中查看资源请求耗时,发现静态资源请求平均延迟超过2 秒;随后切换至 SkyWalking 检查后端链路,确认课程服务接口响应正常;最后在日志系统中筛选对应时间戳的请求日志,发现 CDN 返回 404 错误码。
通过对比三个系统的数据,最终才定位到 CDN 节点因配置更新遗漏,导致部分地区用户无法获取最新资源版本。这类跨系统排查问题大大增加了运维人员的排障难度。
最终,经过长达几年的使用后,此 IT 团队最终决定不再使用自建 SkyWalking 系统,将目光投到了云上。
二、可观测 APM 迁移与优化方案
在客户启动上云选型阶段,团队通过前期技术调研,深入剖析客户现有系统架构,发现其存在微服务链路追踪逻辑复杂、异构探针共存需求迫切等痛点。
针对这个现状,前后满足了支持自定义 TraceID 功能,确保多业务场景下链路数据精准关联;通过技术攻关实现 SkyWalking 与 Otel 探针并行工作,既兼容客户原有监控习惯,又拓展新的观测能力;同时也完成阿里云 ONS 消息队列的适配优化,保障消息中间件调用链路的完整可追溯。
经过多轮 POC 测试验证,这些定制化方案在数据准确性、系统兼容性等核心指标上均优于竞品,最终赢得客户认可,顺利推进上云落地。
2.1兼容前端生成的 TraceID
基于客户想要“先从单一业务先行接入腾讯云 APM”,也为了满足客户的业务在接入 APM 后,能够沿用外围服务生成的 TraceID 从而快速建立一条链路与业务单号关联,提升排查问题的效率的需求:
腾讯云可观测团队结合该业务微服务架构特点,制定了以 OpenTelemetry 为核心的过渡方案,并针对异构系统数据衔接进行定制化改造:
从而帮助用户上云,从以下几个方面实现监控能力升级:
多维度指标采集:除基础的平均响应时间、吞吐量等指标外,还可以采集微服务 RPC 调用耗时、数据库慢查询、堆栈详情、性能剖析、线程池与连接池分析等高阶能力为应用诊断提供全面数据支撑。
高精度链路追踪:通过火焰图追踪技术,将用户业务操作(如课程支付)拆解为多节点调用链路,各节点耗时测量精度达毫秒级别。
安全漏洞扫描:腾讯云可观测 APM 与安全团队深度协作,为用户提供覆盖安全漏洞扫描、SQL 注入检测的一体化能力。
2.2新旧监控体系过渡方案
随着客户业务接入腾讯云可观测 APM 成效显著,更多业务的接入需求接踵而至。然而,部分业务因历史架构限制,短期内无法将 Skywalking 探针切换为腾讯云 OpenTelemetry 探针。Skywalking 采用的 SW8 链路协议标准与腾讯云 OpenTelemetry 探针遵循的 W3C 链路协议标准存在差异,若在同一系统中混用,极易引发链路断裂,严重影响问题排查效率。
针对这一挑战,腾讯云可观测 APM 团队通过技术革新,实现了链路协议的统一兼容:
探针灵活适配:改造腾讯云 OpenTelemetry 探针,新增启动参数配置功能,支持用户根据业务需求手动指定链路协议标准,无论是 SW8 还是 W3C 协议,均可一键切换,大幅提升部署灵活性。
服务端智能解析:升级腾讯云可观测 APM 服务端,使其在接收 OpenTelemetry 方式上报的 Trace 数据时,能够自动识别并处理符合 SW8 格式的 TraceID。这一改进打破了协议壁垒,确保不同探针产生的数据能在可观测 APM 平台中无缝整合。
通过探针与服务端的协同优化,在混合使用 Skywalking 与腾讯云 OpenTelemetry 探针的复杂架构下,成功实现全链路协议标准统一,彻底消除因协议差异导致的断链问题,保障业务监控数据的连续性与完整性,为企业监控系统的平滑过渡与性能优化提供坚实支撑。
2.3阿里 ONS 消息队列监控集成
同时,由于该头部客户团队部分资源在阿里云的现状,故而在对消息队列的支持部分,有支持阿里 ONS 消息队列的需求。腾讯云可观测团队针对此需求进行了紧锣密鼓的开发支持,最终达到无痛使用的效果:
三、迁移实施结果
经过 3 个月的运行验证,某教育头部客户团队从自建迁移上云,使用腾讯云可观测 APM 后取得了显著成效:
故障定位效率:平均故障定位时间从小时级别缩短至 10 分钟,配合告警->控制台定位,典型案例中支付接口异常问题仅耗时 7 分钟即可定位到具体是哪个接口由于什么样的错误导致的故障。
比如在某次促销活动中,突发支付成功率降低的情况,可观测平台 3 分钟内触发告警,显示 “支付网关→订单服务” 链路异常,运维人员通过告警一键跳转控制台查看调用链详情,发现订单服务的 CreateOrder 接口因参数校验异常导致 500 错误,7 分钟内即锁定问题为前端传参格式未适配新版课程 ID 规则,较以往排查效率有了显著提升。
腾讯云可观测 APM 团队通过这一系列的优化措施协助该客户团队监控上云,围绕故障定位、运维成本、用户体验三大核心痛点展开了针对性的优化,实现了从“被动应对”到“主动预防”的跨越:
四、实践经验总结
在整个监控系统迁移过程中,某教育头部企业与腾讯云团队通过一系列策略保障项目顺利落地。这些策略涵盖了对历史系统的兼容、混合架构的管理以及迁移过程的验证,有效降低了迁移风险,确保了业务连续性和系统稳定性。
4.1历史系统兼容策略
采用 W3C 标准校验与兼容模式相结合的方式,对前端原有 TraceID 体系进行平滑过渡,避免因系统升级导致的数据兼容性问题。大大的降低了客户在迁移上云时的难度,也保证了在整个迁移过程中,客户的 APM 监控系统时可用的。
4.2混合架构管理规范
在新旧系统并行阶段,制定严格的数据传输协议标准,如强制实施 SW8 协议,确保不同系统间数据交互的一致性。明确要求新旧系统间的 RPC 调用、HTTP 请求、消息队列传输等场景,必须携带 SW8 协议定义的 TraceID、SpanID 等关键头部字段。例如:在课程购买流程中,旧系统(单体架构)调用新微服务架构的订单服务时,需通过请求头传递 SW8-Traceid 和 SW8-Spanid,确保 SkyWalking 等监控工具能串联跨系统调用链路,保证数据交互的一致性。
4.3分阶段验证机制
在正式迁移前,测试环境先接入腾讯云可观测平台 APM 业务系统,进行了需求、性能等方面的全面验证后,再持续灰度正式环境迁移上云。确保后序正式环境运行的稳定性与可靠性。
结语
某教育头部企业团队历时 6 个月的监控系统迁移项目,成功实现从自建监控体系向可观测平台 APM 的转型。此次实践不仅解决了性能监控难题,还为教育行业技术架构升级提供了宝贵的实践经验,助力教育行业在数字化转型的道路上迈出更加坚实的步伐。
联系我们
如有任何疑问,欢迎加入官方技术交流群
关于腾讯云可观测平台
腾讯云可观测平台(Tencent Cloud Observability Platform,TCOP)基于指标、链路、日志、事件的全类型监控数据,结合强大的可视化和告警能力,为您提供一体化监控解决方案。满足您全链路、端到端的统一监控诉求,提高运维排障效率,为业务的健康和稳定保驾护航。功能模块有:
- Prometheus 监控:开箱即用的 Prometheus 托管服务;
- 应用性能监控 APM:支持无侵入式探针,零配置获得开箱即用的应用观测能力;
- 云拨测 CAT:利用分布于全球的监测网络,提供模拟终端用户体验的拨测服务;
- 前端性能监控 RUM:Web、小程序等大前端领域的页面质量和性能监测;
- Grafana 可视化服务:提供免运维、免搭建的 Grafana 托管服务;
- 云压测 PTS:模拟海量用户的真实业务场景,全方位验证系统可用性和稳定性;
- ......等等