凤凰大型语言模型可观察性：证明痕迹在重启后依然存在

凤凰可以在自身证据层仍然脆弱时展示完整痕迹。一个可访问的页面证明了网络流程现在就给出了答案。确实如此 不是 证明旧的痕迹在重启后依然存在，收集者恢复了采集，或有效的保留政策涵盖了你的团队调查事件期间。 合理的默认做法是进行两次金丝雀重启练习： 1. 查询一个重启前创建的无内容痕迹; 2. 在不更改应用代码的情况下重启凤凰服务; 3. 再次查询同一条线路; 4. 重启后发送并查询第二次跟踪; 5. 比较观察年龄和有效保留率与明确限制。 老金丝雀测试的是持久性。新的金丝雀检测恢复了摄入。你两者都需要。如果只有旧的痕迹存在，存储可能没问题，而收集被破坏。如果只有新的追踪存在，服务器返回时存储为空或意外。 把凤凰案当作三层证据 凤凰的架构文档将系统分为网页界面、跟踪收集器和SQL数据库后端。这种区分在诊断时很重要： 接口可以在OTLP吞入失败时接应; 收集器可以接受连接，而跟踪永远不会变得可查询; 当容器指向新的 SQLite 工作目录时，数据库可以被访问; 这三者都可以同时上线，而保留工作会比事件流程预期更早移除证据。 Phoenix 支持 SQLite 和 PostgreSQL。其当前文档将SQLite定位为本地开发和单用户部署，数据如下 ~/.phoenix/ 或 PHOENIX WORKING DIR .PostgreSQL 是多用户和高可用性部署的文档化生产选择。这并不是说SQLite总是不健康的规则。单个开发者可以运行一个可靠的本地实例，并安装一个已挂载的卷。失败在于让坚持性隐含其中。 该官方 Docker 指南直接显示两个合同： 对于PostgreSQL，Phoenix读取 PHOENIX SQL DATABASE URL ;本指南文件支持PostgreSQL 14及更新版本。把连接数值保存在你的秘密系统里，而不是健康收据里。收据只需后端类、不透明的部署标识符和金丝雀查询的结果。 固定图片是另一个控制项。 latest 这可能方便于一次性本地试验，但同时使重启能够同时更改应用程序及其数据库期望。在演练前录制一段不可篡改的图像摘要或显性版本。在未知图像下成功重启并不构成可重复的证据。 建立一个无内容的重启收据 选择一条金丝雀路径，使其与你关心的代理流量使用相同的收集器和项目路由。不要在金丝雀中放入真实的提示词、模型响应、工具参数、凭证或客户标识。随机的运行标签和时间戳就足够了。 Phoenix 文档化的 REST 端点可以项目列表痕迹设有启动时间界限和可选跨度。使用你部署的认证方法，但不要将授权值留在shell历史和保存输出中。 例如，设置非秘密路由值并请求一个狭窄的时间窗口： 在本地搜索金丝雀不透明回复 trace id ;不要将响应体导出为通用遥测。如果你请求 include spans=true 响应大小和查询延迟增加，因此Phoenix API参考建议懒惰地获取范围细节。重启演练需要的是追踪身份和时间，而不是提示内容。 最低收据可以是这样的： effectiveRetentionDays 指的是附加在实际项目上的策略，而不仅仅是部署默认的策略。凤凰默认情况下可以无限期保留数据，在默认策略中表示为零天数。管理员可以为单个项目分配基于时间或追踪计数的策略。部署时默认设置可以更新新项目，而无需更改现有的项目特定覆盖。这就是为什么配置意图和有效项目状态是不同的证据。 将留任率与您的运营流程进行比较。如果事件能静置14天，即使所有当前痕迹都存在，七天的痕迹窗口也会被削弱。三十天本身也不健康;它仅相对于审查窗口、存储预算和数据治理决策而言是健康的。 在不隐藏中断的情况下进行演练 使用运行时的正常重启操作。不要将第一次演练与Phoenix升级、存储迁移、收集器重配置或应用发布结合使用。关键是要隔离持续性和恢复摄入。 重启前的马上： 1. 录制置顶版本或图片摘要; 2. 确认预期的数据库后端及持久卷或数据库身份; 3. 记录有效的项目保留政策; 4. 通过正常仪器路径发射第一只金丝雀; 5. 查询后只存储布尔结果、追踪ID和时间戳。 重启后： 1. 等待服务记录的准备状态，而不是使用任意的睡眠; 2. 查询相同的重启前轨迹; 3. 发射不同的重启后金丝雀; 4. 通过同一项目路径查询新踪迹; 5. 在收据上盖章，并在新鲜度过期前评估。 本文配套赛程采用五分钟观测限制，并重播九个状态： 结果为 9/9 cases pass .两种配置被归类为健康配置：用于多用户部署的置顶PostgreSQL，以及用于一个用户的固定SQLite和持久卷。其余的固定装置则有意产生 evidence lost , ingestion failed , waiting , needs human , uncertain ，或者 degraded . 判决的先例很重要： 证据 结论 操作员决策 迁移按计划进行 waiting 观察有界维护操作;不要称之为代理故障 迁徙失败 needs human 停止自动恢复并检查数据库/版本边界 观测时间早于新鲜度限制 uncertain 在行动前重新运行查询 政策内的旧痕迹消失了 evidence lost 先保留当前存储，并先诊断挂载/数据库身份 旧的痕迹依然存在，但新的痕迹缺失 ingestion failed 检查收集器可达性、导出路径、认证和项目路由 两种痕迹都存在，但保留时间太短 degraded 将有效的项目政策与事件审查对齐 两种痕迹都存在，证据新鲜，控制组也匹配 healthy 证据层通过了这个有界钻孔 这种排序防止配置警告掩盖实际数据丢失。未置顶的图像很重要，但缺少策略内的追踪是第一个事件。 将迁移置于盲恢复之外 Phoenix 文档说明，新主要版本在启动时可能会运行数据库迁移。它还警告了，回滚应用镜像会有问题 不是 自动降级数据库模式。这使得“重启旧容器”在重大升级失败后成为不安全的通用恢复规则。 对于Kubernetes，迁徙指南建议在 initContainer 所以它们在主容器进行活性性检查之前就完成了。它还解释了 PostgreSQL 索引创建可以阻止写入。 PHOENIX MIGRATE INDEX CONCURRENTLY=true 这样可以避免保留写入锁，但有文献记载的权衡是迁移速度大约是两到三倍，而且新舱仍然需要等待完成。 将这些机制转化为状态： 在批准维护窗口内运行的迁移为 waiting ; 迁移状态未知时进行的查询为 uncertain ; 失败迁移可能推进了模式 needs human ; 只有当数据库兼容性计划明确支持自动回滚时才被允许。 这与其他可靠的代理操作需要的区别相同：活动不是进展，等待不是停滞，命令完成不是预期结果。 知道这张收据不能证明什么 通过的重启收据保护一条证据路径。它不能证明每个模型路线都配备了仪器，每个跨度语义正确，备份可以恢复，代理能交付预期结果。它也不验证LLM评估的内容。这些是分开的测试。 收据故意没有内容。这减少了暴露，但也意味着语义错误需要有限的评估或人工审核。将不可得证据视为不可得;不要用健康的猜测来填充。 Sidewisp的目标健康模型关注证据的新鲜度、可获取性、有益进展、结果和安全的恢复边界。这里的操作模式符合这一领域，但这并不是声称实现了运输整合。Sidewisp目前不连接Phoenix，也未监控此次部署。 Sidewisp 目前处于私密预览阶段。 如果你要为代理人堆栈定义第一份健康合同，请将这份复职回执放在代理人的结果收据旁边。其中一个是告诉你诊断证据是否保存下来的。另一个则告诉你这项工作是否成功。