背景
伴鱼后端服务采用微服务架构部署,目前在服的服务有 800+。在 2019 年,公司就引入 Jaeger,
搭建自己的调用链追踪系统,目前每天写入的数据接近 100 GB / 天。但系统在实际生产使用中,依然不甚满意,主要症结在于:
- 系统采用头部连贯采样(head-based coherent sampling)的 Rate Limiting
限流采样策略,即在 trace 的第一个 span 产生时,就根据限流策略:每个进程每秒最多采 1 条 trace,来决定该 trace 是否会被采集。
这就会导致小流量接口的调用数据被采集到的概率较低,叠加服务出错本身就是小概率事件,因此错误调用的 trace 数据被采集到的概率就更低。 - 即使错误调用 trace 数据有幸被系统捕捉到,但 trace 上只能看到本次请求的整体调用链关系和时延分布,除非本次错误是由某个服务接口超时导致的,
否则仅凭 trace 数据,很难定位到本次问题的 root cause。 - 就算 trace 数据中能明显看到某个服务接口超时,但引发超时的并不一定是该接口本身,可能是该服务(或数据库、缓存等三方资源)被其他异常请求耗尽
资源,而导致本次请求超时。
本文将从「数据基础建设」、「深入挖掘分析」和「效果展示」三个方面,来介绍伴鱼是如何解决以上难题,并沉淀和固化自己的最佳实践。