日志、监控与成本边界
先定义什么时候算坏了，再决定收集哪些数据
生产可观测性的目标不是“日志越多越好”，而是快速回答：哪些用户受影响、从什么时候开始、哪个版本或依赖变化导致、现在应该降级还是回滚。
| 信号 | 小型应用至少记录什么 |
|---|---|
请求 | 请求 ID、路由、状态码、耗时、版本，不记录完整敏感正文 |
指标 | 请求量、错误率、延迟、实例与连接池饱和度 |
依赖 | 数据库、对象存储、队列和模型 API 的耗时、错误与限流 |
任务 | 进入、开始、完成、失败、重试和死信数量 |
发布 | 制品版本、配置版本、迁移版本、执行人和时间 |
模型请求还应记录供应商、模型版本或名称、令牌或计费量、超时和降级结果。提示词与知识库正文默认不进入普通日志；确需采样时先完成数据分类、脱敏、权限和保存期限评审。
推荐从四类用户可感知信号开始：可用性、延迟、错误率和饱和度。每条告警写清服务、阈值、持续时间、可能原因、运行手册和负责人。
避免为每条单次错误通知所有人。把短暂波动聚合为窗口，把真正的支付失败、登录不可用、队列堆积和模型费用异常设为明确升级事件，并定期测试通知链路。
- 云账号设置月度预算和多级告警，关键资源再设置实例数、并发和容量上限。
- 模型 API 按用户、租户、模型和时间窗口限速，限制单请求输入与输出规模。
- 对象存储同时观察容量、请求次数、跨区域流量、外网流出和生命周期费用。
- 数据库观察规格、存储增长、备份保留、连接数和只读副本。
- 队列和重试设置最大次数，永久错误进入死信而不是无限消费。
预算告警通常只是通知，不一定自动阻止费用。是否硬停止服务应由业务损失、用户承诺和安全风险共同决定，不能让财务阈值直接破坏数据一致性。
即使只有一位开发者，也要写出停服、回滚、密钥轮换、联系供应商和恢复数据的顺序。多人团队则明确一线响应、升级人、业务决定人和对外沟通人；共享账号不等于责任交接。
上线前至少演练：应用 5xx、数据库连接耗尽、模型供应商 429、队列堆积和费用快速增长。每次演练记录发现时间、通知时间、止损时间和恢复时间。
Built with