可观测领域的王者 Dynatrace 的故障定位能力验证

在可观测性领域，Dynatrace 可以说是公认的老牌王者，而 Databuff 是这一领域的后起新秀，二者都具备较强的故障定位能力。

今天我们将进行一场测试，验证二者在故障定位能力上的差异。到底谁更胜一筹？请看下文。

01 测试环境介绍

测试系统 EasyShopping，是一个包含 17 个业务服务的复杂微服务系统，部署在 k8s 平台上。

在这套系统中分别安装如下 2 个探针：

• DataBuff 的 One-Agent

• Dynatrace 的 One-Agent

服务拓扑

One-Agent 安装完毕后，DataBuff 的空间地图效果如下所示，体验地址 https://sandbox.databuff.com

Dynatrace 的空间地图效果如下所示：

从展示服务拓扑图上看，DataBuff 相对更有条理一些。

02 故障定位体验

接下来我们将针对不同场景进行故障注入，分别测试二者的故障定位效果。

内容太长，先看结论！

DataBuff 定位效果

• 定位准确：9 个案例

• 定位错误：1 个案例

Dynatrace 定位效果

• 定位准确：6 个案例（每个案例或多或少不够精准）

• 定位错误：4 个案例

测试结果表

下面是对每个测试案例的详细阐述。

案例 1 DB 客户端-SQL-所有实例-耗时故障

对 service-g::k8s 的所有实例注入某个 SQL 耗时突增的故障。

DataBuff 的定位如下所示：

10 点 06 定位到故障，故障详情如下所示：

定位给出如下 4 点信息：

• 故障服务是 service-g::k8s

• 所有实例都有问题（没有给出实例就代表并不是单个实例的问题）

• 仅仅某个 SQL 有问题：给出问题 SQL 为 select * from tableA

• 耗时突增的故障

Dynatrace 的定位如下所示：

10:08 定位到故障，比 DataBuff 晚了 2min，产生了 2 个 Problems（这里不太合理，其实应该是同一个故障），其中 dcgl 的故障详情如下所示：

定位给出如下信息：

• 所有实例都有问题（没有给出实例就代表并不是单个实例的问题）

• 仅仅某个 SQL 有问题：给出问题 SQL 为 select * from tableA

• 耗时突增的故障

基本也算是定位到了，但是缺少故障树。

案例 2 DB 客户端-SQL-单实例-错误故障

对 service-g::k8s 的单实例注入某个 SQL 错误的故障。

DataBuff 的定位如下所示：

10:35 定位到故障，故障详情如下所示：

定位给出如下 4 点信息：

• 故障服务：service-g::k8s

• 单个实例有问题：实例 10.42.1.22 有问题

• 仅仅某个 SQL 有问题：给出问题 SQL 为 select * from tableA

• 失败突增的故障

Dynatrace 的定位如下所示：

最初是多个 Problem，之后自动合并成了 1 个 Problem，Problem 详情如下所示：

基本也定位到了是数据库 dcgl 错误率突增的故障，给出如下信息：

• dcgl 的失败突增的故障

• 定位到具体的 SQL

• 但是没有定位到实例

案例 3 DB 客户端-Connection-所有实例-耗时故障

对 service-g::k8s 的所有实例注入 DB 连接池获取连接的耗时故障。

DataBuff 的定位如下所示：

定位给出如下 3 信息：

• 故障服务：service-g::k8s

• 所有实例都有问题（没有给出实例就代表并不是单个实例的问题）

• 耗时突增的故障

Dynatrace 没有定位到任何信息

案例 4 接口级-Redis-客户端-command-所有实例-耗时故障

对 service-g::k8s 的所有实例的 callRedis 接口注入 Redis 某个命令的访问耗时突增的故障。

DataBuff 的定位如下所示：

定位给出如下信息：

• 故障服务：service-g::k8s

• callRedis 接口有问题

• 所有实例都有问题（没有给出实例就代表并不是单个实例的问题）

• EXISTS 命令有问题

• 耗时突增的故障

Dynatrace 的定位如下所示：

给出 2 个 Problem（其实是 1 个故障）

并未定位到 redis 的某个命令故障，给出了 service-g 的 callRedis 接口有问题。

案例 5 Http-服务端-URL-状态码-单实例-错误故障

对 service-j::k8s 的某个实例的某个接口注入状态码 508 的错误故障。

DataBuff 的定位效果如下所示：

定位给出如下 2 个信息：

• 故障服务：service-j::k8s

• 但是并未定位到错误率突增、状态码 508、某个 URL 接口

Dynatrace 的定位效果如下所示：

Dynatrace 给出如下 3 个信息：

• 故障服务：service-j::k8s

• 某个 URL 错误

• 错误率突增

在这个案例中，DataBuff 在耗时和错误同时出现时还是有些分析不佳的地方。

案例 6 Http-服务端-URL-数据包大小-所有实例-耗时故障

对 service-j::k8s 的所有实例的某个 URL 注入数据包大小突增进而导致传输延迟的耗时故障。

DataBuff 的定位效果如下所示：

给出如下 4 个信息：

• 故障服务：service-j::k8s

• 某个 URL 错误 POST /postMethodB9

• 数据包大小突增

• 平均响应时间突增

Dynatrace 的定位效果如下所示：

和上一个故障合并在一起了（理论上是不同的故障，Dynatrace 还是不能正确区分）

案例 7 Http-客户端-URL-所有实例-耗时故障

对 service-j::k8s 的所有实例的访问服务端 servce-k::k8s 的某个 URL 注入耗时突增的故障。

DataBuff 的定位效果如下所示：

给出如下 3 个信息：

• 故障服务：service-j::k8s

• 访问下游 service-k::k8s 的某个 URL POST /postMethodB9 的问题

• 耗时突增

Dynatrace 的定位效果如下所示：

给出如下 3 个信息：

• 故障服务：service-j::k8s

• 自身接口/postMethodB9 的问题，但是并没有给出作为客户端去访问 service-k 的某个 URL 导致

• 耗时突增

案例 8 Http-客户端-URL 相互影响-所有实例-耗时故障

对 service-j::k8s 的所有实例的访问服务端 servce-k::k8s 的某个 URL 注入耗时突增的故障。

DataBuff 的定位效果如下所示：

给出如下 3 个信息：

• 故障服务：service-p::k8s

• 访问下游 service-g::k8s 的多个 URL 都耗时突增

• 其中根因 URL 是 POST /postMethodB5（它耗时过长，占用 Http 连接池，导致其他 URL 接口被迫等待）

Dynatrace 的定位效果如下所示：

定位基本不对。

案例 9 Kafka-Producer 端-Partition-所有实例-耗时故障

对 service-f::k8s 的所有实例注入某个 Partition 的耗时故障。

DataBuff 的定位效果如下所示：

给出如下 3 个信息：

• 故障服务：service-f::k8s

• 某个 topic 的某个 partition 出现了问题

• 耗时突增的故障

Dynatrace 的定位效果如下所示：

没有定位到任何信息，实际服务有问题。

案例 10 ES-客户端-Index-Method-所有实例-耗时故障

对 service-g::k8s 的所有实例注入某个 index 某种 method 的耗时故障。

DataBuff 的定位效果如下所示：

给出如下 3 个信息：

• 故障服务：service-g::k8s

• 针对远程 es 服务的 my_index_2 索引的 HEAD 方法调用出现问题

• 耗时突增的故障

Dynatrace 的定位效果如下所示：

结果并不准确。