Dynatrace 发布了一个现成的仪表盘，能把运行中的 AI 服务里发现的漏洞集中展示出来。原来团队很难看清自己的 AI 模型、Agent 和推理流程里到底运行着哪些有漏洞的开源依赖，信息分散、缺少上下文。这个仪表盘把运行时漏洞分析和 AI 可观测性结合起来，按严重程度和影响范围汇总，还提供覆盖情况表，告诉你哪些 AI 进程已被扫描、哪些还没被扫。该仪表盘现已可用，前提是先接入 AI 可观测性并开启运行时漏洞分析。
文中可用工具
- Runtime Vulnerability Analytics在运行时扫描进程，发现其中加载代码的已知漏洞
- AI Observability发现并监测 AI 服务相关实体，为漏洞视图提供数据
- OpenInference原文推荐用于接入 AI 可观测性的埋点工具
- GenAI Smartscape识别 AI 服务背后的进程实体
- LangChain原文仅作为 AI 相关开源框架名称提及，未说明具体用途
- Hugging Face原文仅作为 AI 相关开源框架名称提及，未说明具体用途
展开详情收起详情：揭示你的 AI 服务中的漏洞⌄
原文发布：2026-10-30 02:03 · 首次收录：2026-10-30
Dynatrace 这次把 AI 可观测性的数据接入打通了：不管你用的是编码 Agent、Python 大模型应用，还是基于 OpenInference 的工具，采集到的运行数据都能汇到同一个地方。原来每种工具格式不同，往往要各自搭一条接入通道，额外做不少管线工作；现在这些数据会被统一整理成同一套 gen_ai.* 数据模型。对用 Python 调 AWS Bedrock、OpenAI 或 LangChain 的团队，OneAgent 只要开一个设置就能自动采集，不用改代码；已用 OpenInference 的团队，原有埋点也能直接接入。这样团队能把精力放在做应用上，排查问题和看成本也更方便。另外，Anthropic、Google ADK 等十余种框架的 Python 传感器目前是实验状态，采集完整度可能变化，正式可用时间原文没说明。
文中可用工具
- OneAgent自动采集 Python 大模型应用的日志、追踪和 LLM 遥测，开启设置即可，无需改代码
- OpenInference面向 AI 应用的开源埋点规范，支持 33+ 框架自动采集追踪，Dynatrace 可直接接收其数据
- Claude Code编码 Agent，Dynatrace 可采集其 OpenTelemetry 信号以监控用量和成本
- Codex (OpenAI)编码 Agent，Dynatrace 可采集其遥测
- Cursor编码 Agent，Dynatrace 可采集其遥测
- Google Antigravity编码 Agent，Dynatrace 可采集其遥测
- GitHub Copilot编码 Agent，Dynatrace 可采集其遥测
- Claude Managed AgentsDynatrace 支持对其追踪，可查看 Agent 会话、模型调用和 token 消耗
- Claude PlatformDynatrace 是其官方可观测性合作伙伴，可原生导出 OpenTelemetry 追踪
- OpenTelemetry开放遥测标准，OpenInference 规范已捐赠给该项目，Agent 追踪也基于它
- AWS Bedrock原文提到 Python 应用可通过 OneAgent 采集调用它的遥测
- LangChain原文提到 Python 大模型应用可通过 OneAgent 采集其遥测
展开详情收起详情：Dynatrace 统一 AI 可观测性数据接入，覆盖编码 Agent、OneAgent 与 OpenInference⌄
原文发布：2026-10-30 02:40 · 首次收录：2026-10-30
Dynatrace 推出了一个叫「漏洞风险暴露」的新仪表板，把漏洞到底影响哪些主机、进程和 Kubernetes 环境集中到一张图里看。原来只看漏洞数量，既不知道哪些进程受影响、漏洞扩散有多广，也看不出是不是所有该扫描的进程都扫了。这个仪表板把暴露情况、受影响对象和扫描覆盖率放在一起，还支持按团队、集群、命名空间筛选，让团队先修影响面最大的漏洞，并发现没被扫描到的盲区。该功能随文章发布，原文未说明具体开放时间或付费情况。
文中可用工具
- Dynatrace提供漏洞风险暴露仪表板，汇总漏洞暴露与扫描覆盖情况
- Runtime Vulnerability Analytics对受支持技术栈的进程进行运行时漏洞扫描，并报告覆盖状态
展开详情收起详情：漏洞风险暴露：在运行时查看受监控进程的暴露情况⌄
原文发布：2026-10-23 22:46 · 首次收录：2026-10-24
2026 年 10 月 21 日，PHP 项目发布紧急更新，修复两个代号 PHP2Shell 的严重漏洞（CVE-2026-109618 和 CVE-2026-109619），严重程度评分均为 CVSS 9.2。问题出在 PHP 自身：当请求处理中途失败时，PHP 没有把内部状态清理干净，攻击者可以故意触发失败，再借留下的残留数据，在无需登录的情况下远程执行任意代码，甚至泄露密码、令牌和 API 密钥。修复办法只有升级 PHP，已发布 8.5.12、8.4.27、8.3.36、8.2.35 四个补丁版本；8.1 及更早版本没有官方补丁，需要自行打源码补丁或用发行版回溯修复。漏洞细节在补丁发布前已泄露，Cloudflare 已观测到攻击，荷兰众议院和英国 NCSC 一度下线网站预防。普通用户和企业应尽快升级 PHP 或通过系统包管理器安装修复版本，用容器的要重新构建镜像，暂时无法升级的只能用官方建议的配置降低部分攻击路径风险。
展开详情收起详情：CVE-2026-109618 与 CVE-2026-109619：PHP2Shell 严重漏洞——它是什么、该怎么办⌄
原文发布：2026-10-22 22:48 · 首次收录：2026-10-23
Dynatrace 宣布成为“SpaceX 超级智能合作伙伴网络”的启动伙伴，并推出一个已通过验证的官方插件，上架 Cursor 插件市场。原来开发者用 Cursor 这类 AI 编程工具写代码虽然更快，但代码编辑器和线上生产环境是割裂的：线上出故障时，开发者得先切到别的监控门户拼凑线索，才能弄清发生了什么、为什么发生。这次的做法是把 Dynatrace 的生产环境数据（由 Grail、Smartscape 和确定性因果根因分析提供）通过插件接进 Cursor，让 AI 代理和开发者直接在写代码的地方查看线上服务状态、依赖关系和根因。对使用 Cursor 的团队来说，排查线上故障、判断某个漏洞在真实运行环境中是否有影响、分析性能瓶颈，都可以不用离开编辑器，平台团队也能通过 Cursor 的团队市场分发插件并保留管理权限。目前该插件已作为受支持的集成可用，具体配置（平台令牌、MCP 服务器、Dynatrace skills 和 dtctl）需参考配套技术博客。
文中可用工具
- CursorAI 原生编程工作区，开发者在此写代码并与 AI 代理协作
- Dynatrace提供端到端可观测性，把生产环境上下文交给 AI 代理
- Grail为可观测性分析提供数据
- Smartscape映射系统之间的依赖关系
- Dynatrace Intelligence提供确定性的因果根因分析
- Dynatrace plugin已通过验证的 Cursor 市场插件，把生产上下文带进 Cursor
- MCP server技术博客中提到的配置组件，原文未说明具体用途
- Dynatrace skills技术博客中提到的配置组件，原文未说明具体用途
- dtctl技术博客中提到的配置组件，原文未说明具体用途
展开详情收起详情：Dynatrace 与 Cursor 打通 AI 原生开发的闭环⌄
原文发布：2026-10-23 04:21 · 首次收录：2026-10-23
Dynatrace 在9月发布了一批更新。以前，看数据库语句只能知道它执行了什么，却不知道是谁触发的；排查问题还得在不同页面之间来回切换，容易丢失分析上下文。这次新增了“服务回溯”功能，能从数据库查询直接看到上游调用链、负载分布和报错情况；分布式追踪可以在侧边浮层看瀑布图，原来的图表和筛选保持不变。QuickStart 把自动配置和手动安装放在一起，还能从问题直接打开 AI 助手 Dynatrace Assist，并用 dtwiz 自动配置 OpenTelemetry 主机监控。支持的主机现在也能和 OneAgent 监控的主机一起出现在基础设施与运营的 Compute 菜单中。这些功能已发布，具体入口和版本要求原文未详细说明。
文中可用工具
- dtwiz自动配置 Dynatrace 的入门设置和 OpenTelemetry 主机监控所需扩展与路由
- Dynatrace Assist从监控发现的问题直接打开，提供 AI 辅助信息
- OpenTelemetry Collector采集主机监控数据并发送到 Dynatrace
- OneAgentDynatrace 原有的主机监控方式，与 OpenTelemetry 监控主机并列显示
- QuickStart把自动配置和手动安装向导集中在一起，引导新用户完成设置
- Release Radar launchpad在 Dynatrace Playground 上演示九月更新效果
- Schnitzel demo app通过 dtwiz setup 生成示例数据用于入门体验
- OpenPipeline为 OpenTelemetry 主机监控配置动态路由
- Distributed Tracing在侧边浮层打开追踪瀑布图，同时保留原图表和筛选
- Services app从数据库查询语句打开服务回溯，查看上游调用链
- Infrastructure & Operations展示 OpenTelemetry 与 OneAgent 监控的主机
展开详情收起详情：Dynatrace 发布雷达 09.26⌄
原文发布：2026-10-15 23:59 · 首次收录：2026-10-16
Cognition 推出的自主软件工程师 Devin 现在可以把能力延伸到线上事故处理上（即 Devin Oncall），它不再只是写代码，而是能调查生产问题、修改代码并提交合并请求。但 AI 代理要排查事故，不能只看源码，还得知道线上哪里出问题、改了什么、修复是否有效；过去它要自己到多个数据源里翻日志和指标，费时又容易出错。这次 Dynatrace 作为 Devin Oncall 的发布合作伙伴，把生产环境的运行时信息（问题、根因、日志、指标、链路、部署事件和安全发现）通过 MCP 服务器和技能插件接给 Devin，让它在同一个工作流里就能定位并验证修复。对使用 Devin 的团队来说，这意味着从收到告警到排查、修复、验证有可能在一个会话里完成，但目前仍需配置 Dynatrace 平台令牌和相应权限，实际可用范围取决于集成配置。
文中可用工具
- DevinCognition 的自主软件工程师，可承接任务、调查问题、改代码、开合并请求
- Devin Oncall把 Devin 的能力延伸到生产事故响应，帮助团队从告警走向解决
- Dynatrace提供生产运行时智能，如问题根因、日志、指标、链路、部署事件和安全发现
- Devin Marketplace安装 Dynatrace 扩展等插件的市场
- MCP server提供对 Dynatrace 环境的带认证访问，把数据接给 Devin
- Dynatrace skills教 Devin 理解 Dynatrace 数据结构与查询方式，按任务加载
- dt-dql-essentials帮助 Devin 掌握 Dynatrace 查询语言 DQL 的语法和查询模式
- dt-alerting指导 Devin 处理异常检测和告警相关工作流
展开详情收起详情：Devin Oncall 与 Dynatrace：为自主事件响应引入运行时智能⌄
原文发布：2026-10-16 05:58 · 首次收录：2026-10-16
Dynatrace 发文介绍“业务可观测性”如何帮金融企业把技术数据和业务环节接起来。以前银行只看系统指标，交易重复、步骤丢失、决策用了不完整数据这类问题往往要等客户投诉或监管问询才暴露。文中一家欧洲投行的贷款验证流程每天流转数百万欧元，团队用 OneAgent 从请求数据中直接提取业务信息（无需改代码），再用 Kafka Sink Connector、OpenPipeline 和 Dynatrace Business Flow 把技术信号对应到业务步骤，实时监控并告警。这样就能在问题升级成收入损失或合规风险前发现和修复。目前是厂商方案介绍，实际效果未独立验证。
文中可用工具
- Dynatrace Business Observability把技术监控数据与业务流程实时关联，帮助在故障升级前发现问题
- Appian原文仅提及贷款验证流程运行在两个 Appian 应用上，未说明具体用途
- API Connect原文作为两个 Appian 应用之间的通信方式被提及，未详细说明
- Kafka原文作为流程中的消息通信技术被提及，未详细说明
- OneAgent无需改代码即可从 HTTP 请求中提取关键业务数据
- Kafka Sink Connector在无法直接采集数据时提供另一条数据获取途径
- OpenPipeline对原始数据进行处理和规范化，使其可用于监控与分析
- Dynatrace Business Flow把技术信号映射到业务步骤，实时跟踪指标并设置告警
- Dynatrace Playground供用户实际体验 Dynatrace 业务可观测性如何运作
展开详情收起详情：业务可观测性：金融服务业的战略要务⌄
原文发布：2026-10-14 22:44 · 首次收录：2026-10-15
OpenTelemetry Collector 是一个夹在你的应用和观测平台之间的小程序，负责把遥测数据转成统一格式并转发出去，这样你的埋点代码就不用关心后端是谁。但项目故意不提供唯一的下载版本：有精简的 Core、包含数百个社区组件的 Contrib、能用 OCB 自己拼装的定制构建，以及各厂商预打包的发行版，它们能接的数据源和稳定性都不一样。Dynatrace 这篇文章逐一介绍四种选项的取舍，帮你做出半年后不会后悔的选择。如果数据源本身就说 OTLP、拓扑简单，Core 起步比较省心；Contrib 适合探索，但生产前要逐个核对组件成熟度并裁掉不需要的部分。
文中可用工具
- OpenTelemetry Collector Core官方精简版 Collector，只带 OTLP、debug、batch、memory_limiter 等基础组件，适合简单 OTLP 场景起步。
- OpenTelemetry Collector Contrib包含数百个社区和厂商贡献组件的发行版，几乎能对接任何系统，但每个组件成熟度不一。
- OCB官方提供的构建工具，让你自己挑选组件拼装出专属的 Collector 二进制文件。
- otelcol-k8s官方面向 Kubernetes 的专用发行版，只包含供应商中立、与 K8s 相关的组件。
- otelcol-otlp官方最小发行版，只保留 OTLP 接收器和导出器。
- otelcol-ebpf-profiler官方专用发行版，通过 eBPF 做持续性能剖析。
展开详情收起详情：OpenTelemetry Collector 发行版对比：Core、Contrib、OCB 与厂商构建版，该选哪一个？⌄
原文发布：2026-10-14 04:41 · 首次收录：2026-10-14
Dynatrace 宣布其面向美国联邦机构的平台已进入 FedRAMP Class D（High）认证流程的“初始实施”阶段，并出现在 FedRAMP Marketplace 上。此前 Dynatrace 只有 FedRAMP Class C（Moderate）认证，满足不了对高敏感级别有要求的机构。这次进展意味着认证还在进行中，但联邦机构可以据此提前规划未来的可观测性、日志管理和自动化需求。注意，这只是规划依据，不代表已获认证，也不能用于 Class D（High）环境部署；现有 Class C（Moderate）服务仍照常可用。
文中可用工具
- OneAgent自动发现并为应用、基础设施、微服务及其依赖关系插桩
- Smartscape映射上述组件之间的关系
- Grail把日志、指标、追踪、事件及业务数据放在同一上下文中
- FedRAMP Marketplace展示 Dynatrace 平台处于初始实施阶段的官方列表
展开详情收起详情：Dynatrace 达到 FedRAMP Class D（High）初始实施状态⌄
原文发布：2026-10-12 20:53 · 首次收录：2026-10-13
Dynatrace 宣布其 Snowflake 可观测性功能正式可用。此前，企业用 Snowflake 做数据分析、数据管线和 AI 工作负载时，成本、性能、安全、运维和数据质量的信息分散在不同工具里，出问题常要人工在 Snowflake、监控工具和表格之间来回切换拼凑原因。现在，团队通过 Dynatrace 的 Data Observability 应用就能统一查看这五方面情况：它带引导式接入、自动采集遥测，并预置 14 个仪表盘，接上就能用，不用从空白画布搭起。对读者的用处是：更容易在用户抱怨前发现性能瓶颈、在账单飙升前发现仓库消耗异常、在数据变旧或结构被改时及早察觉，从而减少依赖这些数据的 AI 应用出错。该功能由开源项目 Dynatrace Snowflake Observability Agent 支撑，偏好自行部署的团队仍可用开源版本。
文中可用工具
- Dynatrace Snowflake Observability统一查看 Snowflake 的成本、性能、安全、运维和数据质量
- Dynatrace Data Observability app提供引导式接入和预置仪表盘的入口应用
- Dynatrace Snowflake Observability Agent (DSOA)开源代理，负责采集 Snowflake 遥测数据并支撑仪表盘
展开详情收起详情：Dynatrace 正式发布端到端 Snowflake 可观测性功能⌄
原文发布：2026-10-12 21:30 · 首次收录：2026-10-13
Dynatrace 请 Forrester Consulting 做了一项研究，测算企业用 Dynatrace 统一可观测性平台能带来多少商业价值。模型显示，一个典型企业三年可获得 466% 的投资回报，净现值 2030 万美元，不到六个月回本。这笔价值主要来自 AI 自动发现和解决故障（省下 1440 万美元）、业务表现提升（增加 310 万美元利润）以及开发者效率提高（200 万美元）。对读者的用处是：如果公司正被 AI 系统和复杂技术环境搞得监控困难、故障频繁、成本失控，这份研究提供了一个参考案例，说明统一监控可能带来的收益。不过这是厂商委托的模型估算，不是实际用户数据，具体效果因公司而异。
文中可用工具
- Dynatrace统一可观测性平台，用来监控应用、基础设施、AI 模型和代理调用，帮助发现和解决故障、控制成本。
展开详情收起详情：Forrester 研究：Dynatrace 统一可观测性模型显示 466% ROI⌄
原文发布：2026-10-09 00:37 · 首次收录：2026-10-09
在北美 We Are Developers 大会上，Dynatrace 团队观察到开发者社区关注的三个趋势：智能体“管控”（沙箱隔离，防止智能体乱跑）、可观测性与评估（在生产环境中持续监控和评估智能体行为）、以及智能体体验（文档和接口专为智能体设计）。背景是智能体越来越多地进入生产环境，出现了失控和安全事件，问题往往出在缺乏隔离和监控。解决思路包括给智能体独立计算环境、把评估从开发阶段延伸到生产运行阶段、以及提供适合智能体读取的文档和接口。对读者而言，这意味着未来开发软件时，需要把智能体当作“用户”来设计基础设施，并重视运行时安全。文中还提到存储问题（大量遥测数据）尚未获得充分讨论，Dynatrace 用 Grail 数仓应对。
文中可用工具
- BlueBoxDynatrace 推出的 AI 智能体，帮助其他智能体获取可观测性和运行时上下文
- GrailDynatrace 的统一数据湖仓，用于处理智能体产生的大量遥测数据
- MCP一种让智能体访问外部工具和数据的接口协议
- llms.txt一种供大语言模型读取的文档文件，帮助智能体理解网站内容
展开详情收起详情：管控、观测、适配：塑造智能体软件开发的三大趋势⌄
原文发布：2026-10-09 04:49 · 首次收录：2026-10-09
Dynatrace 推出了一款叫 MCP Server 的工具，能把 AI 编程助手直接连到 Dynatrace 的实时监控数据上。以前开发者用 AI 写代码时，AI 只能看到代码本身，看不到代码在生产环境里跑得怎么样，所以排查性能问题很费劲。现在开发者可以用大白话向 AI 提问，AI 会去查真实的运行数据并给出具体到代码行的修复建议。文章演示了一个案例：数据库 CPU 被一个低效查询占满，AI 找到了问题，只加两行索引就解决了，响应时间大幅下降。对开发者的好处是排查更快，但文中的演示和截图来自未来日期，实际可用状态原文未明确说明。
文中可用工具
- Dynatrace MCP Server把 AI 编程助手连接到 Dynatrace 的实时监控数据，让开发者用日常语言提问运行中的系统
- Dynatrace提供应用性能监控数据，检测响应时间退化等问题并定位根因
- Claude Opus 4.8作为 AI 编程助手读取源代码并生成修复建议（文中截图的生成来源）
- PostgreSQL作为应用背后的数据库，文中涉及为其添加 trigram 索引优化查询
- pg_trgmPostgreSQL 扩展，用于创建 trigram 索引加速 ILIKE 模糊搜索
展开详情收起详情：从症状到修复只需几分钟：使用 Dynatrace MCP 的 AI 辅助开发⌄
原文发布：2026-10-02 23:59 · 首次收录：2026-10-03