可观测性

GPU 繁忙会掩盖 Kubernetes 上缓慢的 AI 推理

HPE 的三位产品负责人（Marius Bogoevici、Mahesh Ramachandran、Karthik Subramanian）在一篇赞助文章中讲了怎么发现 AI 服务“机器很忙但用户体验差”的问题。原来大家常看 GPU 利用率，但它只说明显卡在干活，不代表回答够快、够准——首字快可能后面生成很慢，整体快也可能答错。他们建议上线前先用有代表性的提问和流量做一次“基准测试”，记下首字时间、每字生成速度、吞吐量和答案质量，上线后再拿实时表现跟基准对比，并把请求数据和 GPU、网络、数据库、向量库等底层指标对齐，才能分清是需求涨了还是哪里卡住了。读者可以据此建立更靠谱的监控和扩容依据；报道没有给出具体测试数字，相关方法和电子书属于推荐做法，HPE Morpheus 与 OpsRamp 是厂商产品介绍，并非已公开的独立评测结果。

Datadog 在 Forrester Wave™：2026 年第四季度 AIOps 平台报告中被评为领导者

Datadog 宣布自己在 Forrester 的 AIOps 平台评测里被评为“领导者”。以前工程师要自己翻告警、查问题、找根因；现在 Datadog 的 Bits AI 会帮忙定位问题并给出修复建议，还能在设定的护栏内执行修复，工程师保留最终控制权。支撑它的 Scout 1.0 模型刚进入预览，Bits AI 已有超过 1 万名付费客户。对读者来说，这意味着运维排障可能从“人工逐条查”变成“AI 先查、人来把关”，但 Scout 1.0 尚未正式开放。

为什么 MCP 服务器应当告诉 Agent 下一步做什么

AWS 的开发者倡导者 James Ward 提出，很多 MCP 服务器目前只是被动地返回数据，就像一个只负责查数据的接口。他建议服务器在返回数据时顺便告诉 Agent 刚做了什么、接下来可以做什么、去哪里找更多信息，相当于让服务器成为对话中的另一个参与者。他还指出 MCP 默认无法追踪调用链路，AWS 的做法是给工具加会话 ID 参数，让多次调用串成完整旅程，再加一个参数记录用户目标，方便团队复现问题、做评测并改进工具。对使用 MCP 的团队来说，这意味着要同时观察人和 Agent 协作的路径，检验工具改动是否真的帮用户完成任务。文中提到 AWS 已于 5 月向所有人开放其 MCP Server，并在 9 月加入 Lambda 诊断功能；这些做法本身并不新奇，重点在于能否持续观测和衡量。

按工作负载需求匹配监控深度：Datadog 推出 Infrastructure Basic

Datadog 推出了一个叫 Infrastructure Basic 的轻量监控档位。原来，对于不太重要的服务器（比如内部后台系统、开发测试机），团队要么用比实际需要更重的监控方案，要么另买一套工具，要么干脆不监控、留下盲区。现在这个档位只采集 CPU、内存、磁盘、网络、开机时长等基础系统指标，还能盯住指定进程是否在跑，并复用现有的告警通知工具。这样，次要服务器也能和重要系统放在同一个 Datadog 环境里统一查看，减少监控空档。目前该功能需要联系 Datadog 销售团队开通，新用户可先试用 14 天。

AI Agent 需要可替换——同时不丢失工作成果

这篇文章讲的是：当负责处理退款的 AI Agent 中途崩溃时，如何让接替它的新 Agent 安全接手，而不会重复退款。原来问题在于，Agent 会自己推理、临时决定，崩溃后新 Agent 可能重新想一套方案，甚至再退一次款，导致用户被退两次钱。作者的做法是：在发起退款前，先把这笔操作的金额、授权、幂等键和状态写进数据库（相当于先立一张可查的“操作底账”），新 Agent 只能继承这张底账，不能自己改写；支付接口前还有一层校验，只放行记录里已授权的操作。这样即使崩溃，也能靠同一个幂等键和操作编号查清到底发生了什么，避免重复退款。对读者的用处是：如果你在生产环境跑 Agent 处理支付、订单等有副作用的操作，可以用“持久操作记录+幂等键+边界校验”的思路提升可靠性。文中提到的 LangGraph、Temporal 能恢复执行，但不能判断外部是否已成功；Langfuse 和 ClickStack 可用于追溯，但都只是辅助证据，最终以支付方记录为准。

演讲：大规模遥测数据治理——自托管可观测性实战指南

Colin Douch 分享了他搭建并扩展自托管可观测性系统的实战经验。过去团队要监控系统，往往得依赖 SaaS 服务，容易被供应商锁定、成本也不好控；他改用 Prometheus、VictoriaMetrics 和 Jaeger 等开源工具，把指标、结构化日志和分布式追踪关联起来，说明这样做在工程上有哪些取舍。对运维和平台团队来说，这提供了一套不依赖外部厂商、可自行掌控的监控方案思路。需要说明的是，材料只提到这是一场演讲，具体可用性和详细做法原文没有展开。

Radar：面向 AI Agent 的开源 Kubernetes 可视化管理与诊断工具

skyhook-io/radar · The missing open-source Kubernetes UI with a built-in MCP server for AI agents. See what's broken, why, and what changed. Issues, Topology, event timeline, Helm, GitOps, live service traffic, and cluster audits - all in one Go binary.

Radar 是一个以单一 Go 二进制形式提供的开源 Kubernetes UI，可在本地或集群内运行，通过直接连接 Kubernetes API 展示拓扑、资源、事件时间线、Helm、GitOps、实时服务流量与集群审计等信息，帮助定位故障现象及其原因与变更。项目内置 MCP 服务器，使 AI Agent 能够检查和操作集群；同时支持 Helm 部署以实现团队共享访问与 RBAC 权限控制。

漏洞风险暴露：在运行时查看受监控进程的暴露情况

Dynatrace 推出了一个叫「漏洞风险暴露」的新仪表板，把漏洞到底影响哪些主机、进程和 Kubernetes 环境集中到一张图里看。原来只看漏洞数量，既不知道哪些进程受影响、漏洞扩散有多广，也看不出是不是所有该扫描的进程都扫了。这个仪表板把暴露情况、受影响对象和扫描覆盖率放在一起，还支持按团队、集群、命名空间筛选，让团队先修影响面最大的漏洞，并发现没被扫描到的盲区。该功能随文章发布，原文未说明具体开放时间或付费情况。

proof-surface：校验 AI Agent 轨迹是否越权的证明包工具

HarperZ9/proof-surface · proof-surface checks an AI agent's trace against the permissions it was granted, and turns traces, evals and measurements into JSON packets with a verdict and report. Python, no dependencies.

proof-surface 是一个 Python 库和命令行工具，用于把 AI Agent 的轨迹（可读取 OpenTelemetry、LangSmith、Langfuse 导出或自有 JSON 格式）与授权清单中的允许动作、目标范围和有效期逐项比对，并把每个动作标记为 MATCH、DRIFT 或 UNVERIFIABLE，同时给出对应决策与可读报告。它还能把测量、评测、研究声明等记录转成带结论的 JSON 包，并针对各领域常见的过度声明做拒绝检查；此外提供证据包、工作记录、授权收据、委派链、预执行门控等基础校验器及多个外部工具导入适配器。

Dynatrace 与 Cursor 打通 AI 原生开发的闭环

Dynatrace 宣布成为“SpaceX 超级智能合作伙伴网络”的启动伙伴，并推出一个已通过验证的官方插件，上架 Cursor 插件市场。原来开发者用 Cursor 这类 AI 编程工具写代码虽然更快，但代码编辑器和线上生产环境是割裂的：线上出故障时，开发者得先切到别的监控门户拼凑线索，才能弄清发生了什么、为什么发生。这次的做法是把 Dynatrace 的生产环境数据（由 Grail、Smartscape 和确定性因果根因分析提供）通过插件接进 Cursor，让 AI 代理和开发者直接在写代码的地方查看线上服务状态、依赖关系和根因。对使用 Cursor 的团队来说，排查线上故障、判断某个漏洞在真实运行环境中是否有影响、分析性能瓶颈，都可以不用离开编辑器，平台团队也能通过 Cursor 的团队市场分发插件并保留管理权限。目前该插件已作为受支持的集成可用，具体配置（平台令牌、MCP 服务器、Dynatrace skills 和 dtctl）需参考配套技术博客。

用 Agent Observability 优化 AI 成本

Datadog 推出 Agent Observability 的新功能，帮企业搞清楚 AI 智能体的钱花在了哪里。原来云厂商账单只按 API 密钥和模型统计，看不出是哪个应用、哪一步工作流在烧钱，所以成本一涨就很难查原因——可能是流量变大、换了更贵的模型，也可能是缓存没用上、对话历史每轮都重发。现在这个工具把估算的 AI 成本直接挂到具体应用和请求链路上，打开 Cost 页面就能按应用对比花费和效率（比如每次请求成本、缓存命中率），还能钻取到单次最贵的调用，看它的执行链路。它还会自动指出可省钱的点，比如未被缓存的提示词前缀，估算能省多少并给出修改建议。对读者来说，这意味着 AI 成本问题能更快定位到技术原因，而不是对着账单猜。目前材料只说明这是 Datadog 的产品能力介绍，未说明具体定价和正式上线时间。

Ramp 六周自建 AI Agent 运行框架，LangChain CEO 称这是更大变革的一部分

金融科技公司 Ramp 花了好几个月试用市面上的托管 Agent API、开源框架和第三方平台，最后决定自己造。他们用六周时间做出了第一版内部 Agent 运行框架 Laminar，现在支撑公司所有 Agent 产品。原因是不想被单一模型供应商绑死，希望按成本、速度和效果自由切换模型，也想要更好的调试和观察能力，内部自建还能直接和产品工程师协作、不用等外部厂商改代码。做法上，它把对话会话和运行代码的沙箱分开，凭据和调度放在沙箱外；Agent 默认异步工作，不必每步都等完成；还用一个连接器服务集中管理认证、权限和工具调用。LangChain CEO 公开点赞其中多项设计，认为这反映了 Agent 基础设施的走向，但原文并未说明 Laminar 是否对外发布或开源。

用 RUM 和合成监控 SLI 构建更好的 SLO

Datadog 的两位作者写了这篇技术文章，讲怎么用真实用户监控（RUM）和合成监控两种数据来定义 SLO 的指标（SLI）。原来很多团队只用后端性能指标，难以反映用户真实体验；而如果单用 RUM，机器人流量和浏览器配置差异会带来噪声，单用合成测试又不够细。文章建议：合成 SLI 适合长期稳定地监测关键用户流程，RUM SLI 适合精确统计真实用户的关键操作，并按目标变化、监控盲区、低流量误报等情况给出了选用建议。文中提到过去一年客户自建合成 SLO 数量增长了 273%。读者可据此判断何时切换数据源，但没有给出具体落地步骤和产品开放状态。

脚本化测试跟不上 AI 写代码的速度，Datadog 押注智能体来测试

很多团队现在直接用 AI 写代码，Anthropic 的工程师产出的代码量达到原来的八倍，有人每月提交数千个 PR。但麻烦在于：代码写得快了，测试仍然要靠人写，得决定测哪些流程、写脚本、流程一变还要改，瓶颈从写代码挪到了测试环节。Datadog 今年收购了 Propolis，把“由智能体写的测试”加进自家平台：智能体自己去探索应用、走用户流程，再根据自然语言的要求生成测试，并结合 Datadog 的日志和链路追踪来检查性能，避免硬编码测试容易失效的问题。对团队来说，这有望缩短开发周期；不过目前只是文章介绍的方案，具体能否用、怎么用还要看 11 月 4 日的线上活动。

serverless-lakehouse：基于 Runpod Serverless 基准数据构建 bronze→silver→gold 湖仓与可视化仪表盘

ashwinsreedhar28/serverless-lakehouse · Medallion lakehouse (bronze → silver → gold) over my own Runpod Serverless LLM benchmark data: cold starts, FlashBoot, worker-vllm boot anatomy, cost per job. Local PySpark + Delta Lake, redacted landing zone, idempotent ingest, four external audits.

该项目以作者自有的 Runpod Serverless LLM 基准数据为来源，用本地 PySpark 与 Delta Lake 搭建 bronze→silver→gold 的 medallion 湖仓：先着陆并脱敏原始文件，再逐层构建可重建的 Delta 表，最终生成按 GPU 与镜像统计的冷启动分布、FlashBoot 命中率、单任务成本以及 emberserve 与 worker-vllm 的对比等 gold 聚合结果，并通过静态 HTML 页和 Streamlit 应用查看。另附 dbt/Snowflake 后端与审计脚本，材料未说明 GPU、API 成本等部署条件。

本体驱动的可观测性：在 Netflix 规模下构建端到端知识图谱

Netflix 的工程师写文章介绍了他们怎么解决一个很头疼的问题：系统出故障时，找原因要找将近四个小时。原来监控工具收集了很多数据（指标、日志这些），但每个系统各说各话，同一个东西在不同工具里叫不同名字，得靠人脑记着怎么对应。他们的做法是建一个知识图谱，把应用、事件、部署这些概念和关系用统一格式写清楚，机器也能读。这样本来要翻三个工具才能回答的问题，现在一条查询就能搞定。文章还提到他们自研了一个叫 QuipuDB 的图数据库来存这些数据。不过文章只给了开头部分，具体效果数据、完整方案细节没有说明。

Dynatrace 发布雷达 09.26

Dynatrace 在9月发布了一批更新。以前，看数据库语句只能知道它执行了什么，却不知道是谁触发的；排查问题还得在不同页面之间来回切换，容易丢失分析上下文。这次新增了“服务回溯”功能，能从数据库查询直接看到上游调用链、负载分布和报错情况；分布式追踪可以在侧边浮层看瀑布图，原来的图表和筛选保持不变。QuickStart 把自动配置和手动安装放在一起，还能从问题直接打开 AI 助手 Dynatrace Assist，并用 dtwiz 自动配置 OpenTelemetry 主机监控。支持的主机现在也能和 OneAgent 监控的主机一起出现在基础设施与运营的 Compute 菜单中。这些功能已发布，具体入口和版本要求原文未详细说明。

Devin Oncall 与 Dynatrace：为自主事件响应引入运行时智能

Cognition 推出的自主软件工程师 Devin 现在可以把能力延伸到线上事故处理上（即 Devin Oncall），它不再只是写代码，而是能调查生产问题、修改代码并提交合并请求。但 AI 代理要排查事故，不能只看源码，还得知道线上哪里出问题、改了什么、修复是否有效；过去它要自己到多个数据源里翻日志和指标，费时又容易出错。这次 Dynatrace 作为 Devin Oncall 的发布合作伙伴，把生产环境的运行时信息（问题、根因、日志、指标、链路、部署事件和安全发现）通过 MCP 服务器和技能插件接给 Devin，让它在同一个工作流里就能定位并验证修复。对使用 Devin 的团队来说，这意味着从收到告警到排查、修复、验证有可能在一个会话里完成，但目前仍需配置 Dynatrace 平台令牌和相应权限，实际可用范围取决于集成配置。

心理健康风险评估系统（DWS）：面向高校的多模态心理健康筛查与预警平台

kajykk/bysj · 🧠 毕业设计：面向高校的心理健康风险评估系统 (DWS) — 多模态 ML 融合（问卷 + 文本 BERT + 生理信号）· FastAPI + Vue 3 全栈 · 金丝雀发布 / 漂移检测 · Prometheus 全链路可观测

该项目是一个面向高校场景的心理健康筛查与预警平台，融合结构化问卷、文本分析与生理信号进行多模态风险评估。后端采用 FastAPI，前端采用 Vue 3 + TypeScript，包含用户、咨询师、管理员三角色工作台，并覆盖异步任务调度、实时告警、模型治理（漂移检测、金丝雀发布、回滚）、可观测性（Prometheus、Grafana、Sentry、OpenTelemetry）以及 PII 加密、审计、限流等安全合规能力。项目定位为“AI + 全栈 + DevOps + 可观测性”的个人作品集级完整系统示例。

你的 Kubernetes 仪表盘一片绿，用户却在叫苦连天

企业运维中常见一种“幽灵变慢”：Kubernetes 和 Grafana 仪表盘全绿，Pod 正常运行、探针返回成功、CPU 也没打满，但用户却抱怨应用查询或 AI 模型响应时快时慢。原因是探针只回答“容器要不要重启、能不能接流量”，并不衡量一次完整用户请求是否按时完成。HPE OpsRamp 产品负责人 Mahesh Ramachandran 建议持续采集跨层遥测数据并保留历史记录，因为间歇性变慢过去后，没有历史证据几乎无法定位；再结合异常检测和相关性分析找出可疑因素，但相关不等于证因，改动后需对比同一用户侧指标验证。对读者的用处是：看板变绿不等于用户体验变好，应补上应用性能测量和历史数据。该系统需要团队自行配置探针与集成，文中未说明具体可用的 AI 排查功能或发布时间。