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

乒乓狂魔1478673997000
0 阅读1分钟

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

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

01 测试环境介绍

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

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

  • DataBuff的One-Agent

  • Dynatrace的One-Agent

服务拓扑

One-Agent安装完毕后，DataBuff的空间地图效果如下所示（体验地址 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 的定位效果如下所示：

结果并不准确。

avatar
文章
阅读
粉丝