在可观测性领域，Dynatrace可以说是公认的老牌王者，而Databuff是这一领域的后起新秀，二者都具备较强的故障定位能力。
今天我们将进行一场测试，验证二者在故障定位能力上的差异。到底谁更胜一筹？请看下文。
1 测试环境介绍
测试系统EasyShopping，是一个包含17个业务服务的复杂微服务系统，部署在k8s平台上。
在这套系统中分别安装如下2个探针：
• DataBuff的One-Agent
• Dynatrace的One-Agent
服务拓扑
One-Agent安装完毕后，DataBuff的空间地图效果如下所示（体验地址 https://sandbox.databuff.com）：
Dynatrace的空间地图效果如下所示
从展示效果上看，DataBuff相对更有条理一些。
2 故障定位体验
接下来我们将针对不同场景进行故障注入，分别测试二者的故障定位效果。
内容太长，先看结论！
DataBuff定位效果
定位准确：9个案例
定位错误：1个案例
Dynatrace定位效果
定位准确：6个案例（每个案例或多或少不够精准）
定位错误：4个案例
测试结果表
2.1 案例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.2 案例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
但是没有定位到实例
2.3 案例3-DB客户端-Connection-所有实例-耗时故障
对service-g::k8s的所有实例注入DB连接池获取连接的耗时故障
DataBuff的定位如下所示：
定位给出如下3信息：
故障服务：service-g::k8s
所有实例都有问题（没有给出实例就代表并不是单个实例的问题）
耗时突增的故障
Dynatrace没有定位到任何信息
2.4 案例4-接口级-Redis-客户端-command-所有实例-耗时故障
对service-g::k8s的所有实例的callRedis接口
注入Redis某个命令的访问耗时突增的故障
DataBuff的定位如下所示：
定位给出如下5信息：
故障服务：service-g::k8s
callRedis接口有问题
所有实例都有问题（没有给出实例就代表并不是单个实例的问题）
EXISTS命令有问题
耗时突增的故障
Dynatrace的定位如下所示：
给出2个Problem（其实是1个故障）
并未定位到redis的某个命令故障，给出了service-g的callRedis接口有问题
2.5 案例5-Http-服务端-URL-状态码-单实例-错误故障
对service-j::k8s的某个实例的某个接口注入状态码508的错误故障
DataBuff的定位效果如下所示：
定位给出如下2个信息：
- 故障服务：service-j::k8s
但是并未定位到错误率突增、状态码508、某个URL接口
Dynatrace的定位效果如下所示：
Dynatrace给出如下3个信息：
故障服务：service-j::k8s
某个URL错误
错误率突增
在这个案例中，DataBuff在耗时和错误同时出现时还是有些分析不佳的地方
2.6 案例6-Http-服务端-URL-数据包大小-所有实例-耗时故障
对service-j::k8s的所有实例的某个URL注入数据包大小突增进而导致传输延迟的耗时故障
DataBuff的定位效果如下所示：
给出如下4个信息：
故障服务：service-j::k8s
某个URL错误 POST /postMethodB9
数据包大小突增
平均响应时间突增
Dynatrace的定位效果如下所示：
和上一个故障合并在一起了（理论上是不同的故障，Dynatrace还是不能正确区分）
2.7 案例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导致
耗时突增
2.8 案例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的定位效果如下所示：
定位基本不对
2.9 案例9-Kafka-Producer端-Partition-所有实例-耗时故障
对service-f::k8s的所有实例注入某个Partition的耗时故障
DataBuff的定位效果如下所示：
给出如下3个信息：
故障服务：service-f::k8s
某个topic的某个partition出现了问题
耗时突增的故障
Dynatrace的定位效果如下所示：
没有定位到任何信息，实际服务有问题
2.10 案例10-ES-客户端-Index-Method-所有实例-耗时故障
对service-g::k8s的所有实例注入某个index某种method的耗时故障
DataBuff的定位效果如下所示：
给出如下3个信息：
故障服务：service-g::k8s
针对远程es服务的my_index_2索引的HEAD方法调用出现问题
耗时突增的故障
Dynatrace的定位效果如下所示：
结果并不正确。
