可观测领域的王者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 的定位如下所示：