总结一下提效异常定位，首要任务就是需要量化异常，让异常可被观测到。其次就是友好的界面提示一步步引导大家定位问题。

接下来一起探讨一下如何建设小程序上传图片整体链路的可观测性，去尝试建模分析异常定位这个工程问题。

三、破而后立，MDD 劈开黑盒模型

具体到上传图片的场景中，SRE 体系关注各个环节及整体链路的可用性。MDD 思想就是需要我们提炼合适的 SLI，设定 SLO，达成共识，进而围绕这些 SLO 开展工作。

来一起看一下，上传图片各个环节中我们感兴趣的点。

这里总结一些经验：”两点一线，分两面，一面监控画像，一面异常定位“。

为了尽可能的观测各个环节，我们需要梳理一个脉络，如请求的开始到结束，抓住这两点，连成一线，分两面，一面关注长期趋势，一面关注异常分析。

具体提炼 SLI 可参考 Google VALET(Volume、Available、Latency、Error、Ticket)模型。

从图中我们可以看出，评估链路各个环节是否有风险或者有异常，需要一个参考系，长期的指标趋势和经验阈值都是参考的数据源。故而设置 SLO 有两种模式，第一根据经验设置固定阈值，如 QPS 峰值不得大于 10k；第二是设置相对值，如 code=404 环比增加 20%。

有了这些准备工作，提炼了以下 SLI 和 SLO，大家可以参考一下。

为了异常的可观测性，需要按不同的维度去细分 SLI，这次上传图片异常是由于微信灰度了特定的基础库，改造后需要收集终端相关信息，如设备平台，设备型号，微信版本，微信基础库版本以及小程序版本。

在为上传图片链路建模分析的时候，也一直在考虑能否将这些经验延伸到小程序整体的可观测性中呢？

于是进一步细化了分析维度，按不同的小程序包，统计了不同 code 码、路由、domain 的请求数及时延。这样就能更好地支持下钻，并能迁移到整个小程序异常分析中。接下来一起看一下如何落地改造各个环节以便 SLI 的收集。

四、顺势而为，落地整体链路改造

1、用户侧

• 每次小程序启动的时候发起一个探包请求，会上报一下版本信息(平台/版本/微信版本/微信基础库版本/小程序包名/小程序版本)，当然为了安全审计不会收集用户隐私相关的信息。探包请求还额外获得了小程序启动频次的粗略统计数据。

• 通过 hash 算法生成版本信息的指纹 hash_key，后续的用户请求 url 和 http header 中都携带这个 hash_key。

• 通过 hash_key 关联 kong 日志和版本信息，从而能提炼出终端不同维度的 SLI。

• 为了将整个链路串联起来，小程序每次请求生成 trace_id，并通过 header 透传下去。

• 小程序网络不佳的时候，会先将 Error 等日志信息暂存到 LocalStorage 队列中，等有网了再次上报。所有记录日志的地方都会记上 trace_id，方便后续异常定位分析。

2、网络节点

• 新增运营商标识，方便对比分析不同运营商传输的可用性。

• 收集运营商的日志，存储到 Clickhouse 中，方便后续分析，尽可能让网络传输节点可观测。

3、入口网关

• 按业务类型拆分 route_name，如上传，订单提交等等。

• route_name 支持打标签，如业务部门，所属页面等，方便告警监控及识别到的风险通知到具体的业务部门。

• 插件支持生成 trace_id 或透传已生成的 trace_id，打通 KongLog 和后端服务 TraceLog。

4、后端服务

• 增加日志埋点，分析不同图片尺寸大小的上传下载相关的指标。

• 定义好不同的 code 码，方便异常定位分析。

5、可观测平台

• 鉴于之前研发了强大的分析器，只用添加分析，告警规则就能满足这次场景需求。

• 为了节约研发成本，SLI 存储到了 Clickhouse，可视化基于 Grafana 写 SQL 绘制。

• 新增地理位置分析，将请求 ip 转换成经纬度，方便提炼地区维度的 SLI。

整个小程序日志上报的流程如下：

在改造的过程中也遇到了不少问题。

• 控制 Error 信息大小。单条信息过大会导致 Flume 收集异常，重复收集获丢失日志。

• 采样上报，控制频次。一般异常发生可能会产生连锁反应，瞬时产生大量日志，需要避免频繁上报导致用户带宽的消耗。

• 降噪处理。如腾讯周期性安全扫描可能会产生一些干扰异常，如 499 等，会影响用户维度 SLI 的准确性，需要识别这些干扰进行降噪处理。

• 提升分析性能，简化 SQL，很多分析需要连表查询，数据量增大的时候，会存在性能问题。于是添加了大量视图，重建了不同维度的索引表。将数据按分钟维度聚合成 SLI，避免了分析查询原始日志的性能开销。

接下来，一起看一下最终成果。

五、应运而生，建设可观测性平台

在整个改造的过程中，大家也看到了基本上都是一次投入，后续持续受益。整个流程运转起来后，后续就是提炼感兴趣的 SLI，并基于 Grafana 展示即可。

整个可观测性平台是基于 Grafana Clickhouse Prometheus 构建的，符合低代码平台研发，只要会写 SQL 就行。