后端开发如何做好日志监控与故障排查

做好后端故障排查的核心只有一条：把「指标、日志、链路」三层观测数据用同一个 trace_id 串起来，并让告警在用户投诉之前触发。落地就是三件事——结构化日志、四个黄金指标、一套固定顺序的排障动作。下面按这三件事展开。

日志怎么打才能真的帮上忙？

结论：日志必须写成结构化 JSON，每条带 trace_id、时间戳、级别、服务名、耗时，而不是靠人肉 grep 拼接字符串。

字段固定下来之后，检索效率会有量级差别。推荐的最小字段集是：ts（毫秒时间戳）、level、service、trace_id、span_id、msg、cost_ms、uid。级别使用上，生产环境只开 INFO 及以上，DEBUG 通过配置中心动态开关，改完 10 秒内生效，不要为了排查问题重启服务。

打点密度要克制。一个请求入口和出口各打一条（出口带 cost_ms 和状态码），中间只在关键分支打，单请求日志控制在 5 条以内。日志脱敏是硬要求：手机号、身份证、银行卡、token、密码一律不得写入，否则日志系统本身就是数据泄露源。

写入方式用异步 + 本地文件 + 采集器（Filebeat/Fluent Bit）推送，按天切割并保留 7 到 30 天。同步写日志会直接把 P99 拖高，这是最常见的自伤行为。

监控该看哪些指标？

结论：按 Google SRE 的四个黄金指标建仪表盘——延迟、流量、错误、饱和度，能覆盖绝大多数线上故障。

延迟看分位数而不是平均值，重点盯 P99 和 P95。阈值建议：P99 超过 500ms 且持续 5 分钟触发告警。流量看 QPS，用来判断是量级问题还是代码问题。错误看 5xx 占比，超过 1% 持续 5 分钟告警。饱和度看 CPU、内存、数据库连接池 active 数、消息队列堆积长度。

Prometheus 的抓取间隔设 15s，告警规则里一律加 for: 5m，避免毛刺造成误报。注意结论：资源利用率高不等于服务不可用，告警要基于用户可感知的 SLO，而不是 CPU 到了 80% 就打电话。

出故障时按什么顺序排查？

结论：固定四步走——先止损、再定位、后复盘，顺序不能反。

第一步确认影响面，打开仪表盘看错误率曲线的起始时间点，这个时间点往往直接指向最近一次发布或配置变更。第二步拉最近 15 分钟的错误日志按分钟聚合，例如 grep -c "ERROR" app.log 或直接按 date_trunc('minute', ts) 分组统计。第三步拿一条失败请求的 trace_id 去链路系统（Jaeger、SkyWalking、OpenTelemetry）里看瀑布图，找耗时突增或报错的那个 span。

常见根因集中在五类：慢 SQL 与缺失索引、数据库连接池打满、GC 停顿、下游接口超时未设超时时间、发布变更。定位不到就先止损——回滚、限流、降级、扩容，恢复用户可用性优先于找到根因。

具体故障怎么快速定位？

结论：CPU 高、内存涨、接口慢这三类问题各有对应的命令，别靠猜。

CPU 打满时先 top -H -p <pid> 找到最耗 CPU 的线程号，Java 用 jstack <pid> 导出栈后拿线程号的十六进制去比对 nid，Go 直接开 pprof 抓 30 秒火焰图：go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30。

内存持续上涨时，Java 用 jstat -gcutil <pid> 1000 观察老年代占用是否只涨不降，Go 抓 heap profile 对比两次快照。接口变慢时先看慢查询日志和执行计划，再检查连接池的 active/wait 指标，以及下游调用有没有显式设置超时——结论：任何跨进程调用不设超时时间，都是一颗定时炸弹。

告警怎么配才不烦人？

结论：每条告警都必须绑定一个明确的处理动作，没有 runbook 的告警直接删掉。

按错误预算来配：可用性目标 99.9%，一个月允许的不可用时间约 43 分钟，告警应该在这个预算被快速消耗时才响。分级上，P0 走电话、P1 走群消息、P2 进日报，避免所有告警都推送到同一个群导致麻木。

最后一点也最关键：每次故障后写一份不超过一页的复盘，只回答三个问题——影响多久、根因是什么、加了哪条监控能在下次提前发现。把这条监控补上，排障能力才是真的在长。