发布系统上线前要看哪些日志
发布系统上线前，日志不是给人临时翻错误行的杂物，而是确认构建、部署、启动、请求、任务、依赖、数据库、权限和告警链路是否可追溯的证据层。
很多系统上线前，团队会盯着一个问题：“有没有报错？”这个问题当然重要，但它太窄了。发布系统最危险的情况，往往不是屏幕上跳出一行红色错误，而是看起来已经上线，实际却缺少证据：不知道部署的是哪个版本，不知道健康检查为什么通过，不知道某个用户请求走到了哪台机器，不知道后台任务有没有开始跑，也不知道第三方接口失败时系统留下了什么线索。
日志不是上线仪式里的附属品。它是系统把自己的行为按时间留下来的事件流。OpenTelemetry 文档把 log 描述为带时间戳的文本记录，可以是结构化或非结构化，并可带元数据；Twelve-Factor App 则把日志视为从运行进程和支撑服务输出流里收集的、按时间聚合的事件流。换句话说，上线前看日志，不是为了把所有文字读一遍，而是确认系统一旦出事，有没有足够线索让人知道发生了什么、影响了谁、从哪里开始查。
对一个发布系统来说，上线前至少要回答四个问题：新版本有没有被准确记录？流量进入系统后有没有路径证据？失败和慢请求能不能定位到原因？敏感信息有没有被不该记录的日志带出去？如果这四个问题答不上来，即使当前页面能打开，也只是“这一次看起来没坏”，还谈不上可运营。
先区分日志、指标和链路
上线前经常出现一种误会：只要有日志，就等于有监控。实际上，日志、指标和链路追踪各自负责不同层面。Google SRE Workbook 说明，监控可以包含指标、文本日志、结构化事件日志、分布式追踪和事件内省；同一章也强调，日志是事件的追加记录，指标是按时间采集的数值，日志常用于找问题根因，指标更适合较快触发告警和看趋势。
发布系统上线前要看的日志，应该和指标配合。指标回答“现在整体是否异常”：流量、延迟、错误率、资源饱和度有没有变化。Google SRE Book 提出的四个黄金信号是 latency、traffic、errors、saturation。日志回答“这次异常的事件细节是什么”：哪个版本、哪个请求、哪个用户动作、哪个后台任务、哪个依赖、哪条配置、哪次数据库迁移。
如果只看日志，很容易被零散错误吓到，或者被大量无关信息淹没；如果只看指标，又可能知道错误率升高，却不知道是哪条路径、哪个版本或哪个依赖导致。上线前的目标不是把日志当成报警器，而是让日志能在指标报警后快速解释事件。
<figure><img src="images/log_type_map.png" alt="日志类型图"><figcaption>上线前先把发布链路拆成构建、部署、启动、请求、任务、依赖、数据库和权限几类日志。</figcaption></figure>
第一类：构建和制品日志
上线从构建开始。构建日志要能回答：这次发布基于哪个 commit、哪个分支、哪个构建编号、哪个镜像或制品摘要？测试是否执行？依赖安装是否成功？构建产物是否和发布配置匹配？
这类日志不一定给终端用户看，却是事故复盘时最早要查的证据。比如线上异常发生后，第一步通常不是猜代码哪里坏了，而是确认正在运行的版本和预期版本是否一致。如果构建日志只写“build success”，却没有 commit、制品 ID、构建时间、环境、测试结果和发布人，就很难判断线上运行物是不是这次计划发布的对象。
构建日志还要避免两类问题。第一，不要把密钥、完整环境变量、token、cookie 或内部连接串输出到日志里。第二，不要只保留最后几行。很多构建失败的线索在依赖解析、编译警告、测试跳过、包体变化和制品签名环节，只有完整保留才有用。
第二类：部署和编排日志
部署日志记录“制品如何进入运行环境”。它应该覆盖发布步骤、环境、版本号、实例数量、配置加载、健康检查、流量切换、撤销与恢复动作、任务是否完成。这里要特别注意：部署系统说“成功”，不等于业务已经可用；它可能只说明命令执行完了，或者容器被调度了。
在容器化环境中，Kubernetes 文档说明，应用日志有助于理解应用内部发生了什么，也有助于调试问题和监控集群活动；容器化应用常用的方式是写入标准输出和标准错误。文档也提醒，容器或运行时本身的能力通常不足以构成完整日志方案；如果容器崩溃、Pod 被驱逐或节点失效，仍可能需要访问应用日志，因此日志应有独立于节点、Pod 或容器的存储和生命周期。
这对上线前检查很实在：不能只在当前终端窗口看到日志。要确认日志已经被采集到集中系统，能按服务、版本、环境、实例、时间范围检索；否则一旦容器重启或节点迁移，线索就跟着消失。
第三类：启动和健康检查日志
新版本启动时，要看启动日志。它应记录服务名、版本、环境、启动时间、监听端口、配置摘要、数据库连接、缓存连接、队列连接、对象存储连接、迁移版本、功能开关状态和健康检查结果。
启动日志最常见的问题，是写了大量“服务启动中”，却不写具体节点。更有价值的是“启动到了哪一步”。例如：配置加载成功，数据库连接池建立成功，迁移版本为某个编号，后台任务消费者已启动，健康检查端点已注册，外部依赖可连通。这样一旦系统卡住，就能判断是在配置、网络、数据库、队列还是权限上。
健康检查日志也要谨慎。很多系统把健康检查写得太浅，只要进程活着就返回正常。上线前应确认健康检查是否覆盖必要依赖：数据库是否可读写、缓存是否可访问、队列是否可发布和消费、对象存储是否可读写、外部 API 是否处于可接受状态。不同服务需要不同深度，不能把“进程未退出”当成业务可用。
第四类：请求和访问日志
上线后的第一批真实流量，通常最能暴露问题。请求日志至少应包含时间、服务、环境、版本、请求 ID、方法、路径、状态码、耗时、响应大小、来源 IP 的合规处理结果、用户代理或客户端类型。对登录态服务，还可以记录匿名化用户标识或租户标识，但要避免把个人敏感信息写进日志。
请求日志上线前要重点看三件事。第一，是否每条请求都有可关联 ID，能从入口网关追到后端服务、后台任务和外部依赖。OpenTelemetry 文档说明，日志可以和 trace、span 关联，日志记录也包含 TraceId、SpanId、Severity 等字段。这意味着请求出问题时，不必在多套日志里靠时间模糊搜索。
第二，看状态码分布。4xx 是否符合预期，5xx 是否为零或低于可接受阈值，重定向是否异常增多，静态资源是否出现大量 404。第三，看耗时。一个请求最后返回 200，也可能已经慢到影响使用；上线前要把慢请求和对应日志联系起来，而不是只看成功率。
<figure><img src="images/alert_flow_map.png" alt="告警流程图"><figcaption>指标更适合看整体趋势和触发告警，日志用于解释具体事件，二者要能通过版本和请求 ID 关联。</figcaption></figure>
第五类：应用错误和异常日志
错误日志不是越多越好，而是越可解释越好。一条好错误日志至少要包含：发生时间、服务名、版本、环境、严重级别、错误类型、错误消息、请求 ID 或任务 ID、相关资源 ID、是否已重试、是否已降级、是否影响用户。
OpenTelemetry 强调结构化日志需要稳定 schema，不能只是“看起来像 JSON”。如果每个模块都用不同字段名，有的叫 traceId，有的叫 request_id，有的把错误放在 msg，有的放在 message，后续分析会很痛苦。上线前应检查结构化字段是否稳定，日志系统能否按 severity、service、version、path、status、request_id 查询。
错误日志也要控制噪音。比如某个可预期的外部接口短暂超时，如果已经有重试和降级，不一定需要让人被每一条日志打断。Google SRE 的监控哲学强调告警要可行动、低噪声；日志可以记录细节，但告警应尽量围绕用户可见症状或即将发生的明确问题。
第六类：后台任务和队列日志
发布系统不只处理网页请求。很多上线问题来自后台任务：图片压缩没跑、邮件没发、索引没更新、缓存没预热、转码任务卡住、同步任务一直重试。前台页面看起来正常，但后台队列堆积，过一会儿就会变成用户问题。
队列和任务日志要记录任务 ID、任务类型、来源请求、入队时间、开始时间、结束时间、处理耗时、重试次数、失败原因、死信队列状态、幂等键和相关对象 ID。上线前至少要做一次端到端任务：触发任务、观察入队、观察 worker 消费、观察结果写回、观察失败时是否可追踪。
后台任务日志还有一个常见坑：只在任务失败时记录，成功路径没有记录。这样上线时很难判断“没有结果”是因为任务没触发、任务没消费、任务执行成功但结果没写回，还是结果写回后前台没读取。成功路径至少要保留主要状态变化。
第七类：外部依赖日志
发布系统通常依赖很多外部服务：数据库、缓存、对象存储、CDN、邮件、短信、支付、AI API、搜索、分析系统。上线前要看依赖调用日志，而不是只看应用自己的日志。
这类日志要记录依赖名称、调用类型、状态码、错误码、耗时、超时、重试、限流、降级、请求 ID、版本和调用入口。不要记录完整请求体中的敏感字段，也不要把第三方 token 或签名 URL 原样输出。对于用户体验敏感的依赖，要能区分“依赖失败但系统已降级”和“依赖失败导致用户请求失败”。
外部依赖日志的价值在于把“系统慢”拆开。是入口慢，数据库慢，第三方 API 慢，还是对象存储读取慢？如果日志里没有依赖耗时和请求 ID，团队只能靠猜。上线前可以用一小段测试流量验证：每个重要依赖都有日志，日志里有状态和耗时，并能和入口请求关联。
第八类：数据库、迁移和数据写入日志
很多发布事故来自数据层。数据库迁移是否执行、执行到哪一步、耗时多久、是否锁表、是否出现失败、是否和应用版本匹配，这些都应该在上线前查看。
数据写入日志不应把完整数据内容都写出来，但要保留足够的操作信息：表或资源类型、动作、影响行数、任务 ID、请求 ID、迁移版本、耗时、错误码。慢查询日志、连接池耗尽日志、事务失败日志、唯一约束冲突日志，都能在上线早期提示问题。
需要注意的是，数据库日志和应用日志要能对上。如果应用报“保存失败”，数据库侧却没有对应时间窗口的错误，就要怀疑网络、连接池或权限；如果数据库侧出现锁等待，应用侧出现慢请求，就能较快缩小范围。
第九类：权限和审计日志
发布系统上线前，还要看权限相关日志。管理员登录、角色变更、发布开关、内容删除、配置修改、密钥轮换、Webhook 配置、回调地址修改，都应留下审计事件。审计日志不是普通调试日志，它的目标是可追溯：谁在什么时候做了什么动作，作用于哪个资源，结果是什么。
这里的边界很重要。审计日志要记录动作和结果，但不要记录密码、token、cookie、完整身份证件号、完整银行卡号或不必要的个人敏感信息。对于高权限操作，应记录操作者、审批链、来源 IP 的合规处理结果、用户代理、操作前后摘要和关联工单或发布单。
如果一个发布系统上线前没有权限审计日志，后续出现误删、误发、配置误改，就很难判断是系统问题、权限问题还是误操作问题。审计日志不解决所有风险，但它让复盘有证据。
<figure><img src="images/debug_flow_map.png" alt="故障定位图"><figcaption>上线后如果指标异常，先定位版本和请求，再串联应用、任务、依赖、数据库与权限日志。</figcaption></figure>
上线前不要只看“有没有错误”
看日志时可以按一条简单路径走。
第一，确认日志链路存在。新版本启动后，日志是否进入集中系统？时间是否正确？服务名、环境、版本、实例、请求 ID、trace ID、severity 是否齐全？结构化日志是否能被解析？stdout 和 stderr 是否被采集？Kubernetes 文档提到集群级日志需要独立后端存储、分析和查询，这一点在容器环境里尤其重要。
第二，确认主要路径有日志。构建、部署、启动、健康检查、入口请求、后台任务、外部依赖、数据库迁移、权限审计，每一类都要能找到样本。没有样本的路径，出了问题就会变成盲区。
第三，确认日志可关联。一次用户请求是否能串到网关、应用、任务、依赖和数据库？一次发布是否能串到 commit、制品、部署、实例和流量切换？如果不能关联，再多日志也只是散落文本。
第四，确认日志不泄露。上线前要主动搜索 token、cookie、密码、完整个人信息、连接串、私钥片段、签名 URL。日志一旦进入集中系统，复制、检索和保留范围都比本地终端大得多。
第五，确认告警不会被日志噪音带偏。不是每条 ERROR 都应该叫醒人，也不是每个 WARN 都要阻塞上线。更可取的做法是：用指标观察错误率、延迟、流量和资源饱和度，用日志定位具体事件；对于必须关注的单次事件，可以让应用同时增加计数指标，而不是只靠全文搜索触发告警。
一张发布日志检查表
上线前可以把检查表压成十个问题。
1. 构建日志能否定位 commit、制品、测试结果和构建时间？ 2. 部署日志能否定位环境、版本、实例、配置加载、健康检查和流量切换？ 3. 启动日志能否看到数据库、缓存、队列、对象存储和外部依赖的连接状态？ 4. 请求日志是否包含请求 ID、版本、状态码、耗时和路径？ 5. 错误日志是否结构化，能按服务、版本、严重级别和请求 ID 检索？ 6. 后台任务日志是否记录入队、开始、成功、失败、重试和死信状态？ 7. 外部依赖日志是否记录状态码、错误码、耗时、超时、重试和降级？ 8. 数据库迁移和慢查询是否有可查日志？ 9. 高权限操作和配置修改是否有审计日志？ 10. 日志里是否已经清理敏感字段，并能按保留周期管理？
这张表不是为了让上线变慢，而是为了减少上线后的盲查。发布系统的成熟，不在于永远不出错，而在于出错时能快速知道：哪个版本、哪个路径、哪个依赖、哪个数据动作、哪个权限事件出了问题。日志把这些线索留下来，指标和链路把它们连起来，团队才有机会把上线从“祈祷页面能打开”变成“问题可发现、可定位、可恢复”。
<figure><img src="images/log_launch_checklist.png" alt="检查清单图"><figcaption>上线前的日志检查，要覆盖“有日志、能关联、可查询、不泄露、能辅助告警”五个方向。</figcaption></figure>