克劳德代码监测:捕获许可等待和遗漏结果

监控需要三个层,而不是一个仪表板. 使用Claude Code官方的OpenTelemetry源供消费和活动,预期和终端故障的生命周期,以及您实际要求的结果的项目检查. 如果您省略第三层,会话可能会有清洁的痕迹,成功的工具调用,并且在预期的补丁,测试结果或文件仍然缺失时, 合理的默认量是故意小的:出口编辑的指标和事件,记录六个生命周期事件,没有它们的自由文本有效载荷,然后根据特定任务完成预测评估最后的事件. 不要收集提示或原始工具内容,仅仅是为了决定跑步是否需要注意. 这本指南从当前的克劳德法规方案中构建了这一设计, 它不认为工具调用是进步,暂停是失败,或者 Stop 意味着工作完成. 首先要问三个问题. 每个信号都回答一个问题, 并且禁止回答其他两个问题时, 监测变得更加清晰. 层 问题可以回答 信号 它不能证明的 远程测量 克劳德·科德 (Claude Code) 消耗或执行了什么? 会议,API请求,代币,估计成本,工具结果,工具决策,持续时间 要求结果是否正确 生命周期 为什么这次会议是安静的或结束的? 许可请求,通知,背景任务,预期的唤醒,停止,API结束时的转换,会议结束 文件,测试或外部结果是否有效 结果 这项任务是否取得了承诺的结果? 文件哈希,测试退出状态,方案验证,API响应,签署的文物 为什么会话等待或成本 通过OTel计量协议,通过日志/事件的事件,以及可选的分布式痕迹,官方的克劳德法规监测文件暴露了指标. 记录的指标包括会议数量,改变的行列,承诺,拉动请求,活动时间,代币和估计成本. 事件增加了快速相关性,API结果,工具结果和许可决定. 这对于第一层来说是很好的证据. 这不是完成合同. 在普通工作中,区别是重要的. 一个成功的 Write 工具事件表示写作完成. 它并没有说预期的文件是写在正确的位置, 代币和成本曲线可以显示出流失的消费,但低成本的会议仍然可以在可交付的前一步停止. 使用克劳德代码子添加生命周期证据 Claude Codes 子参考提供了第二层,仅供使用的仪表板缺失. 四个事件特别有用: 在即将显示权限对话框时, PermissionRequest 启动. 如果是最新未解决的事件,会话正在等待一个人;它没有停滞. 当主要代理完成响应时, Stop 会发射. 现在的输入可能包括 background tasks 和 session crons ,因此停止转换可能仍然在等待一个任务,子弹,监控任务,工作流程,MCP任务或计划的唤醒. 当API错误结束转折时, StopFailure 取代 Stop . 它的记录错误类别包括利率限制,过载,身份验证,发票,无效请求,缺失模型,服务器错误和最大输出代币. SessionEnd 记录了会议结束的原因. 它对于清理和审计是有用的,但不能阻止终止. PostToolUse , PostToolUseFailure , Notification 并且 PreCompact 添加有用的文本. 保持它们的语义狭窄:最近的 PostToolUse 是活动的证据;重复的 PostToolUseFailure 是工具问题的证据; PreCompact 标志着值得与后来的行为相关的文本转变. 没有一个是普遍的健康判决. 对于一个隐私最小的收集器,只保留一个时间,一个本地哈希的会话标识符,事件名称,工具名称,错误类别,通知类型以及背景任务或计划的唤醒数量. 除了确诊的使用情况证明这些情况合理,将 transcript path , cwd , last assistant message ,Bash命令,工具输入和通知文本省份. 官方Otel默认支持相同的限制. 默认禁用即时文本,助理响应文本,工具参数,工具输入/输出内容和原始API体. 启用 OTEL LOG RAW API BODIES 可以揭示整个对话历史记录;它永远不应该是偶然的故障解决开关. 将最新的证据变成一个状态 下面的决定命令足够小,可以检查. 它对每次会议进行了最后一次分类,而在轮停止时,外部验证器提供了 outcome verified . 命令是故意的. 终端API故障超过最近的活动事件. 没有解决的批准正在等待,而不是暂停时间. 后台工作阻止 Stop 事件被视为完成. 只有排除这些案例后,验证人才决定 complete 和 outcome missing 之间. 保持的测试装置使用7次会议和15分钟的示例门: 按固定时间标记运行装置,将所有7行复制: 这是一个决策规则,而不是生产妖怪. 这一15分钟的门对2分钟的皮工作而言是错误的, 设定工作的预期率和持续时间的新鲜性,然后保持 uncertain 路径,以查找缺失或矛盾的证据. 在谈话之外,定义完成 唯一针对应用程序的分类器输入是 outcome verified . 这一点应该来自一个确定性检查,尽可能,而不是搜索最后的助理消息. 对于代码更改任务,有用的完成可能需要所有这些: 1. 预期的文件与起始承诺不同; 2. 专注测试指挥成功退出; 3. 产生的文物解码或包装可进口; 4. 结果仍然存在于批准的存储库和范围内. 为了完成文件任务,需要目的地文件,前置物或方案验证,所有引用的本地路径,以及存储库已经信任的任何链接检查器. 对于数据出口,请检查预期文件,分析它,验证所需列,并与源边界进行行数量的比较. 对于API更改,运行合同测试,而不是接受仅仅返回的HTTP请求. 监视器应存储验证器的名称,退出状态,观察时间以及结果的摘要,而不是一个捏造的解释. 当没有确定性预言存在时,记录 outcome unknown . 一个未知的结果可能需要审查;它不应该默默地变得健康. 警报下一步安全行动 七个州不需要七个警报声音. 调整每个状态到最小有用的操作: 国家 默认行动 working 别做什么 waiting human 无需批准许可类别,通知负责人 waiting background 显示依赖性和新鲜性;不要重新启动会议 failed: 暴露错误类别和限度重试政策 outcome missing 显示失败完成预示和保存工作进行检查 stalled 在提出一个有限的推力之前,重新检查可达性和预期持续时间 complete 保留证据并关闭问题 这种路由可以防止两个昂贵的错误. 首先,它避免再次试验正确等待权威的代理人. 第二,它避免庆祝谈话停止, 当项目证据说结果没有. 自动恢复需要比监控更严格的界限. 速度限制故障可能在备份后可重复;身份验证故障通常需要一个人;仅仅因为它是旧的,所以不得自动批准许可提示. 在任何干预后,再运行完成预测. 一个成功的命令是活动的证据,而不是原始任务恢复的证据. 没有过度收集的设计应用于 实际部署可以保持逐步: 1. 启用与指标和事件的Claude Code远程测量,将所有内容记录开关. 2. 确认 claude code.session.count 或 claude code.user prompt 在构建警报之前到达收藏器. 3. 加入 PermissionRequest , Stop , StopFailure , Notification , PreCompact 和 SessionEnd 的本地. 4. 在最小的包裹中将这些杆有效载荷正常化;本地进行哈希识别器,放弃路径和自由文本. 5. 定义一个后果任务的确定性完成预示. 6. 在通知任何人之前,再播放每个州的合成事件. 7. 只有当其所有者和安全下一步行动明确时添加警报. 版本的正常化器. 克劳德代码为多个字段记录了最低版本, 优先使用当前文档所暴露的和OTel字段;不要通过剪切终端像素或假设私有转录形状永远不会改变来构建长寿命的显示器. 对于Sidewisp的有用边界 克劳德代码已经提供了强烈的原始信号. 运营缺口将这些信号转化为一个受制的健康决定:工作,等待,失败,过时,或错过承诺的结果然后显示证据和最安全的下一步. Sidewisp 目前处于私密预览阶段。 它的公共网站和文章系统是现场的,但生产的克劳德代码监控适配器,代理健康收集和恢复通常不出货. 预期的角色是与现有运行时间相结合的健康层,而不是替代运行时间,强制模型门户或自主固定器. 如果这个界限与你运行编码代理的方式相匹配, 在此之前,本指南中的三层模式可以单独使用:活动的远程测量,生命周期的子和结果的确定性检查.