日志这件事干得越久越觉得它是服务端排障的核心。我做了二十年一线系统架构和运维遇到过无数“看起来像配置问题”“查到最后是日志问题”的案例。很多新手第一反应是看服务状态、试重启而老手往往先翻日志。服务类日志分析说白了就是给系统做“病历”解读日志策略则是给这个病历提前定好“拍摄范围”和“清晰度”。这篇我打算从方法论讲到实操把我这些年沉淀下来的日志分析套路、策略设计思路和踩坑记录拆开揉碎作为这个系列的第一篇输出。适合正在学Linux运维的朋友、背面试题的系统工程师以及想让日志体系更规范的技术负责人。1. 从“看日志”到“设计日志策略”差距在哪里1.1 日志不只是排障工具更是系统的“黑匣子”早年我遇到过一起棘手的故障线上订单服务每隔几天深夜就出现延迟尖刺查了数据库、网络、代码都没有定论。后来翻看认证服务的详细日志发现是和客户端会话保持时间相关的偶发高耗时操作之前根本没采集这一层日志。这件事让我意识到日志分析能不能救命取决于你之前有没有做好日志策略。简单说日志策略包含三件事记录什么不是所有输出都要存而是按照业务关键路径选点覆盖登录、鉴权、请求入口、核心依赖调用、错误异常这几类。记录多详细平时用info级别重要的外部接口调用可以记debug到独立文件,不要把debug直接开全局,否则磁盘直接被冲爆。保留多久、怎么归档根据合规和排障需要一般保留30天到180天用logrotate切割压缩配合集中收集。你会不会也遇到这种情况出了故障上服务器看/var/log/messages发现日志早就被挤得只剩最近几小时内容完全没法追溯。这就是典型只“看日志”不“设计日志”的后果。1.2 服务类日志和系统日志的区别服务类日志指由应用或业务服务自己产生的运行记录像Nginx的access.log、Tomcat的catalina.out、业务进程的stdout输出系统日志则是内核和systemd产生的messages、journal日志。两者必须分开处理。我见过不少团队把所有日志都交给rsyslog统一收结果应用日志还被按level打了不同标记自定义格式乱七八糟后来想用字段检索都没法做。正确的做法是分而治之类型典型来源特点策略侧重系统日志kernel, systemd, audit格式相对固定时间粒度细重点监控硬件、服务启停、崩溃、被kill服务日志nginx, mysql, java进程, 业务应用字段跟业务强相关量级波动大记录全量请求、告警错误、关键事务安全日志sshd, su, 登录认证敏感需要严格权限独立保存重点审计失败尝试不同日志分析手段也不同。系统日志看趋势和异常事件服务日志要结合业务链路串起来。我见过只会在messages里grep关键字的新人遇到业务报错就抓瞎——不是他们不努力是根本不知道日志还有源和应用之分。1.3 分析日志前必须先建立的三种“时间观”日志分析第一道坎不是技术是时间校准。很多服务容器内是UTC宿主机是北京时间数据库时区又设成东八区结果查一条报错前后差了8个小时方向完全搞反。我的习惯是所有服务器统一使用系统时区且启用时间同步chrony应用日志、容器日志统一格式为带时区的ISO8601字符串集中采集时在日志行附上接收端时间戳方便对比网络延迟。没有这个基础后面所有排序、串联、统计都是空中楼阁。我在排查一次“凌晨三点告警”时就因为容器内日志用UTC愣是误判了半小时业务高峰最后才发现其实对应的是北京时间早上八点整的流量高峰。2. 服务日志分析的整体思路与策略设计2.1 先建索引还是先画链路我的建议是先画链路刚接触日志分析的人喜欢上来就写一堆grep和正则试图把所有日志拉一遍。但这属于“撒网式排查”效率极低。我建议先画出服务依赖链路用户请求进来之后经过网关、认证、业务A、缓存、数据库这一步用了多少个组件每个组件在哪个日志文件里留痕。拿到这份清单后“日志分析”才有抓手按请求时间戳在各服务日志里找到同一个traceId或会话ID按调用顺序从上到下查看哪一段耗时异常或报错针对异常段进入对应服务详细日志定位到具体函数或者SQL。手工操作可以用grep、awk也可以用perl提取字段。如果能通过日志配置提前输出统一的trace_id那么分析效率直接翻倍。这一点值得在日志策略里强制规定所有跨服务调用的日志行必须打印traceId、请求路径、耗时、返回码。2.2 日志级别怎么设才不浪费空间又不丢关键信息日志级别大多数框架都分TRACE、DEBUG、INFO、WARN、ERROR、FATAL。但“线上开INFO测试开DEBUG”这句通用经验只能算入门真正要结合模块的重要性来定。我的策略清单里有几条原则核心交易链路INFO级别关键步骤必须打点外部依赖超时单独打WARN错误堆栈打ERROR。非核心功能比如用户偏好设置、推荐算法日志可以只记录WARN以上减少磁盘占用和IO压力。全局ERROR日志单独切文件不要混在stdout里方便告警和快速扫错。动态调整级别生产环境一般通过配置中心或发信号量改变日志级别遇到疑难问题临时打开指定类包的DEBUG排查完必须关闭。举个例子有一个支付回调服务平时info日志量大概每天8GB。后来把回调请求体、响应体全部下沉到debug级别只保留支付单号、状态、耗时等指标字段日志量降到每天2.3GB排障信息照样够用。2.3 日志轮转与保留策略宁可多留冷数据不可关键时刻没数据日志轮转不光是logrotate一个配置的事它牵扯到文件句柄、切割时机和时间跨度。首要注意很多应用进程启动后一直持有日志文件的文件句柄。如果你用logrotate切割日志但没告诉进程重新打开文件切割完成后进程还会继续往旧文件写。典型表现是磁盘不减反增或者原文件变成0字节但大小仍在增长。解决方式是通过copytruncate或者日志组件里配置daily maxBackup 自动reopen。我的推荐配置模板以logrotate为例/var/log/nginx/*.log { daily rotate 14 compress delaycompress missingok notifempty create 0640 nginx adm sharedscripts postrotate [ -f /var/run/nginx.pid ] kill -USR1 cat /var/run/nginx.pid endscript }这段配置说明每天切割保留14份压缩但延迟一天压缩为了给正在写入的日志留缓冲通过postrotate给nginx发信号让进程重新打开新文件。如果你用systemd的journald也要设置SystemMaxUse别让它无限吃内存盘。我们生产环境有个常见设定SystemMaxUse1GRuntimeMaxUse256M避免/run目录被撑爆journal永久日志再单独转storagepersistent并限制大小。2.4 日志格式规范没有统一的schema再强的工具也白搭很多日志分析困难根源不是工具而是日志格式随心所欲。比如有人打“2024-01-01 12:00:00,123 ERROR连接失败”有人打“01/Jan/2024:12:00:00 0800, failed”解析起来非常痛苦。我强烈建议凡新写服务必须遵守统一日志格式至少包含时间ISO8601或unix时间戳级别单一大写单词traceId/requestId必填线程名/模块名排障收敛范围用业务关键字比如订单号、用户ID消息内容不能带换行多行异常堆栈另做处理或序列化后单行输出来源文件:行号有最好。实际案例我们维持一个Java网关服务日志用logback pattern实现为: %d{yyyy-MM-dd HH:mm:ss.SSS} %-5level [%thread] [%X{traceId}] %logger{36} - %msg%n在Logstash或命令行工具里都能快速分组。你不一定需要复杂框架但至少在文件命名和字段分界符上要保持一致比如统一用|分隔字段比空格分隔更能容忍内容里的空白。3. 核心实操从日志采集到异常定位的全流程3.1 第一步确认服务日志在哪别犯“目录层级”的低级错误拿到一台陌生的服务器我第一步不是cat而是systemctl status 服务名看进程启动命令和WorkingDirectory再看它的标准输出重定向配置或用lsof -p 进程号 | grep log找出它实际打开的日志文件。很多新人以为服务日志一定在/var/log/xxx下其实docker容器默认把日志打到json-file里systemd服务默认写到journal里老一点的tomcat可能输出到logs/catalina.out。排障时别只看一个路径。我常用的一条命令组合# 找到进程实际打开的所有日志文件 ls -l /proc/$(pgrep -f 你的服务关键字 | head -1)/fd | grep log # 或者lsof更直观 lsof -p $(pgrep -f 你的服务关键字 | head -1) | grep -E \.log|json这里能看到进程当前写入的文件描述符。如果发现它写的文件已经被删除状态标记为deleted说明之前日志被移动或切割后进程没重新打开这个文件会在进程退出前一直占磁盘空间。这种情况非常常见也是日志策略里必须防的坑。3.2 第二步用journalctl与logrotate结合搭建本地日志查询环境journald收集系统和服务日志很方便查看时用journalctl。例如查看某个unit的全部日志journalctl -u nginx.service --since 2024-01-01 00:00:00 --until 2024-01-01 02:00:00筛选指定字段和级别journalctl -u app.service -p err journalctl -k -b -1 # 上一次启动的内核日志注意journald默认可能不持久化重启后历史日志会丢。在/etc/systemd/journald.conf里设Storagepersistent它会自动创建/var/log/journal目录。但我一般不建议把长期业务日志完全交给journald它对文本检索不如直接查文件方便更适合做短窗口快速查看。对于大日志文件logrotate会做好切割然后我们再用grep/awk查询。比如查Nginx某个时间段内5xx的分布zgrep 2024:11:0[1-9] /var/log/nginx/access.log.*.gz | awk $9 ~ /^5/ {print $4} | cut -d: -f1 | uniq -c这段的意思是在已压缩的日志文件中按时间过滤上午9点到下午6点匹配响应码500-599的请求按小时统计数量。可以快速判断5xx是偶发还是某个时间段的集中爆发。3.3 第三步手工日志分析的“三步定位法”如果公司没有上TKE日志服务临时排查故障时我习惯用“三步定位法”。第1步按时间线拉全链路时间线。比如同时登到网关、应用、数据库三台机器各自筛出某一时间段日志grep 2024-11-05T10:15:0 /var/log/app/order.log | grep order_889988把每条日志按时间排序找到“请求进入网关”-“鉴权通过”-“订单查询”-“扣库存超时”的位置。这一步的目的是确认卡在哪一跳。第2步按关键字统计异常比例。使用awk对错误码、耗时做聚合awk {print $7} access.log | sort | uniq -c | sort -rn | head -20这个统计能看到哪些接口被调用最多再结合耗时尾部指标(P99)确定异常接口。第3步下钻到单条请求的详细上下文。筛选traceId后把同ID的所有行按时间序排列grep traceIdabc123 /var/log/app/order.log | tail -100观察异常前后的变量和状态。每次排查我都建议把“关联ID 时间窗口 端到端耗时”打印在一张纸上或者思维导图里比纯靠眼睛在终端里翻效率高很多。3.4 第四步日志策略落地写一个可复用的shell分析脚本我为了让团队“人人都能查日志”通常会把常用分析动作封装成脚本。下面是一个压缩日志按时间范围错误级别统计的示例#!/bin/bash # 用途统计某个时间段内各错误码出现次数需传入日志文件和时间窗口 LOG_FILE$1 TIME_START$2 TIME_END$3 # 时间参数示例2024-11-05T00:00:00 到 2024-11-05T01:00:00 zgrep -h $TIME_START\|$TIME_END $LOG_FILE* 2/dev/null \ | awk -v ts$TIME_START -v te$TIME_END $0 ~ ts || $0 ~ te { print } \ | awk {for(i1;iNF;i) if($i ~ /(ERROR|WARN)/) {print $i}} \ | sort | uniq -c | sort -nr实际使用时更严谨的做法是按时间字段截取中间部分再比较字符串。说实话复杂分析不适合纯shell但这个脚本的价值在于低成本复用尤其在只有两三台机器、不想搭建ELK的团队很实用。如果你日志字段用竖线|分隔第二列是时间第三列是级别分析一行命令cut -d| -f2,3 /var/log/business.log | sed -n /2024-11-05 09:00/,/2024-11-05 10:00/p | awk -F| {cnt[$2]} END{for(k in cnt) print cnt[k],k}这种统一格式的好处体现得淋漓尽致不需要正则提取按分隔符处理就能完成大部分统计。4. 常见问题与排查技巧实录4.1 日志文件不写了被旋转进程没重新打开场景logrotate把app.log重命名为app.log.1但应用进程还在向app.log.1写入导致最新日志全跑到旧文件而你一直盯着新的app.log看什么都看不见。排查技巧# 检查进程文件描述符指向哪个文件 ls -l /proc/$(pgrep -f app | head -1)/fd | grep app.log # 如果显示 /var/log/app.log.1 (deleted)说明它一直在写旧文件解决办法给服务配logrotate的copytruncate选项或用kill -USR1方式让进程重新打开日志。对于java应用很多框架支持配置中定期重新打开比如Logback的prudent模式或自定义触发。我的一次真实经历是某消息队列消费者一直写日志监控看到磁盘缓慢增长手动删掉一个巨大的旧日志后磁盘空间竟然没释放一查正是进程持有旧文件句柄。后来必须重启应用才释放空间。所以检查deleted句柄应纳入日常巡检。4.2 日志时间对不上容器UTC宿主机应用时区各说各话现象应用日志记录凌晨1点异常数据库记录早上9点报错中间还有容器日志用UTC完全没法对照。故障复盘后定下的规矩宿主机统一修改为“Asia/Shanghai”容器内TZ环境变量统一设置并且/etc/localtime同步日志字段输出时强制带时区不要输出裸时间所有集中式日志平台ELK/Loki对接收时间做统一时区配置。排查小技巧看时间差可以用一句Python判断date -d 2024-11-05 08:00:00 %s date -d 2024-11-05T00:00:00Z %s如果两个时间戳相同说明一个是本地时间一个是UTC换算关系就清楚了。4.3 磁盘空间突然被日志占满误配DEBUG或循环输出最常见的是某个类库debug日志被打开包含循环打印的参数体一晚上日志就几十GB。排查技巧是查看大文件排行du -ah /var/log | sort -rh | head -10 journalctl --disk-usage如果发现是某个unit日志疯狂写入先动态调整级别很多框架支持运行时改级别再清理历史journalctl --vacuum-size500M不推荐直接rm日志文件最好让进程正常轮转。对于JVM应用如果STDOUT没被重定向systemd会把大量stdout内容存到journal也可能导致/var/log/journal体积暴涨。这种情况是在Service配置里加StandardOutputnull或StandardOutputappend:/var/log/app_stdout.log避免journald无限增长。4.4 关键字搜不到日志级别过滤掉了真正错误有时业务明明异常但日志里搜不到“ERROR”。原因大多是错误被框架捕获又只打了WARN或者异常信息里根本没包含你搜的关键词。排查思路是先看服务状态和调用结果码再看框架层日志级别配置。例如Java Spring Boot的logback默认打印controller层异常为ERROR但某些hystrix熔断日志是WARN你搜ERROR自然漏掉。这时候要用更宽的条件grep -E ERROR|WARN|Exception|Timeout|CircuitBreaker app.log另一个常见情况界面报错日志里只有一个UUID引用具体堆栈在另一个异步线程里。这种情况必须通过traceId或者requestId串联。所以我在日志策略里强制“每一次请求进来第一行必须打印traceId”后面的所有日志都带上它。有次客服反馈“订单提交失败”我就在网关日志里搜这个traceId发现业务A调业务B超时业务B其实没收到而是A内部自己把请求吞了最后超时返回。这个根因如果没有traceId串联只能靠猜。4.5 常见问题速查表现象可能原因排查命令/动作解决方向查日志最新内容还是一小时前进程还在写旧文件deleted句柄ls -l /proc/PID/fdlogrotate增加copytruncate或进程重新打开日志日志时间与当前不符时区或时钟漂移timedatectl status启用chrony设置统一时区journald占用几个GBSystemMaxUse未限制journalctl --disk-usage设置SystemMaxUse减少保留量应用日志中有大量“???”或乱码日志编码不一致file 日志文件统一UTF-8容器内语言环境设为C.UTF-8某个grep没有结果日志级别过滤或关键字太严grep -iE “errexception日志文件权限变成root且应用无法写轮转后属主变化ls -l /var/log/*.loglogrotate create 参数指定正确属主容器中nohup.out越来越大容器内程序直接追加输出du -sh nohup.out改配置让日志按天滚动限制stdout重定向这张表基本涵盖了团队里新手最常见的踩坑点。日志问题其实比代码逻辑问题更讲“现场保护”在没搞清句柄和轮转之前别急着删文件否则可能破坏排障现场。5. 日志分析与策略的进阶自动化告警与集中式检索思路5.1 手工分析之上的“三分钟告警”机制日志分析的最高境界不是出事时快速查日志而是在出事之前就收到准确告警并且告警信息里直接给出线索。我建议至少做三个自动化告警错误率告警统计5xx或ERROR数量在5分钟内超过阈值延迟告警统计请求P99超过500ms后触发服务存活告警心跳日志连续N分钟没有更新。不需要一开始就上复杂系统用shellcron也能实现基础版。例如每分钟扫一次日志文件里最近5分钟错误计数#!/bin/bash # 检测最近5分钟ERROR数量超过20则告警 LOG/var/log/app/error.log CNT$(tail -500 $LOG | awk -v now$(date %Y-%m-%d %H:%M:%S) { # 其实比较时间复杂这里简化为直接数ERROR if ($0 ~ /ERROR/) c } END {print c0}) if [ $CNT -gt 20 ]; then echo app error count $CNT in last lines | mail -s App Error Alert opsexample.com fi注意上面示例用了简单方式生产环境如果日志量大应该用带checkpoint的方式增量读取或用现成的filebeat收集后到Kafka/ES里做告警。但核心不是工具而是把指标定义清楚。5.2 集中式日志该不该上什么时候上我常被问到“几台服务器需要搭建ELK吗”。我的建议三台以下各机器本地logrotategrep完全够用超过十台或者需要跨机器串traceId、做长期趋势分析时就该上集中式方案。集中式方案常见组合EFK/ELKFilebeat采集Logstash或Kafka缓冲Elasticsearch存储Kibana展示。适合需要复杂检索和聚合的场景。LokiGrafana轻量适合以日志内容索引为主不适合大规模全文检索但部署和资源占用少。ClickHouse向量日志适合超大规模配合业务字段存储。无论选哪一种统一日志格式都是前提。否则采集端就算解析成功字段缺失也会让后续分析失去意义。我近几年比较偏爱“采集侧先用轻量脚本做结构化再入检索系统”的思路。比如Filebeat的dissect或grok可以先把一行日志拆出时间、级别、traceId、路径、状态码后面的聚合查询才可视化。举个例子在Kibana里想查“某接口P99耗时”如果日志里没有单独的耗时字段就只能用KQL全文搜不够方便。所以在服务端打印时就把cost123ms这种字段带出来采集端自动映射成cost字段这样才能实现真正的量化分析。5.3 安全与审计日志的策略该留的必须留够该抹的别留神服务类日志不仅用于定位故障还需要支持安全审计。比如SSH登录日志、sudo记录、配置变更记录这类日志即使平时没有故障也要长期保存。对于这类日志我的策略是单独目录权限设为600或640只有root和审计组可读异地同步一份防止本机磁盘被清理后无法回溯监控“多次认证失败”“非工作时间sudo”等异常行为。一条快速扫描暴力破解的命令grep Failed password /var/log/secure | awk {print $(NF-3)} | sort | uniq -c | sort -nr | head -10这能统计攻击来源IP。但更重要的不是事后统计而是事前用fail2ban类工具自动拉黑。日志分析如果只用于“事后查案”价值就打折了一半。正确姿势是区分“排障日志”和“安全审计日志”审计日志单独设置保留周期不能执行logrotate的7天清理。5.4 回顾一个完整的日志策略案例我用一个虚拟的订单服务场景把前面原则串起来。场景有三台业务服务器加一台数据库服务器每天订单量约10万预计单机日志5GB。设计流程业务日志路径/data/logs/order/order.log内容切分为时间|级别|traceId|接口|耗时|状态|业务ID|信息统一UTF-8输出级别INFO级别只打关键节点参数体统一DEBUG全局ERROR独立到error.log轮转每天切割保留30天压缩delaycompress进程通过USR2信号重新打开日志磁盘预留每台机器预留日志磁盘100GB按30天算150GB压缩后可压到30-50GB预留一倍缓冲告警每5分钟统计ERROR数量超过30报警P99耗时超过800ms报警错误码5xx比例超过5%报警。这套方案在一台4核8G的机器上日志服务本身占用CPU在2%以内算是非常轻量。到了10台以上再考虑加Filebeat采集到集中式平台。6. 日志分析策略里那些没人写但很重要的习惯6.1 看完日志必须清掉可能泄露信息的敏感内容日志里偶尔会有密码、token、手机号等敏感信息。我踩过坑调试时把http请求头全部打印到debug结果日志轮转压缩后还长期躺在磁盘上安全审计差点出问题。日志策略上必须加“脱敏”环节日志框架里对密码、身份证、token字段执行掩码处理线上日志禁止打印Authorization头日志文件权限不能让普通用户可读特别是包含用户信息时。虽然这不是分析本身但日志分析能走多远取决于日志是否合规可存。敏感信息不清存储和采集本身就是风险这个习惯值得从一开始就养成。6.2 日志分析不只是“出现问题才打开”日常巡检也是分析的一部分我要求团队每周做一次轻量日志巡检看ERROR趋势、慢接口Top10、磁盘占用趋势、错误日志关键字分布。不必写复杂报表一条命令就能完成# 统计今天各小时错误数 grep $(date %F) /var/log/app/error.log | cut -d| -f2 | cut -d: -f1 | uniq -c正常系统错误分布往往有规律凌晨低谷、白天平稳、发版时短暂上升。如果某天某个小时突然从0跳到上百不用等用户投诉告警就会提醒你。这个日常巡检的价值是建立“正常基线”没有基线告警阈值拍脑袋要么天天误报要么失效。6.3 日志分析是一个需要持续迭代的“产品”不是一次性配置这几年我发现日志策略必须像软件一样持续维护每次故障复盘后要问三个问题这次回看日志哪些关键信息当时没记录哪些日志字段格式不利于快速检索告警阈值是否合理是否需要调整有次我们定位一个网络抖动故障发现业务日志里根本没记录“发送请求时的socket连接耗时”只能靠猜测。后来在HTTP客户端层加上连接建立耗时和响应耗时的分离埋点两周后就捕捉到一次网络设备异常导致的连接创建耗时飙升。没有这次日志字段迭代问题可能要到用户投诉才能发现。还有一次我们调整了保留周期从15天变到45天起因是某个只在周末出现的故障15天后查不到前一天的数据拉长了观察窗口后才看到周期性规律。这些都是“日志策略迭代”的典型场景。6.4 工具推荐和取舍grep、awk、rg、lnav哪个更适合日常日常手工分析我用这几个工具grep最基础适合小文件快速搜索rgripgrep多文件大目录搜索速度远超grep且默认支持正则适合日志分析我几乎在每个服务器上都装了awk按字段统计、过滤的瑞士军刀lnav可以在终端里像看自动化工具一样展示日志支持按时间排序和语法高亮对日志文件比较友好jq如果日志是JSON格式直接管道处理非常方便。举个例子用rg快速找出最近五分钟的错误消息rg 2024-11-05T0[89]: /data/logs/app/*.log | rg ERROR | head -50如果日志超大量建议先zcat解压后的rg。压缩日志可以先zgrep或者rg --text。工具不必贪多掌握grep awk rg解决90%的临时分析需求就够。正式点说我总跟团队讲“能用键盘加管道完成的日志分析就别引入一堆云产品”因为轻量手段在故障时的可用性和速度常常是最高的。这个系列后续会写的方向第一篇先到这里。关于日志分析后面我准备继续聊这几个话题常见服务Nginx、MySQL、Redis、Kafka的日志指标解读容器环境下的日志采集和策略基于日志的故障定界方法论大规模日志平台选型与调优。如果你在日志分析遇到什么“查不出来”的案例欢迎一起探讨。我自己始终有个观点日志策略做得好的系统故障恢复时间至少能缩短一半而优秀日志策略的核心不是工具而是对业务和系统依赖理解的深度。
服务日志分析与策略设计：从排障到体系化运维的实战指南
日志这件事干得越久越觉得它是服务端排障的核心。我做了二十年一线系统架构和运维遇到过无数“看起来像配置问题”“查到最后是日志问题”的案例。很多新手第一反应是看服务状态、试重启而老手往往先翻日志。服务类日志分析说白了就是给系统做“病历”解读日志策略则是给这个病历提前定好“拍摄范围”和“清晰度”。这篇我打算从方法论讲到实操把我这些年沉淀下来的日志分析套路、策略设计思路和踩坑记录拆开揉碎作为这个系列的第一篇输出。适合正在学Linux运维的朋友、背面试题的系统工程师以及想让日志体系更规范的技术负责人。1. 从“看日志”到“设计日志策略”差距在哪里1.1 日志不只是排障工具更是系统的“黑匣子”早年我遇到过一起棘手的故障线上订单服务每隔几天深夜就出现延迟尖刺查了数据库、网络、代码都没有定论。后来翻看认证服务的详细日志发现是和客户端会话保持时间相关的偶发高耗时操作之前根本没采集这一层日志。这件事让我意识到日志分析能不能救命取决于你之前有没有做好日志策略。简单说日志策略包含三件事记录什么不是所有输出都要存而是按照业务关键路径选点覆盖登录、鉴权、请求入口、核心依赖调用、错误异常这几类。记录多详细平时用info级别重要的外部接口调用可以记debug到独立文件,不要把debug直接开全局,否则磁盘直接被冲爆。保留多久、怎么归档根据合规和排障需要一般保留30天到180天用logrotate切割压缩配合集中收集。你会不会也遇到这种情况出了故障上服务器看/var/log/messages发现日志早就被挤得只剩最近几小时内容完全没法追溯。这就是典型只“看日志”不“设计日志”的后果。1.2 服务类日志和系统日志的区别服务类日志指由应用或业务服务自己产生的运行记录像Nginx的access.log、Tomcat的catalina.out、业务进程的stdout输出系统日志则是内核和systemd产生的messages、journal日志。两者必须分开处理。我见过不少团队把所有日志都交给rsyslog统一收结果应用日志还被按level打了不同标记自定义格式乱七八糟后来想用字段检索都没法做。正确的做法是分而治之类型典型来源特点策略侧重系统日志kernel, systemd, audit格式相对固定时间粒度细重点监控硬件、服务启停、崩溃、被kill服务日志nginx, mysql, java进程, 业务应用字段跟业务强相关量级波动大记录全量请求、告警错误、关键事务安全日志sshd, su, 登录认证敏感需要严格权限独立保存重点审计失败尝试不同日志分析手段也不同。系统日志看趋势和异常事件服务日志要结合业务链路串起来。我见过只会在messages里grep关键字的新人遇到业务报错就抓瞎——不是他们不努力是根本不知道日志还有源和应用之分。1.3 分析日志前必须先建立的三种“时间观”日志分析第一道坎不是技术是时间校准。很多服务容器内是UTC宿主机是北京时间数据库时区又设成东八区结果查一条报错前后差了8个小时方向完全搞反。我的习惯是所有服务器统一使用系统时区且启用时间同步chrony应用日志、容器日志统一格式为带时区的ISO8601字符串集中采集时在日志行附上接收端时间戳方便对比网络延迟。没有这个基础后面所有排序、串联、统计都是空中楼阁。我在排查一次“凌晨三点告警”时就因为容器内日志用UTC愣是误判了半小时业务高峰最后才发现其实对应的是北京时间早上八点整的流量高峰。2. 服务日志分析的整体思路与策略设计2.1 先建索引还是先画链路我的建议是先画链路刚接触日志分析的人喜欢上来就写一堆grep和正则试图把所有日志拉一遍。但这属于“撒网式排查”效率极低。我建议先画出服务依赖链路用户请求进来之后经过网关、认证、业务A、缓存、数据库这一步用了多少个组件每个组件在哪个日志文件里留痕。拿到这份清单后“日志分析”才有抓手按请求时间戳在各服务日志里找到同一个traceId或会话ID按调用顺序从上到下查看哪一段耗时异常或报错针对异常段进入对应服务详细日志定位到具体函数或者SQL。手工操作可以用grep、awk也可以用perl提取字段。如果能通过日志配置提前输出统一的trace_id那么分析效率直接翻倍。这一点值得在日志策略里强制规定所有跨服务调用的日志行必须打印traceId、请求路径、耗时、返回码。2.2 日志级别怎么设才不浪费空间又不丢关键信息日志级别大多数框架都分TRACE、DEBUG、INFO、WARN、ERROR、FATAL。但“线上开INFO测试开DEBUG”这句通用经验只能算入门真正要结合模块的重要性来定。我的策略清单里有几条原则核心交易链路INFO级别关键步骤必须打点外部依赖超时单独打WARN错误堆栈打ERROR。非核心功能比如用户偏好设置、推荐算法日志可以只记录WARN以上减少磁盘占用和IO压力。全局ERROR日志单独切文件不要混在stdout里方便告警和快速扫错。动态调整级别生产环境一般通过配置中心或发信号量改变日志级别遇到疑难问题临时打开指定类包的DEBUG排查完必须关闭。举个例子有一个支付回调服务平时info日志量大概每天8GB。后来把回调请求体、响应体全部下沉到debug级别只保留支付单号、状态、耗时等指标字段日志量降到每天2.3GB排障信息照样够用。2.3 日志轮转与保留策略宁可多留冷数据不可关键时刻没数据日志轮转不光是logrotate一个配置的事它牵扯到文件句柄、切割时机和时间跨度。首要注意很多应用进程启动后一直持有日志文件的文件句柄。如果你用logrotate切割日志但没告诉进程重新打开文件切割完成后进程还会继续往旧文件写。典型表现是磁盘不减反增或者原文件变成0字节但大小仍在增长。解决方式是通过copytruncate或者日志组件里配置daily maxBackup 自动reopen。我的推荐配置模板以logrotate为例/var/log/nginx/*.log { daily rotate 14 compress delaycompress missingok notifempty create 0640 nginx adm sharedscripts postrotate [ -f /var/run/nginx.pid ] kill -USR1 cat /var/run/nginx.pid endscript }这段配置说明每天切割保留14份压缩但延迟一天压缩为了给正在写入的日志留缓冲通过postrotate给nginx发信号让进程重新打开新文件。如果你用systemd的journald也要设置SystemMaxUse别让它无限吃内存盘。我们生产环境有个常见设定SystemMaxUse1GRuntimeMaxUse256M避免/run目录被撑爆journal永久日志再单独转storagepersistent并限制大小。2.4 日志格式规范没有统一的schema再强的工具也白搭很多日志分析困难根源不是工具而是日志格式随心所欲。比如有人打“2024-01-01 12:00:00,123 ERROR连接失败”有人打“01/Jan/2024:12:00:00 0800, failed”解析起来非常痛苦。我强烈建议凡新写服务必须遵守统一日志格式至少包含时间ISO8601或unix时间戳级别单一大写单词traceId/requestId必填线程名/模块名排障收敛范围用业务关键字比如订单号、用户ID消息内容不能带换行多行异常堆栈另做处理或序列化后单行输出来源文件:行号有最好。实际案例我们维持一个Java网关服务日志用logback pattern实现为: %d{yyyy-MM-dd HH:mm:ss.SSS} %-5level [%thread] [%X{traceId}] %logger{36} - %msg%n在Logstash或命令行工具里都能快速分组。你不一定需要复杂框架但至少在文件命名和字段分界符上要保持一致比如统一用|分隔字段比空格分隔更能容忍内容里的空白。3. 核心实操从日志采集到异常定位的全流程3.1 第一步确认服务日志在哪别犯“目录层级”的低级错误拿到一台陌生的服务器我第一步不是cat而是systemctl status 服务名看进程启动命令和WorkingDirectory再看它的标准输出重定向配置或用lsof -p 进程号 | grep log找出它实际打开的日志文件。很多新人以为服务日志一定在/var/log/xxx下其实docker容器默认把日志打到json-file里systemd服务默认写到journal里老一点的tomcat可能输出到logs/catalina.out。排障时别只看一个路径。我常用的一条命令组合# 找到进程实际打开的所有日志文件 ls -l /proc/$(pgrep -f 你的服务关键字 | head -1)/fd | grep log # 或者lsof更直观 lsof -p $(pgrep -f 你的服务关键字 | head -1) | grep -E \.log|json这里能看到进程当前写入的文件描述符。如果发现它写的文件已经被删除状态标记为deleted说明之前日志被移动或切割后进程没重新打开这个文件会在进程退出前一直占磁盘空间。这种情况非常常见也是日志策略里必须防的坑。3.2 第二步用journalctl与logrotate结合搭建本地日志查询环境journald收集系统和服务日志很方便查看时用journalctl。例如查看某个unit的全部日志journalctl -u nginx.service --since 2024-01-01 00:00:00 --until 2024-01-01 02:00:00筛选指定字段和级别journalctl -u app.service -p err journalctl -k -b -1 # 上一次启动的内核日志注意journald默认可能不持久化重启后历史日志会丢。在/etc/systemd/journald.conf里设Storagepersistent它会自动创建/var/log/journal目录。但我一般不建议把长期业务日志完全交给journald它对文本检索不如直接查文件方便更适合做短窗口快速查看。对于大日志文件logrotate会做好切割然后我们再用grep/awk查询。比如查Nginx某个时间段内5xx的分布zgrep 2024:11:0[1-9] /var/log/nginx/access.log.*.gz | awk $9 ~ /^5/ {print $4} | cut -d: -f1 | uniq -c这段的意思是在已压缩的日志文件中按时间过滤上午9点到下午6点匹配响应码500-599的请求按小时统计数量。可以快速判断5xx是偶发还是某个时间段的集中爆发。3.3 第三步手工日志分析的“三步定位法”如果公司没有上TKE日志服务临时排查故障时我习惯用“三步定位法”。第1步按时间线拉全链路时间线。比如同时登到网关、应用、数据库三台机器各自筛出某一时间段日志grep 2024-11-05T10:15:0 /var/log/app/order.log | grep order_889988把每条日志按时间排序找到“请求进入网关”-“鉴权通过”-“订单查询”-“扣库存超时”的位置。这一步的目的是确认卡在哪一跳。第2步按关键字统计异常比例。使用awk对错误码、耗时做聚合awk {print $7} access.log | sort | uniq -c | sort -rn | head -20这个统计能看到哪些接口被调用最多再结合耗时尾部指标(P99)确定异常接口。第3步下钻到单条请求的详细上下文。筛选traceId后把同ID的所有行按时间序排列grep traceIdabc123 /var/log/app/order.log | tail -100观察异常前后的变量和状态。每次排查我都建议把“关联ID 时间窗口 端到端耗时”打印在一张纸上或者思维导图里比纯靠眼睛在终端里翻效率高很多。3.4 第四步日志策略落地写一个可复用的shell分析脚本我为了让团队“人人都能查日志”通常会把常用分析动作封装成脚本。下面是一个压缩日志按时间范围错误级别统计的示例#!/bin/bash # 用途统计某个时间段内各错误码出现次数需传入日志文件和时间窗口 LOG_FILE$1 TIME_START$2 TIME_END$3 # 时间参数示例2024-11-05T00:00:00 到 2024-11-05T01:00:00 zgrep -h $TIME_START\|$TIME_END $LOG_FILE* 2/dev/null \ | awk -v ts$TIME_START -v te$TIME_END $0 ~ ts || $0 ~ te { print } \ | awk {for(i1;iNF;i) if($i ~ /(ERROR|WARN)/) {print $i}} \ | sort | uniq -c | sort -nr实际使用时更严谨的做法是按时间字段截取中间部分再比较字符串。说实话复杂分析不适合纯shell但这个脚本的价值在于低成本复用尤其在只有两三台机器、不想搭建ELK的团队很实用。如果你日志字段用竖线|分隔第二列是时间第三列是级别分析一行命令cut -d| -f2,3 /var/log/business.log | sed -n /2024-11-05 09:00/,/2024-11-05 10:00/p | awk -F| {cnt[$2]} END{for(k in cnt) print cnt[k],k}这种统一格式的好处体现得淋漓尽致不需要正则提取按分隔符处理就能完成大部分统计。4. 常见问题与排查技巧实录4.1 日志文件不写了被旋转进程没重新打开场景logrotate把app.log重命名为app.log.1但应用进程还在向app.log.1写入导致最新日志全跑到旧文件而你一直盯着新的app.log看什么都看不见。排查技巧# 检查进程文件描述符指向哪个文件 ls -l /proc/$(pgrep -f app | head -1)/fd | grep app.log # 如果显示 /var/log/app.log.1 (deleted)说明它一直在写旧文件解决办法给服务配logrotate的copytruncate选项或用kill -USR1方式让进程重新打开日志。对于java应用很多框架支持配置中定期重新打开比如Logback的prudent模式或自定义触发。我的一次真实经历是某消息队列消费者一直写日志监控看到磁盘缓慢增长手动删掉一个巨大的旧日志后磁盘空间竟然没释放一查正是进程持有旧文件句柄。后来必须重启应用才释放空间。所以检查deleted句柄应纳入日常巡检。4.2 日志时间对不上容器UTC宿主机应用时区各说各话现象应用日志记录凌晨1点异常数据库记录早上9点报错中间还有容器日志用UTC完全没法对照。故障复盘后定下的规矩宿主机统一修改为“Asia/Shanghai”容器内TZ环境变量统一设置并且/etc/localtime同步日志字段输出时强制带时区不要输出裸时间所有集中式日志平台ELK/Loki对接收时间做统一时区配置。排查小技巧看时间差可以用一句Python判断date -d 2024-11-05 08:00:00 %s date -d 2024-11-05T00:00:00Z %s如果两个时间戳相同说明一个是本地时间一个是UTC换算关系就清楚了。4.3 磁盘空间突然被日志占满误配DEBUG或循环输出最常见的是某个类库debug日志被打开包含循环打印的参数体一晚上日志就几十GB。排查技巧是查看大文件排行du -ah /var/log | sort -rh | head -10 journalctl --disk-usage如果发现是某个unit日志疯狂写入先动态调整级别很多框架支持运行时改级别再清理历史journalctl --vacuum-size500M不推荐直接rm日志文件最好让进程正常轮转。对于JVM应用如果STDOUT没被重定向systemd会把大量stdout内容存到journal也可能导致/var/log/journal体积暴涨。这种情况是在Service配置里加StandardOutputnull或StandardOutputappend:/var/log/app_stdout.log避免journald无限增长。4.4 关键字搜不到日志级别过滤掉了真正错误有时业务明明异常但日志里搜不到“ERROR”。原因大多是错误被框架捕获又只打了WARN或者异常信息里根本没包含你搜的关键词。排查思路是先看服务状态和调用结果码再看框架层日志级别配置。例如Java Spring Boot的logback默认打印controller层异常为ERROR但某些hystrix熔断日志是WARN你搜ERROR自然漏掉。这时候要用更宽的条件grep -E ERROR|WARN|Exception|Timeout|CircuitBreaker app.log另一个常见情况界面报错日志里只有一个UUID引用具体堆栈在另一个异步线程里。这种情况必须通过traceId或者requestId串联。所以我在日志策略里强制“每一次请求进来第一行必须打印traceId”后面的所有日志都带上它。有次客服反馈“订单提交失败”我就在网关日志里搜这个traceId发现业务A调业务B超时业务B其实没收到而是A内部自己把请求吞了最后超时返回。这个根因如果没有traceId串联只能靠猜。4.5 常见问题速查表现象可能原因排查命令/动作解决方向查日志最新内容还是一小时前进程还在写旧文件deleted句柄ls -l /proc/PID/fdlogrotate增加copytruncate或进程重新打开日志日志时间与当前不符时区或时钟漂移timedatectl status启用chrony设置统一时区journald占用几个GBSystemMaxUse未限制journalctl --disk-usage设置SystemMaxUse减少保留量应用日志中有大量“???”或乱码日志编码不一致file 日志文件统一UTF-8容器内语言环境设为C.UTF-8某个grep没有结果日志级别过滤或关键字太严grep -iE “errexception日志文件权限变成root且应用无法写轮转后属主变化ls -l /var/log/*.loglogrotate create 参数指定正确属主容器中nohup.out越来越大容器内程序直接追加输出du -sh nohup.out改配置让日志按天滚动限制stdout重定向这张表基本涵盖了团队里新手最常见的踩坑点。日志问题其实比代码逻辑问题更讲“现场保护”在没搞清句柄和轮转之前别急着删文件否则可能破坏排障现场。5. 日志分析与策略的进阶自动化告警与集中式检索思路5.1 手工分析之上的“三分钟告警”机制日志分析的最高境界不是出事时快速查日志而是在出事之前就收到准确告警并且告警信息里直接给出线索。我建议至少做三个自动化告警错误率告警统计5xx或ERROR数量在5分钟内超过阈值延迟告警统计请求P99超过500ms后触发服务存活告警心跳日志连续N分钟没有更新。不需要一开始就上复杂系统用shellcron也能实现基础版。例如每分钟扫一次日志文件里最近5分钟错误计数#!/bin/bash # 检测最近5分钟ERROR数量超过20则告警 LOG/var/log/app/error.log CNT$(tail -500 $LOG | awk -v now$(date %Y-%m-%d %H:%M:%S) { # 其实比较时间复杂这里简化为直接数ERROR if ($0 ~ /ERROR/) c } END {print c0}) if [ $CNT -gt 20 ]; then echo app error count $CNT in last lines | mail -s App Error Alert opsexample.com fi注意上面示例用了简单方式生产环境如果日志量大应该用带checkpoint的方式增量读取或用现成的filebeat收集后到Kafka/ES里做告警。但核心不是工具而是把指标定义清楚。5.2 集中式日志该不该上什么时候上我常被问到“几台服务器需要搭建ELK吗”。我的建议三台以下各机器本地logrotategrep完全够用超过十台或者需要跨机器串traceId、做长期趋势分析时就该上集中式方案。集中式方案常见组合EFK/ELKFilebeat采集Logstash或Kafka缓冲Elasticsearch存储Kibana展示。适合需要复杂检索和聚合的场景。LokiGrafana轻量适合以日志内容索引为主不适合大规模全文检索但部署和资源占用少。ClickHouse向量日志适合超大规模配合业务字段存储。无论选哪一种统一日志格式都是前提。否则采集端就算解析成功字段缺失也会让后续分析失去意义。我近几年比较偏爱“采集侧先用轻量脚本做结构化再入检索系统”的思路。比如Filebeat的dissect或grok可以先把一行日志拆出时间、级别、traceId、路径、状态码后面的聚合查询才可视化。举个例子在Kibana里想查“某接口P99耗时”如果日志里没有单独的耗时字段就只能用KQL全文搜不够方便。所以在服务端打印时就把cost123ms这种字段带出来采集端自动映射成cost字段这样才能实现真正的量化分析。5.3 安全与审计日志的策略该留的必须留够该抹的别留神服务类日志不仅用于定位故障还需要支持安全审计。比如SSH登录日志、sudo记录、配置变更记录这类日志即使平时没有故障也要长期保存。对于这类日志我的策略是单独目录权限设为600或640只有root和审计组可读异地同步一份防止本机磁盘被清理后无法回溯监控“多次认证失败”“非工作时间sudo”等异常行为。一条快速扫描暴力破解的命令grep Failed password /var/log/secure | awk {print $(NF-3)} | sort | uniq -c | sort -nr | head -10这能统计攻击来源IP。但更重要的不是事后统计而是事前用fail2ban类工具自动拉黑。日志分析如果只用于“事后查案”价值就打折了一半。正确姿势是区分“排障日志”和“安全审计日志”审计日志单独设置保留周期不能执行logrotate的7天清理。5.4 回顾一个完整的日志策略案例我用一个虚拟的订单服务场景把前面原则串起来。场景有三台业务服务器加一台数据库服务器每天订单量约10万预计单机日志5GB。设计流程业务日志路径/data/logs/order/order.log内容切分为时间|级别|traceId|接口|耗时|状态|业务ID|信息统一UTF-8输出级别INFO级别只打关键节点参数体统一DEBUG全局ERROR独立到error.log轮转每天切割保留30天压缩delaycompress进程通过USR2信号重新打开日志磁盘预留每台机器预留日志磁盘100GB按30天算150GB压缩后可压到30-50GB预留一倍缓冲告警每5分钟统计ERROR数量超过30报警P99耗时超过800ms报警错误码5xx比例超过5%报警。这套方案在一台4核8G的机器上日志服务本身占用CPU在2%以内算是非常轻量。到了10台以上再考虑加Filebeat采集到集中式平台。6. 日志分析策略里那些没人写但很重要的习惯6.1 看完日志必须清掉可能泄露信息的敏感内容日志里偶尔会有密码、token、手机号等敏感信息。我踩过坑调试时把http请求头全部打印到debug结果日志轮转压缩后还长期躺在磁盘上安全审计差点出问题。日志策略上必须加“脱敏”环节日志框架里对密码、身份证、token字段执行掩码处理线上日志禁止打印Authorization头日志文件权限不能让普通用户可读特别是包含用户信息时。虽然这不是分析本身但日志分析能走多远取决于日志是否合规可存。敏感信息不清存储和采集本身就是风险这个习惯值得从一开始就养成。6.2 日志分析不只是“出现问题才打开”日常巡检也是分析的一部分我要求团队每周做一次轻量日志巡检看ERROR趋势、慢接口Top10、磁盘占用趋势、错误日志关键字分布。不必写复杂报表一条命令就能完成# 统计今天各小时错误数 grep $(date %F) /var/log/app/error.log | cut -d| -f2 | cut -d: -f1 | uniq -c正常系统错误分布往往有规律凌晨低谷、白天平稳、发版时短暂上升。如果某天某个小时突然从0跳到上百不用等用户投诉告警就会提醒你。这个日常巡检的价值是建立“正常基线”没有基线告警阈值拍脑袋要么天天误报要么失效。6.3 日志分析是一个需要持续迭代的“产品”不是一次性配置这几年我发现日志策略必须像软件一样持续维护每次故障复盘后要问三个问题这次回看日志哪些关键信息当时没记录哪些日志字段格式不利于快速检索告警阈值是否合理是否需要调整有次我们定位一个网络抖动故障发现业务日志里根本没记录“发送请求时的socket连接耗时”只能靠猜测。后来在HTTP客户端层加上连接建立耗时和响应耗时的分离埋点两周后就捕捉到一次网络设备异常导致的连接创建耗时飙升。没有这次日志字段迭代问题可能要到用户投诉才能发现。还有一次我们调整了保留周期从15天变到45天起因是某个只在周末出现的故障15天后查不到前一天的数据拉长了观察窗口后才看到周期性规律。这些都是“日志策略迭代”的典型场景。6.4 工具推荐和取舍grep、awk、rg、lnav哪个更适合日常日常手工分析我用这几个工具grep最基础适合小文件快速搜索rgripgrep多文件大目录搜索速度远超grep且默认支持正则适合日志分析我几乎在每个服务器上都装了awk按字段统计、过滤的瑞士军刀lnav可以在终端里像看自动化工具一样展示日志支持按时间排序和语法高亮对日志文件比较友好jq如果日志是JSON格式直接管道处理非常方便。举个例子用rg快速找出最近五分钟的错误消息rg 2024-11-05T0[89]: /data/logs/app/*.log | rg ERROR | head -50如果日志超大量建议先zcat解压后的rg。压缩日志可以先zgrep或者rg --text。工具不必贪多掌握grep awk rg解决90%的临时分析需求就够。正式点说我总跟团队讲“能用键盘加管道完成的日志分析就别引入一堆云产品”因为轻量手段在故障时的可用性和速度常常是最高的。这个系列后续会写的方向第一篇先到这里。关于日志分析后面我准备继续聊这几个话题常见服务Nginx、MySQL、Redis、Kafka的日志指标解读容器环境下的日志采集和策略基于日志的故障定界方法论大规模日志平台选型与调优。如果你在日志分析遇到什么“查不出来”的案例欢迎一起探讨。我自己始终有个观点日志策略做得好的系统故障恢复时间至少能缩短一半而优秀日志策略的核心不是工具而是对业务和系统依赖理解的深度。