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