日志要能定位问题，也要守住隐私

故障发生时，团队希望日志能回答几个具体问题：请求到达了吗，卡在哪一步，返回了什么类别的错误，影响持续了多久？为了得到答案，最容易想到的办法是把请求和响应完整写入日志。但正文往往含有个人信息、访问令牌或其他不该长期复制的数据。

日志的目标不是重建访客说过的每句话，而是描述系统发生了什么。一个结构化事件通常可以记录时间、服务与路由、阶段、结果状态、耗时、请求关联 ID 和受控错误代码。用稳定字段描述事件，聚合和筛选会比搜索自由格式文本可靠得多。

让关联 ID 代替大段正文

请求进入系统时生成随机关联 ID，并在内部服务之间传递。日志可以用它把同一条请求的校验、缓存、上游调用和响应关联起来，而无需保存完整问题文本。发生故障时，支持人员可以请用户提供界面显示的编号，再从受限的运维系统查看相关事件。

关联 ID 不应编码邮箱、用户编号或其他可识别信息，也不应被误当成身份凭证。它的用途是连接事件，不是授权访问。公开给访客的错误消息只需包含排查所需的短编号，不应顺带泄露服务内部名称或堆栈。

明确哪些字段不该进入日志

授权头、Cookie、API 密钥和密码应直接排除。问题正文、留言内容、响应正文也应默认不记录；如果某个场景确有必要，需要限定字段、访问人员和保留期限，并对数据做最小化处理。日志平台也属于数据存储系统，不能因为它叫“观测工具”就绕过隐私审查。

脱敏规则应在进入日志系统之前执行，而不是依赖每位开发者记得手动清理。还要注意 URL 查询参数、异常对象和第三方 SDK 自动附带的上下文，它们可能悄悄带入令牌或个人内容。抽样也不等同于脱敏：抽到的那条记录仍然可能包含敏感数据。

让记录有期限、有范围

保留时间应与排查需要匹配。短期运行日志和长期趋势指标可以采取不同策略；指标通常只保留汇总值，详细事件则按需要更快删除。访问权限要限制在确实负责运行与支持的人员，并保留适当的访问审计。

好的日志既提供定位线索，也主动减少不必要的信息。先写出需要回答的运维问题，再为每个问题挑选最小字段，通常比先收集全部内容、以后再想办法删掉更稳妥。