链路分析 K.O “五大经典问题” - 读书笔记

 https://mp.weixin.qq.com/s/9KX04mmLNQbKZt-iQYk7qg

【流量不均】负载均衡配置错误，导致大量请求打到少量机器，造成“热点”影响服务可用性，怎么办？

通过链路分析按 IP 分组统计链路数据，快速了解调用请求分布在哪些机器上，特别是问题发生前后的流量分布变化，如果大量请求突然集中在一台或少量机器，很可能是流量不均导致的热点问题。再结合问题发生点的变更事件，快速定位造成故障的错误变更，及时回滚。

【单机故障】网卡损坏/CPU 超卖/磁盘打满等单机故障，导致部分请求失败或超时，如何排查？

通过链路分析先筛选出异常或超时请求，根据宿主机 IP 或容器 IP 进行聚合分析，快速判断是否存在单机故障。如果异常请求集中在单台机器，可以尝试替换机器进行快速恢复，或者排查该机器的各项系统参数：

【慢接口治理】如何快速梳理慢接口列表，解决性能瓶颈？

找到慢接口后，可以结合相关的调用链、方法栈和线程池等数据定位慢调用根因，常见原因包括以下几类：

• 数据库/微服务连接池过小，大量请求处于获取连接状态，可以调大连接池最大线程数解决。
• N+1 问题，比如一次外部请求内部调用了上百次的数据库调用，可以将碎片化的请求进行合并，降低网络传输耗时。

• 单次请求数据过大，导致网络传输和反序列化时间过长且容易导致 FGC。可以将全量查询改为分页查询，避免一次请求过多数据。
• 日志框架“热锁”，可以将日志同步输出改为异步输出。

【业务流量统计】如何分析重保客户/渠道的流量变化和服务质量

可以使用链路分析的自定义 Attributes 过滤和统计实现低成本的业务链路分析。

【灰度发布监控】500台机器分10批发布，如何在第一批灰度发布后，就能快速判断是否有异常？

变更三板斧“可灰度、可监控、可回滚”，是保障线上稳定性的重要准则。其中，分批次灰度变更是降低线上风险，控制爆炸半径的关键手段。一旦发现灰度批次的服务状态异常，应及时进行回滚，而不是继续发布。

不同机器流量进行版本打标 {"attributes.version": "v1.0.x"} ，通过链路分析对attributes.version 进行分组统计，可以清晰的区分发布前后或不同版本的流量变化和服务质量。不会出现灰度批次异常被全局监控掩盖的情况。

1. 基于链路明细数据进行分析的成本较高。链路分析的前提是尽可能完整的上报并存储链路明细数据，如果采样率比较低导致明细数据不全，链路分析的效果就会大打折扣。为了降低全量存储成本，可以在用户集群内部署边缘数据节点，进行临时数据缓存与处理，降低跨网络上报开销。或者，在服务端进行冷热数据分离存储，热存储进行全量链路分析，冷存储进行错慢链路诊断。
2. 后聚合分析的查询性能开销大，并发小，不适合用于告警。链路分析是实时的进行全量数据扫描与统计，查询性能开销要远大于预聚合统计指标，所以不适合进行高并发的告警查询。需要结合自定义指标功能将后聚合分析语句下推至客户端进行自定义指标统计，以便支持告警与大盘定制。

3. 结合自定义标签埋点，才能最大化释放链路分析价值。链路分析不同于标准的应用监控预聚合指标，很多自定义场景的标签需要用户手动埋点打标，这样才能最有效的区分不同业务场景，实现精准分析。