AI 基础设施平台的难题不止是提供 GPU。用户看到的是一次函数执行，平台内部却要协调调度、容器、网络与多家云的硬件；同一种失败表象可能来自客户代码，也可能来自底层供应商。Modal 的案例值得读，是因为它把可观测性放在这些责任边界之间：先建立跨层上下文，再让工程师和调查 Agent 使用同一套生产证据。文中的可靠性数字是客户案例的自报结果，机制细节比把百分比当成通用收益更有参考价值。

来源：Datadog / Modal · 首发 2026-10-09
原文：Modal scales the next generation of AI with unified observability from Datadog。受访者为 Modal CTO 与联合创始人 Akshat Bubna。

问题来自跨层归因，而非单一监控面板

案例描述 Modal 运行于 20 多家云提供商，每天启动约 2,600 万个容器。供应商之间的网络行为、硬件与失败模式不同，负载又不断变化。一个请求变慢时，仅知道某台机器 CPU 升高，未必能判断是客户程序、平台调度还是云端网络出了问题。真正的操作任务是缩小故障范围，并把下一步行动交给正确的责任方。

原文没有公布调度器算法、故障检测模型或自动修复架构，因而不能把案例写成新算法报告。它展示的是统一调查面的组织方式：基础设施、网络、Kubernetes、应用和云服务信号在一个平台中关联；新服务在开发时就加入监测，避免故障发生后才补采关键数据。这个做法的工程含义是，可观测性覆盖要随服务演化，而不是只随机器数量增长。

从“有很多数据”走向“能串起一次执行”

Modal 使用的能力包括 Infrastructure Monitoring、APM、Network Monitoring、CI Visibility，以及日志、指标和 traces。它们回答不同问题：指标给出何时偏离常态，日志提供事件细节，trace 连接请求经过的组件，网络信号帮助检查跨主机或跨云路径。原文声称统一平台减少了在多个工具间切换的成本，但没有提供关联算法或标签规范。

从工程角度推导，统一界面要产生价值，前提是这些信号可以指向同一服务、同一执行和相近时间窗口。否则，把若干面板放在一起仍只是并排观察。特别是短生命周期容器，实例标识和调用上下文必须在实例消失后仍能帮助关联历史。这里说的是理解案例所需的设计条件，不是宣称 Modal 已公开采用某一种具体 schema。

这也说明应把“收集量”和“可调查性”分开看。更大的数据量可以扩大证据覆盖，也可能带来高基数、噪声和查询成本；某个关键服务缺少上下文关联，即使其他服务产生大量日志，也不能弥补那条调查链的缺口。

Agent 通过 MCP 接触证据，工程师完成判断

案例最有时效性的变化是 Datadog MCP Server。Modal 让 AI Agent 访问生产遥测，关联日志、traces、基础设施指标和网络信号，向工程师提出可能的根因。这样，Agent 的帮助建立在生产上下文上，而不只是对告警标题生成解释。

原文描述的是辅助调查，没有证明 Agent 能独立闭环修复，也没有公布调查正确率、工具调用成功率或权限配置。一个符合证据的理解是：Agent 减少人工搜集与整理信息的工作，工程师利用它提供的上下文继续确认原因。若把“最可能的根因”误写成已验证因果，就跳过了对照时间线、检查影响范围和验证干预结果这些关键步骤。

对于 AgentOps，这个接口还提示了衡量方式的变化。单次回答是否流畅远不如是否找到相关遥测、是否区分相关性与因果、是否给出可以追查的证据重要。这是由案例引出的评价视角，原文并未报告这些维度的实验结果。

两个可靠性百分比，回答的是不同问题

案例自报 99% 的事故在五分钟内发现，约 96% 的问题在影响客户前解决。前者刻画检测时间窗口，后者刻画问题解决与客户影响的先后关系，两者分母未被证明相同。它们不能相乘得到整体成功率，也不能直接推导平均修复时间、全年可用性，或所有问题都会被提前发现。

尤其需要保留的是，页面没有给出这两个比例的观察周期、样本量、事故严重等级分布或对照期。这限制了对产品因果收益的判断：团队流程、工作负载变化与服务成熟度也可能参与结果。对读者而言，可靠的结论是客户报告了较高的早期检测与影响前处置比例；更强的产品比较需要额外数据。

摄取与索引分层，成本控制也要有口径

原文报告每月约 1,160 亿日志事件、近 246 TB 日志数据，覆盖 66 个生产服务和约 1,300 台主机，并跟踪约 2,700 个指标名称。指标名称数不是时间序列基数：不同标签组合可能把一个名称扩成很多序列，因此不能用 2,700 判断全部监测规模。

APM 数据存在需要分开的两个口径。一段称每月收集约 970 亿 spans；后文谈成本时称每月摄取约 1,200 亿、仅索引约 23 亿。页面没有解释二者的时间或范围差异，不能将它们混写为同一总量。只在后一个口径内计算，索引比例约为 1.9%。这一算术比例帮助理解摄取与索引分层，但不是采样准确率，也不能据此推断其余数据的保留时长、可检索性或丢失率。

这种取舍让成本问题更具体：哪些证据需要快速查询，哪些只需保留有限摘要或其他访问形式，要与排障需求一起决定。案例没有披露存储层级、保留策略和完整成本曲线，因此无法计算每次事故调查的费用，更不能承诺按同一索引比例就能取得相同可靠性。

原页提供的是展示性界面图，没有完整技术架构图，本篇不把它当作数据流设计。阅读时可先看跨层责任划分，再看 MCP 调查与摄取／索引的区别。最可迁移的经验是让新服务及时产生可关联证据，并让人和 Agent 在同一上下文中调查；可靠性改善仍要用各自系统的检测、处置与客户影响记录来解释。

因此，这个案例适合用来审视证据链是否完整，而不适合据此选定一个固定采样比例。先辨别问题是否被发现，再追问诊断是否成立、处置是否及时，三个阶段需要各自的记录与统计分母。