线上故障排查需结构化日志：统一格式，必含request_id、service_name、host、level、timestamp等字段，分级输出（info/warning/error），高频日志采样，避免混乱与信息丢失。
线上故障排查，日志是最直接、最可靠的线索来源。关键不是“有没有日志”，而是“日志是否可查、可定位、可关联”。核心在于结构化记录 + 精准过滤 + 上下文串联。
统一日志格式，带上关键上下文字段
默认的 print 或简单 logging 输出，在多线程/异步/微服务环境下极易混乱。必须在日志中固化以下字段：
- request_id：全链路唯一标识，所有日志（Web请求、DB操作、消息消费）都带上它，便于跨模块串联
- service_name 和 host：明确日志来源服务与机器，避免集群中日志混杂
- level、timestamp（精确到毫秒）、funcName、lineno：基础定位信息
- 业务关键字段（如 user_id、order_id、trace_id）：按需动态注入，不要硬编码进 logger，用
logger.info("xxx", extra={"user_id": uid})
分级输出 + 合理采样，避免日志爆炸或关键信息丢失
线上环境不能全量 DEBUG，也不能只留 ERROR：
- INFO 级别记录主流程入口/出口、关键状态变更（如“订单创建成功”、“支付回调接收”）
- WARNING 记录预期外但未中断流程的情况（如降级触发、缓存未命中率突增）
- ERROR 必须包含完整异常栈（用
logger.exception()而非logger.error(str(e))） - 高频日志（如每秒千次的埋点）做采样，例如
if random() ，保留特征又不压垮磁盘
快速定位：用工具链代替人工 grep
单机查日志用 grep -A 5 -B 5 "request_id=abc123" 效率低且易漏；生产环境推荐组合：
立即学习“Python免费学习笔记（深入）”；
- 集中采集：用 Filebeat / Fluentd 把日志实时推到 Elasticsearch
- 精准检索：Kibana 中用
request_id: "abc123" AND level: "ERROR"过滤，再按时间排序看上下游 - 关联分析：用 Kibana 的 “Discover” 或 “Lens” 查看同一 request_id 下各服务的日志时间线，识别延迟瓶颈或异常跳变
- 临时调试：若无 ELK，可在代码中加临时日志（务必带 request_id），并用
tail -f app.log | grep "request_id=xyz"实时盯屏
补充手段：日志之外的关键检查点
日志可能缺失或滞后，需交叉验证：
- 检查进程状态：
ps aux | grep python看是否 OOM 被 kill，或 stuck 在某个调用 - 查系统指标：
top、df -h、netstat -an | grep :8000排查资源耗尽或端口占满 - 复现链路：用相同 request_id 的入参，本地或预发环境重放请求，对比日志差异
- 数据库慢查：开启 slow query log，查是否有未走索引的查询拖垮接口
