大家都用过咖啡点餐小程序吗?
截至 2022 年,上海已有超过 8000 家咖啡店,容纳百余个咖啡品牌,已是全球咖啡馆最多的城市。行业内的激烈竞争不仅体现在咖啡品类创新或口味保证上,便捷的消费购买方式也成为制胜关键。很多知名品牌,都已提供线上点餐服务,用户可以通过手机 App 或是小程序在线上下单,随后去线下门店取餐或等待快递送餐上门。
「我们希望知道点餐 App 或小程序在每一个终端用户手机上的运行状态,知道他们与后台服务的通信情况。比如是否有大面积的点单页面加载卡顿、是否出现集中的支付失败异常、是否出现取餐号推送错误等等。要能尽早看到问题,并尽快解决问题,哪怕是个别用户遇到的问题,也要能清晰排查到。若等收到用户投诉后才去找问题,那就晚了,可能已经丢失了很多订单,给用户非常不好的体验,同时也对我们的品牌造成负面影响。」
这是来自某知名咖啡品牌的诉求
对点餐小程序的监测需求
1在交流过程中,客户提出重点关注应用服务的性能监控,要能收集和分析应用的性能数据,及时发现潜在的问题并修复它们。
2在客户的点餐小程序里,不仅有用到自己开发的服务,也包括一些第三方服务。如何能准确监测各个服务的质量,提供详细数据,快速定位故障责任方,也是重点需求。
之前使用过某云厂商的应用链路产品,但只能统计出第三方服务的报错数量,无法下挖更详细的信息,也无法准确记录故障现场上下文,这导致客户要在第三方服务商面前能完整复现故障后才可要求修复,经常碰到扯皮的困扰。
使用观测云后,经过大约 2 周的监控环境改造,已完美解决这些问题。
观测云使用场景
场景 1:在测试阶段就引入观测云
按传统经验,完整的监控平台往往只服务于生产环境,因为只有运维人员会使用基础设施或日志监控工具,碰到真实问题后,再回退给测试或开发去解决。但观测云认为,现代软件会面临快速迭代开发,要保证生产环境质量,监控应该更加「左移」,让测试和开发人员也能看懂监控数据,以便及早发现和解决问题。
观测云可以统一应用性能监测、基础设施监测和日志分析功能,通过应用链路自动绘制拓扑,展现调用关系,进一步分析服务调用之间的错误率、响应时间等,方便开发和测试在预发或测试环境就能看到运行状态。因为观测云提供 SaaS 服务,所以开发、测试和运维不用维护监控平台底座,甚至可以随时相互共享仪表板或数据,使应用在开发、测试和上线过程中都能全面实现可观测性,方便各个团队间实现相互协同。
场景 2:第三方服务接口报错定位
如下图所示,在自定义仪表板中,显示 RabbitMQ 队列出现报错(红色),这是一个支付请求消息队列,那意味着有用户遇到支付故障;
在视图上直接点击详情,找到具体链路请求;
进一步跳转,自动筛选出相关的错误链路信息;
继续下钻链路详情,可以看到具体的报错信息,可以看到是第三方供应商提供的接口有响应超时。
通过观测云的快照功能,把整条链路状态保存为一个数据副本,将分享链接给到第三方供应商,用直白的数据展示故障,提出报修后,快速得到了供应商的确认与修复。
经事后统计,因为该接口的间歇性故障曾造成每天约 2000 条支付报错,假设有一半的客户因为首次支付失败而放弃购买,那就是每天几万元的业务损失,每月损失可达百万元。通过观测云的全链路可观测能力,工程师们快速找到并修复了这个系统漏洞,创造了实际的业务新增收入,而实际使用观测云的工具成本,仅有几十分之一。
通过观测云,帮助该企业在 DevOps 的开发测试早期就能够及时发现问题,极大地减少了服务上线之后的错误率;同时在线上环境,也能够直接定位第三方服务报错的原因,大幅缩短 MTTR 并提升服务质量,直接推动客户的业务的增长。
观测云
技术交流|行业资讯 | 干货分享 | 最佳实践,点击 ⬇ 「关注」或在观测云官网(guance.com)添加小助手即可获取~
服务器托管,北京服务器托管,服务器租用 http://www.fwqtg.net
相关推荐: 启动速度提升 10 倍:Apache Dubbo 静态化方案深入解析
作者:华钟明 文章摘要: 本文整理自有赞中间件技术专家、Apache Dubbo PMC 华钟明的分享。本篇内容主要分为五个部分: -GraalVM直面 Java 应用在云时代的挑战 -Dubbo享受AOT带来的技术红利 -Dubbo Native Image…