Cloudflare Observability MCP：证明零对数结果

来自 的空响应Cloudflare可观察性MCP服务器并不能证明 Worker 是健康的。有证据表明一个查询没有返回任何行。在将其转化为结论之前，请证明查询使用了预期的结果Cloudflare帐户、工作人员、时间窗口、日志配置和字段集，并且同一范围可以检索已知的控制调用。 合理的默认值是严格的：调用过滤后的零行结果 healthy empty 仅当启用Workers Logs和Incalling Logs时，头部采样率为 1 ，窗口位于保留内部，字段发现成功，查询完成，更广泛的查询在同一帐户、Worker 和窗口中找到已知调用。如果缺少任何收据，请保持状态未知或路由特定配置失败。 这很重要，因为远程MCP在证据层不完整的情况下，交换也能成功。协议结果回答“工具返回了吗？”操作员仍然必须回答“此查询是否涵盖了此决策所需的事件？” 一个成功的MCP查询仍然可能是证据失败 Cloudflare列出了用于调试应用程序日志和分析的托管可观察性服务器。目前的Cloudflare MCP 服务器目录提供其远程端点，表示新连接使用 Streamable HTTP，并解释授权是通过CloudflareOAuth。这Workers 可观测性 MCP 存储库文档三个工具： query worker observability 查询工作人员日志和指标； observability keys 发现元数据、特定于 Worker 的字段和自定义字段； observability values 查找选定字段的可用值。 这些工具足以调查许多事件，但它们的成功范围并不能证明覆盖范围。该存储库还表示每个请求都会获得新鲜的、请求范围内的授权和帐户上下文。因此，不要假设因为上一个请求使用了正确的帐户，所以下一个请求也一定会这样做。在每个查询收据中记录非秘密帐户参考和工作人员参考。 有几种方法可以获得令人信服的空结果： 1. OAuth 已完成，但所选帐户不是生产帐户。 2. Worker 名称或环境过滤器解析为空。 3. 该部署禁用了工作人员日志。 4. 调用日志被明确禁用。 5. 头部采样忽略了您期望找到的调用。 6. 请求的窗口比保留的数据旧。 7. 过滤器使用当前架构中不存在的字段或值。 8. 过滤后的结果确实是空的。 只有最后一个状态支持“无匹配事件”，即使如此，也仅适用于有界范围和窗口。将列表折叠成 success 丢弃操作员需要的确切证据。 在解释过滤器之前证明数据集 从收集开始，而不是从事件查询开始。Cloudflare的电流工人日志文档表示工作人员必须启用可观察性才能写入工作人员日志。它还记录了一个单独的 invocation logs = false 环境。因此，当您的审计期望的调用证据故意缺失时，Worker 可以成功运行。 采样是另一个硬边界。 head sampling rate 范围从 0 到 1 ;在 0.01 ，仅记录一百个请求中的一个。对采样数据进行零行错误查询可能对趋势估计有用，但它无法确定性地清除一个已知请求。该文档指出，该服务可以在帐户超出其每日日志限制后应用 1% 的样本。记录有效的采样策略，而不仅仅是预期的配置。 保留使旧窗口变得不可知。记录的最长期限为免费工人三天和付费工人七天。如果事件窗口在保留边界之前结束，则对其进行分类 window expired 。扩展或重写查询无法恢复不再存储的数据。 每次调查均使用此顺序： 1. Pin 范围。 捕获授权帐户、工作人员和环境的不透明、非秘密引用。不要在健康收据中存储 OAuth 令牌、请求 URL、日志正文或客户标识符。 2. 检查收集。 确认已为部署环境启用工作日志以及是否启用调用日志。 3. 记录覆盖范围限制。 捕获有效头采样率、保留天数和请求的开始/结束时间戳。 4. 过滤前发现。 使用 observability keys 确认必填字段存在，然后 observability values 确认 Worker 或环境值存在。这可以防止拼写错误或过时的字段看起来像是干净的结果。 5. 运行控制查询。 足够广泛的查询以查找在同一帐户、Worker 和窗口内发出的一个已知调用。如果需要关联，请使用本地保存的散列请求标记；切勿将原始标记上传到监控记录。 6. 运行事件过滤器。 仅在控件出现后，零行错误过滤器才应被视为候选过滤器 healthy empty . 紧凑的收据可以保留决策而不保留日志内容： 帐户和工作人员引用是相关键，而不是带有秘密的标识符。收据故意排除提示、日志消息、标头、请求 URL、工具参数和 OAuth 材料。 路由九个状态而不是渲染一个绿色结果 本文附带的可检查工件重播了九个无内容的案例。它的优先规则是故意保守的： 状态 证据 操作员动作 needs auth 远程服务器未授权 路由至帐户所有者；不要将 Worker 标记为无法访问 scope unresolved 缺少帐户或工作人员参考 解析准确的帐户、部署和环境 collection disabled 工作日志或调用日志已关闭 决定是否启用收集和重新部署 window expired 该窗口早于保留的数据 标记历史判决不可用 query failed 架构发现、时间戳或查询执行无效 在解释行计数之前修复查询 sampled unknown 零行，下面有头部采样 1 将缺勤视为不确定性 coverage unknown 零行且缺少已知的控件调用 调查范围、过滤器、摄取或收集延迟 incident found 过滤后的查询返回一个或多个匹配行 调查退回的证据 healthy empty 零过滤行加上完整覆盖和找到的控件 仅清除此过滤器、范围和时间窗口 分类器在查看之前检查先决条件 filteredRows 。该顺序可以防止最常见的假绿色：看到零并在询问是否有任何有效数据集可供搜索之前停止。 在本地运行夹具： 九个装置在每个州产生一个案例，并且所有三项测试都通过了： 可证伪的部分很简单。取出健康的空夹具并移除控制收据：其状态变为 coverage unknown 。较低的采样 1 到 0.1 : 就变成了 sampled unknown 。添加三个过滤行：它变成 incident found 。仅在建立证据路径后，行计数才有意义。 经过验证的空日志窗口仍然不是代理结果 healthy empty 是故意狭窄的。意思是选中的Cloudflare工作日志过滤器在覆盖的窗口中没有返回匹配的行。这并不意味着工作线程产生了正确的响应、提交了一次下游写入、计划作业交付了其工件，或者用户更广泛的代理任务成功了。 Cloudflare的工人可观察性概述分离日志、跟踪、指标、分析和导出的遥测数据。每个表面都回答不同的问题。干净的错误过滤器可以与错误的业务结果共存。成功的调用日志可以与丢失的目标记录共存。已知的控制请求可以证明查询覆盖率，而无需提及不相关的队列使用者。 当事件涉及用户可见的影响时，在日志查询之外添加结果收据：文件哈希、数据库版本、公共响应、队列确认或其他确定性目标检查。如果效果可能已发生但收据不存在，则不要在副作用边界处自动重试。先和好。 还有隐私限制。控制探针应该是合成的、有界的，并且易于识别，而无需在日志中放置秘密。健康收据应保留哈希值和状态，而不是请求主体。Cloudflare超大日志可以被截断的文档；目前的争论并不能证明所有预期的领域都得以幸存。检查 $cloudflare.truncated 当诊断取决于日志内容时的边界。 这Cloudflare可观察性MCP服务器被记录为正在进行的工作，因此工具名称和行为可能会更改。重新运行现场发现，在事件报告中固定证据日期，并将过时的工具假设视为查询失败而不是健康的结果。 Sidewisp 目前处于私密预览阶段。其生产监控适配器和恢复系统通常不发货。这里的方法是本地操作模式，而不是声称Sidewisp目前连接到Cloudflare帐户、查询实时 Workers 或修复事件。 有用的规则更小：永远不要将“零行”提升为“健康”，直到已知事件证明确切的数据集、范围、窗口和收集策略能够返回证据。这变成了MCP对可审计决策的响应，而不假装仅通过日志证明结果。