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

aiSRE工程狮 aiSRE工程狮 博客等级 墨衍会员 · AI 创作全网分发 墨衍智能分发 本文由作者通过墨衍一键同步至各平台 1分发平台 1k累计阅读 1.1k平均单平台 已同步平台 优快云 微信公众号 微博 知乎 掘金 百家号 博客园 抖音 小红书 你的文章也可以这样分发 墨衍会员 ¥399起/年，写一次发全网 我也要 码龄5年
关注
原创 2025-10-27 11:09:10 1k 阅读 AI 写同款· GEO 优化 ›
4.探索Dynatrace系统组件 Dynatrace ActiveGate充当Dynatrace OneAgent和Dynatrace服务器之间的代理。如果您的基础架构依赖VMware虚拟化，Dynatrace可以深入了解您的虚拟机如何影响Web应用程序的性能。你可以在物理或虚拟主机上安装Dynatrace代理，或者配置Dynatrace来监控你的云基础设施或容器。可以安装和配置可选Dynatrace组件，以将Dynatrace功能拓展到整个环境。Dynatrace可以与亚马逊网络服务集成，以智能监控在亚马逊云中运行的服务。 阅读详情

原文地址：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
结果并不正确。

收录于
故障定位

当前文章被收录于：

故障定位
5 篇文章 0 人学习
订阅专栏 查看详情
标签
#kubernetes #java #docker
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
可观测领域的王者Dynatrace的故障定位能力验证 测试系统EasyShopping，是一个包含17个业务服务的复杂微服务系统，部署在k8s平台上。DataBuff的One-AgentDynatrace的One-Agent。 阅读详情

相关推荐

51、Dynatrace – 应用性能管理

本文全面介绍了 Dynatrace 这款基于人工智能的应用性能管理（APM）工具，涵盖了其核心功能、应用场景、安装配置流程以及与其他监控工具的对比优势。文章还详细解析了 Dynatrace 的智能算法、依赖关系图、性能瓶颈分析等高级功能，并提供了优化建议、事件管理和用户体验监控的最佳实践。通过多个行业的真实案例，展示了 Dynatrace 在提升系统稳定性、加快故障诊断和优化应用性能方面的强大能力。最后，文章展望了 Dynatrace 未来的发展方向，并推荐了相关的学习资源和社区支持平台。

g2h3i4j5的博客 198

Dynatrace与人工智能运维核心解析实践

随着IT环境的日益复杂，互联网的运维们，有哪些痛点是容易忽略掉的？ 当前自动化的人工智能运维方式也变得至关重要，这种运维方式可以帮忙IT运维人员在成千上万的跨域数据节点中，自动判断应用性能状态，以及自动定位应用性能问题的根源，这种突破性的运维方式重新定义了应用性能监控的工作模式，使得团队可以更加关注于软件功能的交付，并同时大幅减少性能问题的诊断时间。

Dynatrace-OneAgent-Ansible：此Ansible角色安装Dynatrace OneAgent

Ansible角色：Dynatrace OneAgent 这个角色负责将Dynatrace OneAgent部署在具有不同可用配置Linux和Windows操作系统上，并确保OneAgent服务保持运行状态。 它提供了与各种OneAgent配置文件进行交互的任务。 注意：此角色仍在积极开发中。 可能存在不确定的问题，并且角色变量可能会随着开发的继续而变化。 要求 要使用此角色，需要满足以下条件： ansible> = 2.9.0 然后，您需要为角色提供两个关键信息： 环境网址：托管https://{your-domain}/e/{your-environment-id} | SaaS

Dynatrace系列之- 标记常见问题

Dynatrace系列之- 标记常见问题 在大型环境中，系统的某些方面可能会持续触发不必要的警报。这些告警可能来自非关键组件或者是非关键情况下的资源不足的问题。通常这些问题不需要人员响应。 为了减少此类警报并避免发出垃圾告警邮件，Dynatrace AI根因分析引擎会自动检测那些经常发生但是并非重要的问题。Dynatrace通过观察指定期内（一天和一周）那些受监控实体的问题模型来检测此类频繁出现的问题。 当在这些时间段内多次检测到同一问题时，Dynatrace会根据阈值突破的实际严重程度与问题的持续时间来评

Kang的博客 1166

从工艺文件到寄生分析：手把手教你用华大九天RCExplorer做版图预检（附ITF文件解析）

本文详细介绍了华大九天RCExplorer工具在模拟IC和版图设计中的应用，从工艺文件解析到寄生参数提取的全流程。通过ITF文件的深度解析和实战案例，帮助工程师掌握金属层、介质层及通孔参数的关键影响，提升设计效率与准确性。文章还提供了与StarRC工作流集成的实用技巧，是国产EDA工具应用的权威指南。

weixin_42522552的博客 408

实验室LIMS系统选型指南：从赛默飞到金现代，5大主流方案横评

本文深入分析了实验室LIMS系统选型的5大核心维度，包括架构选择、行业适配性、合规性设计、智能化程度和成本模型。通过对比赛默飞、金现代等主流厂商的优劣势，提供实战避坑策略，帮助实验室管理者做出明智决策，提升运营效率和合规水平。

plum99的博客 259

2026企业可观测性平台选型指南：如何选择最适合企业的全栈可观测方案？

摘要： 2026年，企业可观测性市场加速向“必备”转型，全球规模预计达35.3亿美元（年增11.7%），AIOps市场增速更高达30.2%。Gartner评估19家厂商，重点关注AI可观测性、成本优化等能力。企业选型需先厘清三大核心问题：数据主权要求、IT架构复杂度及信创适配性。本文提出四步决策框架：1）明确需求优先级；2）评估方案核心能力（如国产化方案嘉为蓝鲸或海外SaaS工具）；3）考察AI实用性与成本控制；4）通过POC验证。针对不同企业类型（如金融、云原生），推荐差异化选型路径，并强调AI能力需结合

trainsignalcn的专栏 359

用Matlab搞定Delta并联机器人运动学：从建模到正逆解完整流程（附代码）

本文详细介绍了如何使用Matlab实现Delta并联机器人的运动学分析，包括几何建模、正逆解求解及可视化验证。通过符号计算和数值迭代法，解决非线性方程组问题，并提供完整代码示例，帮助读者快速掌握Delta机器人的运动学计算与应用。

weixin_30955617的博客 177

2026年企业APM应用性能观测工具选型指南：四大主流方案深度对比

2026年企业APM选型面临云原生与AI运维新挑战。本文对比四大主流方案：嘉为蓝鲸（国产化适配/运维闭环）、Dynatrace（AI全栈自动化）、Datadog（SaaS轻量化）、New Relic（代码级诊断）。核心选型要素包括OpenTelemetry兼容性、信创适配能力及运维闭环价值。国内企业优先考虑嘉为蓝鲸的本地化服务与全栈国产化能力，跨国企业则适合国际方案的全球化支持。企业应根据自身架构特性、业务规模及长期规划选择最优方案。

trainsignalcn的专栏 490

API安全攻防实战：从信息搜集到漏洞利用的完整路径

本文详细解析了API安全攻防实战的全过程，从信息搜集到漏洞利用，涵盖了渗透测试的核心技巧和工具使用。通过真实案例展示如何发现和利用API漏洞，如HTTP方法滥用、内容类型转换攻击等，并提供企业级防御策略和测试心得，帮助安全研究人员提升API安全防护能力。

weixin_30394981的博客 435

手把手写深度学习(27)：如果获得相机位姿态的plücker embedding？以RealEstate10K为例

用plücker embedding表示相机的位姿是一种非常常用的方法，这篇博客以RealEstate10K数据集为例子，详细讲解如何从相机的轨迹坐标中获得plücker embedding，用于下一步模型的学习。

沉迷单车的追风少年 2239

2026年企业IT运维监控与可观测方案选型：四大主流技术路线深度对比

文章摘要： 2026年企业IT架构复杂度激增，可观测性工具需求旺盛。市场调研显示，全球可观测性市场规模将持续扩大，中国企业IT运维市场也快速增长。然而，工具增多并未提升排障效率，Gartner强调需强化数据整合与合规性。本文对比四类主流方案： 一体化平台（嘉为蓝鲸）：全栈监控、国产化适配，适合复杂架构企业； 云原生平台（Datadog）：SaaS模式敏捷，但成本与合规性存短板； AI驱动平台（Dynatrace）：智能化运维强，成本高昂； 云厂商监控（AWS CloudWatch）：单一云场景轻量级适用，多

trainsignalcn的专栏 318

【ARFoundation自学04】AR Tracked Image 图像追踪识别与对应类的调用

1.添加组件 2.创建图像识别库 3.创建识别后追踪的物体（UI、模型等）

leoysq的博客 2560

2025运维监控选型：5大产品含国产化选项，从成本到效率算清投资回报

2025年传统监控难应对故障定位、根因分析等挑战，可观测成为业务连续性关键。文章对比六款主流运维监控系统，包含国产监控平台，分析其核心定位、能力亮点与适用场景，结合需求、技术栈等给出选型建议，助力企业挑选适配的IT运维监控方案。

trainsignalcn的专栏 914

[HBM] RAM Cell Self Repair | 内存单元自我修复

对抗错误的大都是冗余，内存颗粒在设计的时候也考虑增加冗余。具体的说：添加冗余或备用的存储单元行和列，及时将测试中的故障进行修复和替换，存储器修复包括行修复，列修复或两者的组合。

串起点滴 785

安卓App开发 篇三：Android SDK和API

Jetpack 是一个由多个库组成的套件，可帮助开发者遵循最佳做法、减少模板代码并编写可在各种 Android 版本和设备中一致运行的代码，让开发者可将精力集中于真正重要的编码工作。hl=zh-cnhl=zh-cnWorkManager 是 Android Jetpack 的一部分，是用于持久性工作的推荐解决方案，适用于需要通过应用重启和系统重新启动来调度的工作，也是后台处理操作的主要推荐 API。立即执行：必须立即开始且很快完成的任务，可以加急，使用和Worker，通过对调用处理加急工作。

生活在别处 1286

2026年企业可观测性平台选型：四大主流方案能力拆解与场景适配

文章摘要： 2026年企业IT架构复杂度激增，可观测性需求显著提升。市场数据显示，全球可观测性软件规模将持续扩大，但企业面临工具链割裂、根因定位困难及国产化合规压力。本文分析了四类主流方案：嘉为蓝鲸（国产全栈智能平台，适配政企信创需求）、Datadog（SaaS全栈方案，适合云原生企业）、Dynatrace（AI驱动根因分析，侧重稳定性要求高的行业）和Splunk（融合安全与可观测性）。选型需综合评估部署模式、国产化适配、AI能力、工具兼容性及成本，建议企业分阶段迁移，优先统一观测视图。不同规模与行业的企业

trainsignalcn的专栏 262

SIMATIC S7-1200, S7-1500 PID 控制[手册]

SIMATIC S7-1200, S7-1500 PID 控制[手册]

为什么要迈进NGAIOps（下一代AIOps）

自2016年Gartner首次提出AIOps概念已过去8年时间，AIOps软件工具层出不穷，这篇文章给大家介绍下什么NGAIOps? 为什么需要NGAIOps? 以及国内外的AIOps的方案路径与落地对比。

乘云数字DATABUFF官方博客 1242

LinePhone3.2.7(android端最新版本) sip客户端

SIP客户端For android：LinePhone3.2.7(最新版本)，官网地址：http://www.linphone.org/

华为的C语言编程规范.pdf

华为技术有限公司内部技术规范。本规范制定了编写C语言程序的基本原则、规则和建议。从代码的清晰、简洁、可测试、安全、程序效率、可移植各个方面对C语言编程作出了具体指导。
上一篇： DataBuff 多模态AI在可观测平台上的应用实践（龙蜥系统运维联盟Meetup分享）
下一篇： 从巴比馒头的“洗菜流水线”，来看“telemetry pipeline”工具的火热兴起
点赞 16
评论 0
书签 书签 18
aiSRE工程狮
aiSRE工程狮
博客等级 码龄5年 423粉丝 92原创
+ 关注 专栏目录 订阅专栏
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值