日志采集
日志最佳实践的目标是让故障发生时可以快速检索到“哪个服务、哪个请求、哪段代码、什么错误”。日志采集本身只是第一步，字段设计、索引和留存同样重要。
| 字段 | 说明 |
|---|---|
timestamp | 日志时间，统一时区 |
level | debug、info、warn、error |
service | 服务名 |
namespace | Kubernetes 命名空间 |
pod | Pod 名称 |
trace_id | 请求链路 ID |
request_id | 单次请求 ID |
message | 日志正文 |
应用优先输出 JSON 结构化日志，便于日志平台解析和索引。
- 业务日志优先输出到 stdout/stderr。
- 必须写文件时，路径、滚动方式和采集规则一起管理。
- 不采集敏感字段，例如密码、Token、完整身份证号。
- debug 日志默认不长期保存。
- error 日志建议建立独立告警和检索入口。
| 日志类型 | 建议 |
|---|---|
| debug | 短期保留或按需开启 |
| info | 按业务重要性设置 7-30 天 |
| error | 保留更久，支持复盘和审计 |
| 审计日志 | 按合规要求保留 |
日志成本通常来自写入量、索引量、存储和查询。索引字段越多越好用，但成本也越高，需要按查询场景设计。
- 所有告警都附带日志查询条件。
- 所有入口请求都带
trace_id或request_id。 - 业务错误码和下游依赖错误单独成字段。
- 发布版本号写入日志字段，方便定位发布相关故障。