跳到主要内容

依赖报错怎么办

· 阅读需 4 分钟
Kindling-OriginX
故障根因推理引擎

依赖报错怎么办

在开发过程中,经常会依赖各种库,可能是公共的、可能是公司内部的。这些依赖给我们开发带来了很多便利,避免了重复造轮子。但是这也导致程序中的很多部分彻底变成了黑盒,出现问题时更加难以定位和确定根因,使得很多时候既没有明确的排查方向,又要面对程序执行的黑盒,根本无从下手。

常常会遇到通过日志发现底层依赖库抛出了异常,例如依赖的某个库中抛出了网路连接的错误,通过日志看到产生了Connection Refused或着响应发生了超时,但通过 APM 工具发现网络和其他依赖服务都没有问题,只能看着错误信息干着急。

依赖报错怎么办

要不先求助依赖库的开发同学看看

依赖报错怎么办

再求助负责基础设施的同事帮帮忙

依赖报错怎么办

最后只能重新想办法,可办法又是什么呢?

依赖报错怎么办

通过查看日志,我们定位到抛出异常的库。但是,我们并没有对这个库进行过任何变更,那么该如何进行接下来的排查呢?又需要哪些数据来佐证内心对问题的各种推测和猜想呢?这些推测和猜想又真的是正确的方向么? 依赖报错怎么办

需要明确方向,打开盲区

一方面需要对 Trace 数据做更加深入和全面的分析及数据关联来明确排查方向,另一方面需要真正能够彻底消除盲区,真实还原程序执行过程。

Kindling-OriginX 通过分析和关联 Trace 、Log、Metrics 数据,补充并细化 trace-profiling 的指标,深入并明确问题方向;另一方面利用 eBPF 结合 trace-profiling 技术打开程序执行和系统调用盲区,从根本上彻底还原程序执行过程,不再有黑盒存在。 依赖报错怎么办

定位关键指标,关联相关数据

依赖的相关代码中确实存在bug。 依赖报错怎么办

智能化给出可解释性的根因报告

根据报告和数据发现网络设施确实存在波动,提供相关交接数据。 依赖报错怎么办

自动化 Tracing 关联分析异常数据,彻底打开全部盲区

消除传统 Trace、Log、Metrics 数据中的盲区,找到盲区中的问题点,发现存在DNS耗时异常。 依赖报错怎么办 对于难以明确排查方向,无法定界的故障,Kindling-OriginX 快速组织和分析故障线索,通过自动化 Tracing 关联分析,以给出可解释的根因报告的方式,为这类故障提供可操作的排查方法。