可观测性

OpenTelemetry Collector 发行版对比：Core、Contrib、OCB 与厂商构建版，该选哪一个？

OpenTelemetry Collector 是一个夹在你的应用和观测平台之间的小程序，负责把遥测数据转成统一格式并转发出去，这样你的埋点代码就不用关心后端是谁。但项目故意不提供唯一的下载版本：有精简的 Core、包含数百个社区组件的 Contrib、能用 OCB 自己拼装的定制构建，以及各厂商预打包的发行版，它们能接的数据源和稳定性都不一样。Dynatrace 这篇文章逐一介绍四种选项的取舍，帮你做出半年后不会后悔的选择。如果数据源本身就说 OTLP、拓扑简单，Core 起步比较省心；Contrib 适合探索，但生产前要逐个核对组件成熟度并裁掉不需要的部分。

Datadog 如何大规模定义服务关键性

Datadog 内部有数千个服务，以前对所有服务一视同仁地制定部署和可靠性标准，规模变大后成本太高，也不知道该把有限的可靠性投入放在哪里。他们用大语言模型读取几百篇最高严重级别的故障复盘文档，提取出哪些服务导致或被卷入事故，再结合 APM/RUM 错误链、生产流量和监控告警等信号，给每个服务打出高、低、未知的关键性等级和置信度。这样就能对真正关键的服务严格部署、收紧可靠性目标，对不关键的服务放宽标准，把精力集中在故障时最影响客户的地方。

演讲：EVE Online 如何利用头部采样观察“乐趣”

EVE Online 的工程师 Nicholas Herring 在一场演讲中，介绍了这款已有 20 年历史的网游是如何做分布式追踪和可观测性的。难点在于游戏服务器实时处理海量事件，如果样样都记录，数据量太大、成本高，还可能拖慢游戏本身。他们的做法是在追踪一开始就决定采不采样（头部采样），并配合动态指数移动平均（EMA）和确定性采样，在保证数据能反映真实运行情况的同时控制开销。对做大型在线系统的读者来说，这是一套在“看得清”和“跑得快”之间取平衡的实战经验。

Dynatrace 达到 FedRAMP Class D（High）初始实施状态

Dynatrace 宣布其面向美国联邦机构的平台已进入 FedRAMP Class D（High）认证流程的“初始实施”阶段，并出现在 FedRAMP Marketplace 上。此前 Dynatrace 只有 FedRAMP Class C（Moderate）认证，满足不了对高敏感级别有要求的机构。这次进展意味着认证还在进行中，但联邦机构可以据此提前规划未来的可观测性、日志管理和自动化需求。注意，这只是规划依据，不代表已获认证，也不能用于 Class D（High）环境部署；现有 Class C（Moderate）服务仍照常可用。

Dynatrace 正式发布端到端 Snowflake 可观测性功能

Dynatrace 宣布其 Snowflake 可观测性功能正式可用。此前，企业用 Snowflake 做数据分析、数据管线和 AI 工作负载时，成本、性能、安全、运维和数据质量的信息分散在不同工具里，出问题常要人工在 Snowflake、监控工具和表格之间来回切换拼凑原因。现在，团队通过 Dynatrace 的 Data Observability 应用就能统一查看这五方面情况：它带引导式接入、自动采集遥测，并预置 14 个仪表盘，接上就能用，不用从空白画布搭起。对读者的用处是：更容易在用户抱怨前发现性能瓶颈、在账单飙升前发现仓库消耗异常、在数据变旧或结构被改时及早察觉，从而减少依赖这些数据的 AI 应用出错。该功能由开源项目 Dynatrace Snowflake Observability Agent 支撑，偏好自行部署的团队仍可用开源版本。

Forrester 研究：Dynatrace 统一可观测性模型显示 466% ROI

Dynatrace 请 Forrester Consulting 做了一项研究，测算企业用 Dynatrace 统一可观测性平台能带来多少商业价值。模型显示，一个典型企业三年可获得 466% 的投资回报，净现值 2030 万美元，不到六个月回本。这笔价值主要来自 AI 自动发现和解决故障（省下 1440 万美元）、业务表现提升（增加 310 万美元利润）以及开发者效率提高（200 万美元）。对读者的用处是：如果公司正被 AI 系统和复杂技术环境搞得监控困难、故障频繁、成本失控，这份研究提供了一个参考案例，说明统一监控可能带来的收益。不过这是厂商委托的模型估算，不是实际用户数据，具体效果因公司而异。

管控、观测、适配：塑造智能体软件开发的三大趋势

在北美 We Are Developers 大会上，Dynatrace 团队观察到开发者社区关注的三个趋势：智能体“管控”（沙箱隔离，防止智能体乱跑）、可观测性与评估（在生产环境中持续监控和评估智能体行为）、以及智能体体验（文档和接口专为智能体设计）。背景是智能体越来越多地进入生产环境，出现了失控和安全事件，问题往往出在缺乏隔离和监控。解决思路包括给智能体独立计算环境、把评估从开发阶段延伸到生产运行阶段、以及提供适合智能体读取的文档和接口。对读者而言，这意味着未来开发软件时，需要把智能体当作“用户”来设计基础设施，并重视运行时安全。文中还提到存储问题（大量遥测数据）尚未获得充分讨论，Dynatrace 用 Grail 数仓应对。

RAGeval：多评委共识的 RAG 管线评测与可观测性工具

Yacine-ai-tech/RAGeval · Drop-in LLMOps evaluation & observability library — multi-judge consensus with disagreement alarm, 5 composite metric scorers, bootstrap confidence intervals, and OpenTelemetry tracing. PyPI: omnismart-rageval.

RAGeval 是一个自托管的 LLMOps 评测与可观测性库，面向 RAG 管线。它提供多评委共识评分与分歧告警、检索相关性、忠实度、成本与时延等指标，并支持 FastAPI、LangChain 等框架的装饰器方式接入。项目包含仪表盘用于查看实时共识遥测、查询日志、成本报告和告警。

从症状到修复只需几分钟：使用 Dynatrace MCP 的 AI 辅助开发

Dynatrace 推出了一款叫 MCP Server 的工具，能把 AI 编程助手直接连到 Dynatrace 的实时监控数据上。以前开发者用 AI 写代码时，AI 只能看到代码本身，看不到代码在生产环境里跑得怎么样，所以排查性能问题很费劲。现在开发者可以用大白话向 AI 提问，AI 会去查真实的运行数据并给出具体到代码行的修复建议。文章演示了一个案例：数据库 CPU 被一个低效查询占满，AI 找到了问题，只加两行索引就解决了，响应时间大幅下降。对开发者的好处是排查更快，但文中的演示和截图来自未来日期，实际可用状态原文未明确说明。

用 Datadog 监控 Databricks

Datadog 发布官方介绍，讲如何把 Databricks 上的分析、数据工程和 AI/ML 工作负载接入 Datadog 统一监控。原来用户只能分别看 Databricks 自带指标和下游基础设施，成本和数据质量难以串起来。这次通过三条数据采集路径（集群上的 Agent 抓 Spark 指标与日志、轮询 Databricks API 拿任务运行状态、查系统表获取成本与血缘），把作业健康、花费、数据质量和日志汇总到一个界面。读者可以据此设置作业失败告警、查看 Spark 查询瓶颈、获得集群规格优化建议，并配合云厂商集成定位底层问题；相关功能已可用，但文中未说明具体版本或价格限制。

Databricks 的原生监控资源

Databricks 官方发了一篇指南，讲怎么收集 Databricks 和它底层 Spark 的运行数据（比如性能、成本、用量）。之前这些数据分散在各处，用户不容易统一查看和排查问题。这次介绍的方法主要是用系统表来查询日志、成本和性能指标，再配合 Spark UI、作业通知和 REST API，就能做分析和告警。不过要注意，系统表的数据不是实时的，延迟随 schema 不同，所以不能拿它做秒级告警；实时监控得靠作业通知和 API。

“没人想看数十亿条追踪数据”：Dynatrace 收购 Arize，因为 Agent 需要新型可观测性

Dynatrace 是一家做应用性能监控的老牌公司，Arize 是一家专门帮企业追踪和调试 AI 模型及 Agent 行为的创业公司。过去的问题是：传统监控只能看到服务器和软件运行得好不好，但看不出 AI Agent 有没有答错话、调错工具或没完成任务；反过来，Arize 能看出 Agent 出错，却不了解底层软件哪里出了毛病。现在 Dynatrace 以 9.15 亿美元收购 Arize 并已完成交易，把上下两层监控打通，开发者就能一次查到问题出在 AI 还是底层程序。两位 CPO 还说，以后可观测性不只给人看仪表盘，更要让 Agent 自己读数据、自己采取行动，因为数据量太大，人根本看不过来。

演讲：超越可观测性——AI 时代生产运营的演进

四位讲者在一场演讲中聊了 AI 时代生产运营的变化：过去系统出故障时，工程师主要靠日志、指标等监控数据人工判断，现在可以用 AI 把运营数据变成可执行的处置建议，加快事故响应。演讲还谈到自动化与新的架构做法如何帮助团队把系统做得更容易理解，以及 AI 如何改变软件交付流程。对读者来说，这提供的是思路和方向，而非某个具体可用的工具。

Amazon CloudWatch Omni 将 CloudWatch 延伸至智能体时代

亚马逊最近推出了 Amazon CloudWatch Omni，这是一个以 AI 为核心的监控平台。它想解决的问题是：以前监控软件和监控自主 AI 智能体往往要分开做，很麻烦。这个平台把监控、评估和排查故障放在同一个环境里，让你能同时照看普通应用和 AI 智能体。对开发者来说，以后排错可能更省事，不用在多个工具之间来回切换。目前只是发布消息，具体怎么用、是否已经开放给所有人，材料没有说明。

演讲：现实世界中的自适应推荐系统：推理、评估与系统设计

Mallika Rao 在一次演讲中提出，自适应推荐系统真正的难点不在模型结构本身，而在系统怎么搭。现实中系统要边用边学，就得处理实时反馈、检索内容的新鲜度、多阶段流程的协调，以及从用户请求到返回结果的整体延迟预算。同时还得兼顾成本和可观测性这些实际运营限制。目前这只是演讲内容分享，文中没有说明有任何现成工具或产品可以直接使用。

OpenTelemetry 与 Prometheus 正在和睦相处，但仍缺什么？

这是 Road to KubeCon 系列报道，追踪 KubeCon + CloudNativeCon NA 2026（11 月 9–12 日，盐湖城）前 Kubernetes 与云原生生态的主要动态。本周聚焦可观测性：一份 2026 年调查显示，OpenTelemetry（OTel）与 Prometheus 的互操作性进步明显，平均易用性评分从 3.1 升至 3.6，认为两者难以共用的比例从 29% 降到 10%，但数据模型对齐、资源属性和元数据处理、命名与格式问题仍待解决。Atlassian 把约 10 万台主机、横跨 14 个区域的指标采集从自研 StatsD 实现迁移到 OTel，对外接口不变，聚合 CPU 减半、边车成本约降 30%；New Relic 调查发现 73% 的受访者在标准化、迁移或测试 OTel，83% 认为可观测性对 AI 生成代码必不可少。另外 HPE GreenLake 连续第二年被评为 Gartner 基础设施平台消费服务魔力象限领导者。对读者来说，这些进展意味着可观测性工具链正在走向统一，但迁移成本和跨项目互操作仍是现实挑战。

LangSmith 新动态：Engine v2、托管式 Deep Agents、微调等

LangChain 更新了 LangSmith 平台。这次带来四件事：Engine v2 能主动找代理问题，包括自动红队测试和自动验证修复方案；托管式 Deep Agents 升级到 v0.8，新增按用户隔离的认证与记忆、Slack 文件传输、通用 HTTP 接入和内置网页搜索；Trajectories 把冗长的代理会话整理成对话视图，方便排查；微调功能则把这些会话数据变成训练素材，用于定制模型，还支持搭建自定义界面。主要面向正在把 AI 代理投入生产的团队，目前具体定价和正式开放程度原文未说明。

Spring Web Services 5.1.0-M1 现已发布

Spring 团队发布了 Spring Web Services 5.1.0-M1，这是一个里程碑预览版，已可从 Maven Central 获取。该版本包含 13 项改进、依赖升级和错误修复，主要新增功能是可观测性支持，用 Micrometer Observation API 对 Web 服务交换进行指标采集和追踪；还支持用 @SoapHeader 把 SOAP 头反序列化为自定义类型，不再局限于 SoapHeaderElement。此外，故障响应加入了 WS-Security 支持，并与 Spring Framework 7.1、Spring Security 7.1 对齐。对使用 Spring 开发 SOAP Web 服务的团队来说，这次更新让监控和报文处理更灵活，也方便后续升级到新版框架。

从洞察到创新：Kiro Crew、Dynatrace 与 AWS 如何帮助团队做更多

Dynatrace、AWS 和 Kiro Crew 合作，想把“看到问题”和“动手解决”之间的空档补上。很多团队其实已经收集了大量系统运行数据，能看出哪里坏了、哪里慢，但从发现到真正处理，中间还隔着人工分析和排查。这次他们做了一个 Dynatrace 看板应用：把系统检测到的问题按生命周期排好，再由 Kiro Crew 的智能体排序，并给出一句话理由，告诉你先看哪个。工程师点开卡片就能看到问题详情，还能一键发起带上下文的调查或生成摘要。目前应用是只读的，不会自动关问题或改配置，任何操作都要真人确认。

在 Datadog 中远程配置 RUM SDK

Datadog 推出 RUM 远程配置功能，让开发者可以直接在 Datadog 界面里修改浏览器、iOS 和 Android 端 RUM SDK 的采样率、隐私设置和数据采集范围，不用改代码重新发版。过去这些设置写在应用代码里，改动必须发新版本，移动端还得等应用商店审核和用户慢慢升级，遇到故障想多采数据时来不及。现在只需在初始化代码里加一个远程配置 ID，SDK 下次启动时就会拉取最新设置。新应用默认开启，老应用手动接入即可。