日志与可观察性：看见失败又不泄露数据

用户说没成功，系统要能定位

星桥手作社的页面提示材料草案生成失败。可能是人数不合法、库存服务没返回、模拟模型格式错误或保存冲突。没有日志时只能猜原因。日志是记录系统发生了什么的事件，可观察性则是利用日志、指标等信息理解运行状态。学习者不用一开始搭建复杂平台，先为每次请求记录唯一标识、阶段、状态和耗时，就能把一条请求从输入到展示串起来，避免把所有失败都怪到模型。

记录必要信息，不复制一切

一条日志可以写请求编号练习九、阶段为结构校验、结果为缺字段、耗时为模拟两单位、资料版本为第二版。不要默认保存完整问题、全部模型输出、密钥或账户凭证，因为日志本身也需要权限和保留期限。错误诊断往往只需要字段名、错误类别和脱敏摘要，不需要正文。虚构学习数据也要养成最少记录习惯，实际应用更应区分普通运行日志与受限的审查样本，后者须有明确目的和访问控制。

一个逐阶段排查示例

请求练习九依次记录身份检查通过、输入检查通过、库存读取成功、确定计算成功、模拟生成成功、结构校验失败，原因是缺少说明字段。这样可以判断网络交换或模拟生成完成并不代表业务草案成功，故障发生在输出契约。用户界面应显示生成结果不符合格式，确定计算仍是需求二十、缺两张，暂未保存草案。日志与界面各有用途，用户不必看到内部细节，维护者则能依据请求编号找到相关阶段。

运行正常不等于答案正确

监控指标可以包括失败比例、响应时间、工具次数、重试次数和预算消耗。系统没有异常、每次都很快，只能说明运行表现，不能证明材料数字或引用正确。答案质量需要测试集和人工核验。反过来，答案正确但耗时很长或重复写入，也说明工程仍有问题。设计告警时可以对连续校验失败、权限拒绝异常增多或预算快速消耗设置阈值，但不要因为一次正常拒答就把整个服务判为故障。

从日志走向恢复动作

日志要能支持具体处理，例如停用有问题的资料版本、回退输出模板、限制异常重试或交给人工确认。记录恢复动作和结果，避免只堆数字却没人负责。保存失败后不要让界面宣称已保存，可以让用户查看未保存草案并重试安全的保存步骤。对同一请求使用统一编号，跨阶段就能关联，但编号本身不授予读取全部数据的权限。好的可观察性既帮助理解系统，也尊重数据边界，不把为了调试当成无限收集的理由。