可观测性工具的盲区与故障排查困局

云原生常见可观测性工具的用法

Tracing

Tracing 可以追踪一次用户的请求，从而大致定位问题节点。如果运气好，是可以直接呈现某段代码的问题，比如问题就是SQL语句慢，或者执行了非常多次的redis操作导致整个请求慢，但是仍然有很多的时候只呈现了 Controller 方法执行时间长。

Logging

如果请求出现错误，在整个 Logging 体系中搜索错误日志是很快能够定位出错误的原因的，但是如果是请求发生了慢的现象，就得结合 Tracing。Tracing 基本定位到某个Controller 的问题，日志提供进一步的问题，排查到底是为什么慢，能否排查出问题取决于日志记录完备情况，所以经常出现的情况是补充日志进一步排查问题。

Metrics

通过 Metrics 中的SRE黄金指标能够很快确定业务是否正常，是否需要人为干预。但是一旦到某个业务慢，通过tracing和日志也没有发现直接线索，这个时候就只能通过 Metrics 找到有问题节点资源饱和度指标，看各种指标异常，不断地猜测试错验证了。

这里面存在两个大的问题：工具集成性差和盲区导致排障困难

集成性差是工程性问题，是次要问题

根据前文提到 Tracing、Logging、Metrics 工具在不同场景下使用，在不同工具之间跳转很麻烦会导致排查故障效率不高，但这是个工程问题，很多开源项目都在致力于解决这个问题。比如 OpenTelemetry 社区就致力于解决这个问题，会将三者从不同的线头糅合成一个线头，包括很多商业工具也都在界面跳转等易用性上发力，这个问题终将能够解决。