1. 为什么我们需要关注日志记录日志系统就像飞机的黑匣子记录着系统运行时的每一个关键动作。我在处理线上故障时90%的案例都是通过日志快速定位的。最近一个典型例子某电商系统在促销期间突然出现订单丢失最终通过Nginx访问日志发现是负载均衡策略导致请求被错误路由。现代系统日志已从简单的文本记录发展为包含结构化日志JSON格式分布式追踪TraceID串联指标监控Prometheus格式安全审计符合ISO27001标准2. 日志记录的核心要素设计2.1 日志级别划分实践我建议采用五级分类法从低到高DEBUG开发调试用如变量值打印INFO关键业务流程节点如用户登录成功WARNING可恢复的异常如缓存失效回源ERROR需要干预的故障如数据库连接失败CRITICAL系统级故障如磁盘写满关键经验线上环境默认只记录INFO及以上级别通过动态调整功能如Log4j2的JMX控制临时开启DEBUG排查问题2.2 日志内容规范优秀日志应包含# 反面案例无用日志 logger.info(Processing request) # 正面案例 logger.info( f[订单创建] 用户:{user_id} 商品:{sku_ids} 金额:{amount}, extra{ trace_id: request_id, client_ip: remote_addr } )必须包含的要素业务场景标识如[订单创建]关键业务参数用户ID等请求上下文TraceID、IP等时间戳建议UTC格式3. 主流日志方案对比选型3.1 单机场景方案工具优势适用场景性能影响Log4j2异步日志、动态配置Java应用低Zap零内存分配、结构化日志Go应用极低Winston多传输协议支持Node.js应用中3.2 分布式系统方案ELK Stack实战配置示例# Filebeat配置片段 filebeat.inputs: - type: log paths: - /var/log/app/*.log fields: env: production output.elasticsearch: hosts: [es01:9200] indices: app-logs-%{yyyy.MM.dd}关键考量点日志采集延迟Filebeat vs Fluentd存储成本ES冷热数据分离查询性能合理设置分片数4. 问题定位的实战技巧4.1 高频问题排查模式超时问题检查日志中的时间戳差值示例[API] start2023-07-20T08:00:00.000Z end2023-07-20T08:00:05.123Z并发问题搜索重复的TraceID检查线程ID是否冲突数据不一致对比不同服务的日志时间线使用jq工具分析JSON日志差异4.2 高级分析工具链Linux基础工具组合# 实时监控错误日志 tail -f app.log | grep --color -E ERROR|CRITICAL # 统计错误类型分布 awk /ERROR/{print $5} app.log | sort | uniq -c | sort -nr日志可视化分析Grafana Loki的LogQL查询{apporder-service} | Timeout | pattern ip - _ method uri _ status _ latency | latency 5s5. 生产环境日志管理规范5.1 日志切割策略推荐采用时间大小双维度滚动# Log4j2配置示例 RollingFile nameFileAppender fileNameapp.log filePatternapp-%d{yyyy-MM-dd}-%i.log Policies TimeBasedTriggeringPolicy interval1/ SizeBasedTriggeringPolicy size500MB/ /Policies /RollingFile5.2 敏感信息过滤必须处理的敏感字段身份证/银行卡号正则过滤密码/Token完全屏蔽IP地址生产环境脱敏实现方案示例// Logback的替换规则 replace regex\b\d{18}\b/regex replacement***ID***/replacement /replace6. 典型故障排查案例最近处理的Redis连接泄漏问题现象服务每隔几天就出现连接超时排查过程发现ERROR日志中有Connection timeout通过netstat确认连接数持续增长在代码中找到未关闭的连接池解决方案添加try-with-resources块增加连接数监控日志日志关键片段[REDIS] Connection pool stats: active78, idle2, max100这个案例让我养成了在资源操作类日志中强制记录状态指标的习惯