做Linux运维和架构这二十年我见过太多线上事故的复盘会十次有八次最后都会落到一句话上“日志就在那儿就是我们没看明白。”日志分析这事儿听起来谁都会实际上大多数人停留在会敲几个命令的层面离“分析”两个字差得远。这系列文章我打算用二十年的实战经验把Linux服务类日志分析和策略这件事从底层原理讲到落地套路。今天这篇001先把全局框架和最重要的基础策略讲清楚适合刚接触服务端日志的运维、后端开发也适合带团队的人拿来当内部培训的底稿。1. 服务类日志分析先搞清楚你要面对的是什么服务类日志说白了就是所有跑在Linux上的服务进程产生的文本记录。这个范围看起来很宽实际分析的时候你必须先分类因为不同类型日志的分析方式和策略完全不同。1.1 服务类日志的四大来源第一类系统层日志。主要由systemd的journald统一采集同时也会落到/var/log/messages、/var/log/syslog这些传统文件里。内核的环形缓冲输出在dmesg里硬件故障、驱动报错、OOM Killer的信息都在这里面。这类日志的特点是杂、量大、格式不统一但排查系统级问题的时候绕不开。第二类应用服务日志。Nginx的access.log和error.logMySQL的慢查询日志和错误日志Java应用通过log4j2或者logback输出的业务日志Python应用用logging模块产生的运行日志这些都算。这类日志是整个分析工作的主战场因为绝大多数业务问题都藏在应用日志里。第三类中间件和基础设施日志。Kafka的server.logRedis的logfileElasticsearch的cluster.log这些中间件自身产生的日志往往能告诉你集群健康状况、主从切换、磁盘水位、GC停顿这些信息。这类日志的特点是包含大量的时序信息最适合做趋势分析。第四类安全与审计日志。/var/log/secure记录登录行为/var/log/btmp记录失败的登录尝试lastlog记录所有用户最近登录时间。这类日志平时没人看一旦出事它就是唯一的线索。为什么要把来源分这么清楚因为分析策略必须跟着来源走。比如系统层的日志重点是异常关键字扫描应用层的日志重点是业务指标的提取和行为链路还原安全日志重点是非白名单行为告警。一套grep走天下的那种思路在真实生产环境里撑不了多久。1.2 日志分析的三层目标我在带团队的时候习惯把日志分析的目标分成三层。第一层是故障定位也就是服务挂了、接口超时、CPU飙高的时候能通过日志快速锁定问题点。这一层考验的是“检索能力”也就是你手速够不够快命令用得够不够熟。第二层是性能与容量评估。服务没挂但响应时间在慢慢变长磁盘在一点点被占满这种慢性病最可怕。这层需要的是“统计能力”你要从海量日志里提炼出趋势数据比如错误率的变化曲线、P99耗时的走向、请求量的波峰时段。第三层是安全与合规审计。日志是发生过的行为的唯一可信记录谁在什么时候登录过系统哪个API在什么时间被异常调用这些都得从日志里还原出来。这层需要的是“关联能力”通常要把系统日志、应用日志、网络日志串起来看。这三层目标决定了你的策略设计。如果团队只是停留在“能用grep搜出来”的阶段那日志分析的基础设施建设比如采集、归档、索引、告警这些基本都还没着落。这也是我这系列文章要解决的核心问题。2. 动手分析之前日志本身先要管好很多人拿到日志就开始grep我从来不这么干。日志分析的第一步是先检查日志本身的状态。日志文件如果没管好你分析出来的所有结论都是错的。我把这个阶段叫“日志治理”它比分析本身重要得多。2.1 logrotate日志轮转不是可有可无的配置运维过生产环境的都知道服务日志如果不做轮转一个文件能写到几十个GB到时候别说分析连打开都费劲。Linux系统自带的logrotate就是干这个的。但默认配置通常只覆盖系统日志应用服务日志必须你自己手动加策略。我贴一份我常用的轮转配置直接加到/etc/logrotate.d/下面每个服务一个文件/var/log/nginx/*.log { daily rotate 30 compress delaycompress missingok notifempty dateext create 0640 nginx adm sharedscripts postrotate if [ -f /var/run/nginx.pid ]; then kill -USR1 cat /var/run/nginx.pid fi endscript }说下设计思路。daily表示每天切一次rotate 30表示保留30份也就是一个月的日志量。compress开启压缩delaycompress是延迟压缩意思是昨天切出来的那个文件先不压因为可能还有进程没写完今天再压避免丢日志。dateext很关键日志文件名会带上日期方便按天回溯。postrotate这个脚本是重点。Nginx日志文件被rename之后Nginx还是会往原来的inode写所以必须发USR1信号让它重新打开日志文件。Java应用和Python应用处理的思路类似但方式不同Java通常用log4j2的RollingFile自己管轮转系统层的logrotate只需要处理stdout重定向出来的文件。这里最容易踩的坑就是配置了轮转但忘记配postrotate信号导致日志文件一直在往被rename的旧文件里写你分析到的全是断档数据。轮转周期怎么选流量小的服务可以weekly流量大的一天切两次甚至按小时切。没有绝对正确的答案但我建议宁可切得勤一点也不要让单个日志文件超过1GB。超过这个体量用命令行分析的时候每一次扫描都是几秒钟起步效率低到让人崩溃。2.2 时间同步与日志格式规范日志分析最怕的就是时间错乱。多台服务器NTP没做好A机器凌晨2点报了错B机器的日志时间戳是1点50你在聚合分析的时候怎么都对不上。所以在策略层面第一优先级是全网NTP同步这个没有商量的余地。第二个规范是日志格式。我强烈建议应用日志统一输出为JSON格式。为什么因为JSON格式天然带字段用jq之类的工具解析非常方便后续接入ELK这类集中式日志平台也不需要做复杂的格式转换。反观那种自由文本日志比如“2024-01-15 10:00:01 ERROR user login failed”看着是挺清晰但真要统计、过滤、聚合的时候每一步都得靠正则硬抠维护成本极高。举个例子同样是记录一次登录失败文本格式和JSON格式的差别是这样的2024-01-15 10:00:01 ERROR login failed. usernamezhangsan, ip10.0.0.8, retry3{timestamp: 2024-01-15 10:00:01, level: ERROR, event: login_failed, username: zhangsan, ip: 10.0.0.8, retry: 3}前者你要统计某个用户连续失败次数就得写正则去匹配username字段后者直接jq一条命令就完成了。这个看起来是小改造实际对后续所有分析策略的影响是全局性的。3. 核心分析手段命令行工具的实战姿势日志治理做完才轮到真正的分析环节。我不会在这篇里铺开讲ELK这种重平台因为那是后面的内容。这篇先把命令行分析这套基本功讲透它适用于任何没有部署集中日志平台的场景也是所有复杂分析能力的底座。grep、awk、sort、uniq、wc这五个命令玩熟练了百分之八十的日常分析任务都能搞定很多人不信我直接上实战。3.1 grep、awk、sort组合三板斧打天下先用一个最经典的场景来演示。假设我要分析Nginx的access.log找出最近一天请求次数最多的十个来源IP看看有没有攻击行为。我只需要一行命令grep 15/Jan/2024 /var/log/nginx/access.log | awk {print $1} | sort | uniq -c | sort -rn | head -20这段命令的每一环都有明确的目的。grep先把当天的请求从整个文件里筛出来因为access.log默认的日志格式里日期字段在$4的位置但用grep过滤比用awk匹配来得快这是性能上的考虑。awk {print $1}取第一列Nginx默认格式第一列就是客户端IP。sort排序是为了让uniq -c能正确统计相邻重复行的数量这里是很多新手容易忽略的一步sort必须放在uniq前面。最后sort -rn按统计数量倒序排head -20取前二十。这个组合拳能解决一大类问题TOP N统计。统计访问最多的URL把$1换成$7就行。统计哪个状态码出现最多把$1换成$9。统计哪个时间段请求量最高把$1换成$4截断小时字段。再进一步如果想知道这二十个高请求IP背后的UA特征可以用awk拼接起来看grep 15/Jan/2024 /var/log/nginx/access.log | awk {print $1, $12} | sort | uniq -c | sort -rn | head -20正常运行的服务排除掉搜索引擎的爬虫剩下那些请求量异常高但UA很奇怪的IP基本就能判定是扫描或者攻击尝试了。这个分析过程总共只要几秒钟但如果你没有一个结构化的分析思路就算给你同样的命令你也想不到要这么组合。3.2 从日志中提炼业务指标命令会敲了接下来要说的是怎么把日志变成指标。这是分析和“看日志”的分水岭。讲一个我实际处理过的场景。有一次业务方反馈接口在下午出现大量超时但服务没重启过CPU也不高。我直接写了下面这个组合统计超时请求的时间分布grep timeout /var/log/app/app.log | awk {print $2} | cut -c1-5 | sort | uniq -c$2是时间字段的话cut -c1-5取的是“小时:分钟”这个维度输出结果直接就能看出超时集中在哪个时段。那次分析发现16:00到17:00之间超时数异常膨胀对应到业务上正好是数据团队每天下午跑批任务的时间段两个服务争抢数据库连接资源问题就这么定位了。再比如接口耗时分析。如果你的应用日志里有耗时字段比如“cost235ms”这种文本可以先提取数值再做区间分布grep cost /var/log/app/app.log | sed -n s/.*cost\([0-9]*\)ms.*/\1/p | awk {if($1100) a; else if($1300) b; else c} END {print lt100:, a, 100-300:, b, gt300:, c}这里用sed把耗时数值抽出来再用awk做区间累加。结果是三个数字一眼就能看出大致的耗时分布。这种分析的价值在于它不需要任何监控系统就凭一份日志你就能给接口性能画一个粗略的画像。虽然不够精细但用来临时应急和初筛完全够用。3.3 故障现场快速定位的套路接下来是很多人最关心的部分服务出问题了怎么在最短时间内从日志里找到线索。我有一套固定的流程这套流程在无数次故障处理中验证过效率非常高。第一步确认时间窗口。先看故障现象出现在什么时间然后在这个时间窗口的前后五分钟开始检索。比如用户在10:02反馈服务不可用那就从09:57的日志开始看因为问题往往是渐进式的前面几分钟可能已经有异常信号了。第二步按严重级别过滤。Java应用日志里搜ERROR和ExceptionPython搜TracebackNginx搜5xx状态码。先用大网捞一遍看异常的大致分布不要上来就盯着某一条日志看那是盲人摸象。第三步抽取上下文。找到疑似异常点之后用grep -A和-B参数把前后几十行一起看grep -A 30 -B 10 OutOfMemoryError /var/log/app/app.log | tail -100看异常发生前后的调用链确认是独立事件还是连锁反应。很多新手在这里犯的错误是看到ERROR就以为找到了根因其实ERROR只是结果前面的连接池耗尽、超时重试这些才是原因。上下文比单条日志重要得多。第四步交叉关联。如果故障同时出现在多台机器上把各机器同一时间窗口的日志拉下来对比。手工对比可以用diff加时间截取效率不高但能解决问题。这个是后面讲集中式日志平台时的核心场景但即使没有平台这个思路也必须建立起来。这套流程最大的价值是“套路化”也就是在面对海量日志的时候不慌不忙知道自己的下一步是什么。我把这套流程整理成了故障排查速查表在后面第4节详细列出来你可以直接打印出来贴在工位上。4. 日志分析中的典型坑与排查技巧这一节的内容是我这些年踩坑踩出来的每条背后都对应一次真实的线上事故。我把它们整理成问题清单的形式每条都附上排查思路和解决手段。这些内容常规文档里基本看不到但生产环境里天天都在发生。4.1 时间不同步与时区混乱第一个坑就是时间问题。线上环境多台机器NTP配置没生效某台机器的时间比标准时间慢了两分钟。表面上看没什么但一旦做日志聚合分析错误的时间戳会把正常的时序彻底打乱。有一次我排查一个支付回调延迟的问题A地机器显示回调在10:00到达B地机器显示收到请求在09:58怎么算时间都对不上最后查下来就是B地机器本地时间慢了。解决办法分成两步。第一步全机房统一配置NTP并且监控时钟偏移量。Linux下可以用timedatectl查看也可以用ntpq -p查看同步状态。第二步应用日志统一输出UTC时间或者带上时区偏移量。比如ISO8601格式就是带时区的2024-01-15T10:00:0008:00这种比不带时区的2024-01-15 10:00:00严谨得多因为后者在不同时区的机器上同一时刻记录的时间字面值不一样后续解析必然出问题。另外还有个细节系统重启后硬件时钟漂移很多服务器主板上电后从RTC读的时间不对但NTP又没来得及同步。这时候日志上会有几条时间戳明显不正常。我的习惯是每次做重大变更之前先跑一遍date命令确认时钟准确这个动作不值钱但能省下后面无数排查时间。4.2 日志轮转导致的数据断档第二个坑非常隐蔽就是日志轮转和分析任务之间的竞争。日志文件每天凌晨被logrotate重命名但如果分析任务恰好在这个时间点读取旧文件读到的可能是不完整的数据。更麻烦的是有些分析脚本用tail -f模式读日志轮转之后tail仍然盯住旧文件的inode新写入的内容根本读不到。我的解决方案是做三件事。一是给logrotate加delaycompress这个前面提到过确保轮转后旧文件还能完整写到第二天避免正在执行的进程还没落盘就被压缩。二是在分析任务前面加一个延迟比如凌晨4点再跑当天的统计任务这样凌晨0点轮转过来的文件已经完整落地了。三是如果一定要做近乎实时的分析那日志采集这层就要用上类似supervisord托管的方式重启应用进程或者使用应用框架自带的日志重载机制这个后面单独写。轮转策略本身也有讲究。rotate份数和磁盘容量要匹配我见过一个团队把rotate设成365一年日志全留着结果磁盘被撑爆。日志压缩率一般在10比1左右也就是说10GB原始日志压完大约1GB你按这个比例估算磁盘占用再反推rotate份数。比如服务器分配10GB给日志目录日增原始日志500MB保留30天就是15GB原始压缩后约1.5GB这是合理的。如果改成保留90天压缩后约4.5GB也还能接受。4.3 编码与特殊字符处理第三个坑是编码问题。大多数Linux服务器的日志默认是UTF-8编码但总有一些历史包袱比如老业务用GBK输出日志或者在日志里写了奇怪的转义字符。用grep搜索中文关键词的时候如果终端编码和文件编码不一致结果就是你什么都搜不到但数据明明就在那里。排查方法很简单用file命令看日志编码file /var/log/app/app.log如果是ISO-8859或者GB2312先转码再分析。用iconv转成UTF-8或者直接在grep的时候用iconv处理流iconv -f GBK -t UTF-8 /var/log/app/app.log | grep 关键字另外还有一个经验日志里带有回车、退格这类控制字符会让终端输出乱七八糟分析的时候趁早过滤掉。可以先用cat -A看一下文件里有没有特殊字符再用tr删除控制字符。这些细节平时不起眼但关键时刻能节省大量时间。还有个我踩过的坑是日志文件里的极长行。正常的日志一行几百字符但堆栈信息能把一行拉到几万字符。用awk处理这种超长行容易触发工具本身的限制出现莫名其妙的结果。遇到这种情况先用fold把长行分解或者用awk的substr截断后再处理。4.4 文件句柄与日志丢失第四个坑发生在应用进程本身。有些Java应用用了log4j2异步日志应用还在运行但日志文件已经没了或者大小一直不涨。这种情况通常是logrotate轮转时进程持有的文件句柄还指向旧文件或者应用的日志配置里maxFileSize和maxBackupIndex设置不当滚动出来的日志被应用自己删掉了。排查思路分三条线。第一条用lsof检查进程打开的文件句柄确认是否指向已被rename的文件lsof -p PID | grep app.log第二条查看日志目录下的文件数量和时间戳如果发现当天的日志文件不存在而旧文件还在增长基本就是轮转后信号没发对。第三条检查应用自身的日志配置Java的log4j2通常自己管理轮转系统层的logrotate要排除掉这些文件否则两边同时轮转会互相打架。Nginx和Java应用这两类是我见过日志策略冲突最多的地方。日志丢失的问题最难排查因为数据没了就是没了不会有任何报错。所以我的经验是预防大于补救日志文件权限、属主、所在目录的空间都要纳入监控关键日志要有多副本至少保证一份在本地一份通过日志采集代理送到集中存储。这个集中存储的策略我在后面的篇章里会专门展开讲。5. 策略设计让日志分析从“救火”变成“防火”前面讲了这么多具体操作现在把视角拉高一点说说策略层面的东西。20年的架构经验告诉我日志分析如果只停留在“出事的时候能查出来”那这个团队的运维能力就是不及格的。真正成熟的体系是要有一整套预定义的策略让分析工作从被动救火转向主动防火。这节内容偏方法论但都是可以落地的。5.1 三级分析策略日常巡检、故障响应、深度审计我习惯把日志分析策略分成三个等级对应不同的频率、深度和工具要求。第一级日常巡检策略。每天固定时间跑一遍标准化的统计分析检查错误日志数量是否有异常波动请求量是否有断崖关键接口的耗时分布是否在合理区间磁盘空间是否在预期范围内。这一级的工具不需要多复杂crontab加Shell脚本就能实现。但关键是脚本的标准化所有巡检项的输出格式要统一方便每天对比。第二级故障响应策略。这套流程是预演过的不是临时想出来的。具体包括故障触发条件是什么比如错误率超过阈值、请求量骤降、某个进程消失、第一步查什么、第二步查什么、需要在多长时间内给出初步结论。我前面第3节讲的那套定位流程就是故障响应策略的核心。这个策略一定要写成文档而且要定期用故障演练来验证不然等到真出事的时候团队还是乱的。第三级深度审计策略。这个频率低但工作时长长。通常是在重大版本发布后、安全事件发生后或者是季度复盘时对某一阶段的全部日志做一次全面审计。这时候命令行已经不够用了需要把日志导出到分析平台用SQL或者专门的查询语言做复杂的关联查询。这一级的内容我计划在后面的篇幅里单独开一篇讲。三级策略的关系是层层递进的。日常巡检发现问题触发故障响应故障响应解决完之后再判断是否需要进入深度审计。没有一个固定的制度把这三级串起来日志分析就永远是一盘散沙。5.2 告警策略阈值与收敛是核心矛盾有了分析策略还需要配套的告警策略否则日志分析的结果只停留在纸面上。这里最容易犯的错误是“阈值拍脑袋”。比如日志里ERROR出现了5次就告警结果业务正常波动就有10次告警被人为忽略最终变成狼来了。我设计告警阈值的方法是先跑两周到一个月的历史日志做基线统计。算出正常时段的错误量均值、P95、P99。然后以P99的1.5倍到2倍作为告警阈值并且加时间窗口。比如“连续十分钟内错误数超过100条”才告警而不是“出现一条就告警”。窗口的好处是过滤掉瞬时抖动保留真正需要关注的问题。告警收敛也是必须做的。同一类错误在短时间内可能触发几十条告警这没有意义。我的做法是同一个告警规则在15分钟内只发送一次合并通知并带上事件次数和样本日志。这项工作在命令行层面可以用简单的计数脚本实现在集中式日志平台里面是内置能力。这里还要说一个比较容易被忽视的点告警不只是给运维看的。关键业务的日志告警要同步发给对应的开发负责人API的错误率告警要发给网关团队安全日志的异常登录告警要发给安全负责人。角色不同关注的日志类型不同告警路由本质上是按责任边界设计的。5.3 工具选型策略从命令行到集中式平台的演进路径工具选型这个问题很多团队会陷入两个极端。一个是“we can do everything with grep”另一个是“必须先上ELK再说”。这两个极端我都走过我的建议是分阶段演进。第一阶段单机日志量在每天几个GB以内团队规模小于十个人这个阶段直接用命令行工具就够了。前面讲的grep、awk、sort这套组合已经能覆盖绝大部分需求配合crontab做定时统计投入成本接近零。这时候如果强行上ELK光维护Elasticsearch集群就能把一个三人运维团队拖垮。第二阶段日志量上来了或者多个团队都需要查日志这个时候引入集中式日志平台。工具上轻量方案用Loki加Promtail重量方案用ELK。选择的标准不只看规模更要看团队能力。有专职运维且日志查询需求复杂选ELK没有运维投入纯开发团队自用选Loki这类更轻的。SaaS类的日志服务也可以考虑前提是数据安全合规能满足。第三阶段日志分析系统化。通过统一的采集代理把日志、指标、链路追踪三种数据打通。这个阶段分析策略基本自动化日常巡检和告警不再依赖人去执行脚本。这已经是可观测性的范畴了是日志分析这条路的终点站。我特别想强调一点不管工具怎么演进前面讲的命令行基本功都是不过时的。我在ELK平台上排查问题很多时候第一判断还是用命令行直接跑原始日志因为索引里的数据有可能存在字段映射误差原始日志才最可信。工具可以换兜底能力不能丢。6. 写在最后给同行的一点建议写到这里001篇的主要内容基本讲完了。按照我自己的习惯每篇结尾都会留一点私货。我这些年带团队见过太多的分析师可以熟练地敲出复杂的查询语句却搞不清楚日志的轮转策略看不懂时间戳的时区含义。日志分析的天花板从来不在工具而在对日志本身的理解深度。所以我强烈建议读完这篇之后先别急着学更多高阶命令而是回你的服务器上把你负责的服务的日志目录、轮转配置、时间同步状态认认真真检查一遍。这些基础的事情做好了后面我再慢慢展开讲日志平台建设、检索语法优化、告警规则设计这些进阶话题的时候你才能接得住。下一篇我准备写“日志检索语法的十个黄金技巧”都是可以直接套用的实战经验到时候见。