可观测领域的王者Dynatrace的故障定位体验

原创 已于 2025-07-02 16:04:08 修改 · 584 阅读 · 16 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#kubernetes #java #docker

于 2025-07-02 15:44:54 首次发布

原文地址：https://databuff.com/resourceDetail/blog101

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

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

1 测试环境介绍

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

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

• DataBuff的One-Agent

• Dynatrace的One-Agent

服务拓扑

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

image.png

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

image.png

从展示效果上看，DataBuff相对更有条理一些。

2 故障定位体验

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

内容太长，先看结论！

  • DataBuff定位效果

    • 定位准确：9个案例

    • 定位错误：1个案例

  • Dynatrace定位效果

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

    • 定位错误：4个案例

测试结果表

在这里插入图片描述

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

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

DataBuff的定位如下所示：

image.png

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

image.png

定位给出如下4点信息：

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

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

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

  • 耗时突增的故障

Dynatrace的定位如下所示：

image.png

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

image.png

定位给出如下信息：

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

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

  • 耗时突增的故障

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

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

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

DataBuff的定位如下所示：

image.png

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

image.png

定位给出如下4点信息：

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

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

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

  • 失败突增的故障

Dynatrace的定位如下所示：

image.png

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

image.png

image.png

image.png

image.png

image.png

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

  • dcgl的失败突增的故障

  • 定位到具体的SQL

但是没有定位到实例

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

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

DataBuff的定位如下所示：

image.png

image.png

定位给出如下3信息：

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

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

  • 耗时突增的故障

Dynatrace没有定位到任何信息

image.png

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

对service-g::k8s的所有实例的callRedis接口

注入Redis某个命令的访问耗时突增的故障

DataBuff的定位如下所示：

image.png

image.png

定位给出如下5信息：

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

  • callRedis接口有问题

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

  • EXISTS命令有问题

  • 耗时突增的故障

Dynatrace的定位如下所示：

image.png

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

image.png

image.png

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

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

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

DataBuff的定位效果如下所示：

image.png

image.png

定位给出如下2个信息：

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

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

Dynatrace的定位效果如下所示：

image.png

image.png

image.png

image.png

Dynatrace给出如下3个信息：

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

  • 某个URL错误

  • 错误率突增

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

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

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

DataBuff的定位效果如下所示：

image.png

image.png

给出如下4个信息：

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

  • 某个URL错误 POST /postMethodB9

  • 数据包大小突增

  • 平均响应时间突增

Dynatrace的定位效果如下所示：

image.png

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

image.png

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

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

DataBuff的定位效果如下所示：

image.png

image.png

给出如下3个信息：

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

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

  • 耗时突增

Dynatrace的定位效果如下所示：

image.png

image.png

给出如下3个信息：

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

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

  • 耗时突增

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

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

DataBuff的定位效果如下所示：

image.png

image.png

给出如下3个信息：

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

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

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

Dynatrace的定位效果如下所示：

image.png

image.png

定位基本不对

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

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

DataBuff的定位效果如下所示：

image.png

image.png

给出如下3个信息：

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

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

  • 耗时突增的故障

Dynatrace的定位效果如下所示：

image.png

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

image.png

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

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

DataBuff的定位效果如下所示：

image.png

image.png

给出如下3个信息：

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

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

  • 耗时突增的故障

Dynatrace的定位效果如下所示：

image.png

基本也不对

中汇公司利用 Dynatrace打造可伸缩、可调整的性能测试之路
03-05
2. **自动化的故障诊断**：通过智能分析技术，Dynatrace能够自动识别和定位问题根源，显著减少了故障排查的时间。 3. **灵活的扩展性**：随着业务的发展，中汇公司的系统架构也在不断变化，Dynatrace的可伸缩性和...
OneAgent-SDK:描述Dynatrace OneAgent SDK的技术概念
05-27
因此，该存储库可被视为SDK的API和概念的独立于语言的文档。 目录 跟踪传出消息 跟踪传入消息 跟踪定制服务 添加自定义请求属性 限度 故障排除 帮助支持 进一步阅读 Dynatrace OneAgent SDK Dynatrace OneAgent ...
可观测领域的王者Dynatrace的故障定位能力验证
最新发布
weixin_43932886的博客
07-02 526
测试系统EasyShopping，是一个包含17个业务服务的复杂微服务系统，部署在k8s平台上。DataBuff的One-AgentDynatrace的One-Agent。
APO的接口级拓扑 VS Dynatrace ServiceFlow
kindlingx的博客
09-02 907
GPT介绍应用级别拓扑：应用级别拓扑是一种用于表示应用程序内部及其与其他应用程序或系统之间关系的可视化模型。它描述了应用程序中的各个组件（如服务、数据库、消息队列等）之间的交互方式，包括调用关系、数据流动和依赖关系。应用级别拓扑的目标是帮助开发和运维团队更好地理解和监控应用程序的架构、性能和健康状况。
dynaTrace Ajax版使用指南[译]
weixin_30496751的博客
01-11 373
【原文出处】：http://blog.dynatrace.com/2009/11/17/a-step-by-step-guide-to-dynatrace-ajax-edition-available-today-for-public-download/ 译者按：dynaTrace是迄今为止在IE平台上出现的最好的javascript性能分析工具，没有之一。他是不折不扣的王者。不过本人英文水平很...
k8s面试题-Pod定义中的command与args
07-02 119
从上面的输出看，Dockerfile中ENTRYPOINT指定的命令echo没有被覆盖，运行时指定的命令“ip a”被当成echo命令的参数。ENTRYPOINT指定的命令当使用docker来运行镜像时，是不能被覆盖的，但是在k8s中，当pod定义中同时配置command和args时会被覆盖。pod中指定的command和args生效了，日志输出了pod的IP地址信息。在k8s的资源对象pod中，经常会使用command和args。docker运行镜像时，指定命令“ip a”，运行后，查看pod的日志，
K8s Pod调度基础——2
Lemon__ing的博客
07-01 701
‌，通过自动化副本管理、滚动更新和回滚机制，显著提升应用部署的可靠性和灵活性。‌：若仅需共享存储（非独占），可使用 Deployment + 共享 PVC。‌，通过唯一标识、有序管理和持久化存储，为分布式系统提供稳定运行环境。StatefulSet 是 Kubernetes 管理有状态应用的‌。Deployment 是 Kubernetes 管理无状态应用的‌。通过此对比，可根据应用特性精准选择控制器，避免过度设计或功能缺失。
k8s一键部署tongweb企业版7049m6（by why+lqw）
weixin_39938069的博客
07-01 261
1.获取对应的安装包和授权,并将授权和安装包放在同一个目录下。3.提前拉取jdk的镜像（这里配置了使用openjdk:8）1.此贴仅供参考，请根据自身需求在测试环境测试和修改。2.docekr已配置远程仓库。
K8s——Pod（1）
Lemon__ing的博客
06-30 738
Pod 的设计体现了 Kubernetes 对“逻辑主机”的抽象，解决了分布式系统中容器协同的挑战，是现代云原生架构的基础组件。通过镜像拉取与重启策略的灵活组合，Kubernetes 实现了‌。
Kubernetes（K8s）_15_调度原理
爱喝可乐的w
06-30 1006
Kubernetes的调度器原理源码解读
六、K8s管理
不能将运气当成战略！
06-30 1038
ConfigMap也是k8s的一种资源，主要用于存储配置数据，如程序的环境变量、配置文件等。ConfigMap可以实现把应用程序等配置信息从容器镜像或者代码中分离出来，从而可以更容易等管理和更新配置，而不必重新构建应用程序。
k8s pod深度理解
2401_83683659的博客
06-30 321
HTTPGetAction：HTTP Get 请求状态码 200-400 则健康 检测容器是否正常运行，失败则重启容器。就绪探针（ReadinessProbe） 同上 检测容器是否准备好接收流量，失败则不路由流量至该容器。kubelet 创建：目标节点的 kubelet 调用容器运行时（如 Docker）创建容器。所有容器的父容器，负责回收僵尸容器，同时它为pod中的容器提供了统一的网络及统一的共享存储。就绪标记：所有容器通过检测后，Pod 进入 Running 状态并接收流量。
K8s + Springboot 如何实现 优雅停机 + 不停服更新
u013517141的专栏
06-27 914
配置就绪/存活探针的关键就是，我们的系统有提供对应的探针，巧了，如果我们的 springboot 项目已经引入了actuator依赖，就是已经待了对应的探针的；maxSurge: "25%" ：在更新过程中最多可以创建当前副本数的 25% 的额外 Pod，从而加快更新速度。但是，光实现优雅停机，服务的高可用性还是没有得到完全保障的，我们好需要实现，服务的不停服更新才可以！不停服更新的关键点就在于：要实现 滚动更新 + 就绪/存活探针 的配置！确保服务在停止前处理完现有请求，减少错误，避免数据异常；
k8s pod深度解析
2501_91114776的博客
06-30 803
Pod 是 Kubernetes（K8s）中最小的部署和管理单元，它代表着一组紧密关联的容器集合，这些容器共享网络、存储等资源，共同完成特定的应用功能。
k8s创建定时的 Python 任务（CronJob）
weixin_45735391的博客
06-30 841
问题原因解决方案Pod 长时间处于Running状态Istio 注入了容器，它不会随主容器退出而退出在 CronJob 上添加注解。
k8s pod调度基础
2401_83683659的博客
07-01 289
在节点上运行一个pod副本、当有新的节点加入集群时，会为他们新增一个pod，当节点从集群被移除，这些pod会被回收，删除daemonset将会删除它创建的所有的pod。statefulset（有状态集，有副本）- 滚动更新（镜像）、pod扩缩容、级联与非级联删除。部署无状态服务时使用deployment（部署），deployment部署后，借助复制集管理pod。级联删除：删除statefulset时，statefulset和它的pod都会被删除。请求数据->依赖他者，自身有则返回，自身无借助他者返回数据。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值