干这行时间长了你会发现一个反常识的现象真正让线上系统出问题的往往不是业务代码本身的逻辑错误而是那些你当时觉得“多写一行保险”的日志。日志不是越多越好这句话我是在踩了无数次坑之后才真正理解的。开发阶段日志能帮你定位问题但如果从一开始就没规划好日志级别、输出内容和存储策略等日志量上来之后它反而会成为线上故障的帮凶——拖垮性能、打爆磁盘、淹没真正的异常。这篇文章围绕日志的定位、开发优化手段、常见坑和线上排查命令四块展开把我这些年积累的经验和教训一次性说清楚。1. 想清楚日志是给谁看的再决定怎么写1.1 日志的本质是行为回放不是流水账日志本质上是一份“系统行为的可回放记录”它的价值在于能够回答三个问题系统发生了什么、为什么发生、影响范围有多大。很多人写日志时只想着“这里打一行方便调试”却没有想过这行日志在生产环境会被谁看、以什么形式看、能帮助他做出什么判断。我在处理线上故障时最怕的情况就是日志库里几十个G的文件error级别的信息也刷了几千条但真正要找的那次请求上下文却完全没有记录。比如业务层吞掉了异常只打印了一行“操作失败”没有订单号、没有用户ID、没有堆栈——这种日志写了等于没写。从使用场景来看日志的读者至少有四类开发人员定位bug、运维人员监控健康状态、安全人员做审计追踪、数据分析人员统计业务行为。不同读者对日志的需求完全不同开发要细节运维要指标安全要留痕分析要结构化。在写日志之前先问自己一句这行日志是给谁看的他要从中获取什么信息如果能回答清楚日志的格式和粒度自然就清晰了。1.2 日志量的三层隐性成本很多人只盯着磁盘占用看日志成本实际上日志量过大带来的问题远不止存储费用那么简单我一般把它拆成三层来看。第一层是存储成本。日志是需要保留的少则一周多则一年甚至更久。以每天100GB日志量来计算保留30天就是3TB再加上副本和归档成本很可观。很多公司日志存储的账单比服务器本身还贵这就是日志失控的直接代价。第二层是性能损耗。同步写日志时每条日志都要经过格式化、锁竞争、系统调用、磁盘写入这一整套流程高并发下非常容易成为瓶颈。我见过一个业务高峰期接口RT响应时间从50毫秒飘到3秒的案例查到最后就是日志中间件的同步刷盘把线程全部卡住了后面会详细展开。第三层是检索效率。日志量越大排查问题越慢。没有索引的原始日志文件到了几十个GB之后grep一次就要几分钟即使上了ELK或Loki这类日志平台海量噪音日志也会让真正的异常被淹没relevance排序出来的结果全是无效信息。日志过多的终极代价不是钱而是故障发生时你找不到问题的时间。1.3 什么才算“适量日志”判断日志合不合理我的经验是拿“排障还原度”来衡量如果线上某台机器挂掉了你能不能用已有日志完完整整地还原出这个实例生命周期的最后几分钟包括收到了什么请求、处理了什么流程、在哪个环节出错、资源状态如何能满足这条标准的日志就是适量日志满足不了就说明日志要么不够、要么太杂。可观测性领域常说的三大支柱——logs、metrics、traces日志在其中只负责“发生了什么”的部分不需要大包大揽。指标类数据应该走监控系统链路信息应该走分布式追踪日志不要想着什么都记专注记录关键事件和异常现场就够了。2. 开发阶段的日志优化把控制点放在源头2.1 日志级别划分与动态调整机制日志级别是最基础也最容易被忽视的优化手段。DEBUG记录详细调试信息INFO记录业务关键节点WARN记录可恢复的异常或值得关注的情况ERROR记录需要人工介入的错误。很多团队在开发调试时全程用INFO输出细节上线又懒得改结果就是生产环境到处都是细碎的INFO日志。我在实际项目中习惯定的标准是INFO只记录跨系统的关键调用、核心状态变更和业务流程的入口出口DEBUG才记录方法内部的计算过程、临时变量和分支走向WARN面向“这次能过但值得注意”的场景比如重试成功、缓存穿透、慢查询已超阈值ERROR严格限定为“影响本次请求结果且需要排查”的问题。业务异常如果已经被catch并正常处理了一般打在WARN而不是ERROR否则线上错误告警会被刷成“狼来了”。更重要的机制是动态日志级别调整。生产环境不可能预知所有场景有时需要临时打开DEBUG排查问题又不能重启应用。基于Logback的配置中心动态设置、Spring Boot Actuator暴露的logger端点都支持运行时调整日志级别。我通常的做法是在审批可控的前提下对单个类或单个包临时降级到DEBUG问题定位完立刻恢复这样既不影响业务又能拿到想要的现场信息。2.2 结构化日志才能被机器高效处理文本日志人眼看着方便但规模大了以后机器处理才是主要方式。非结构化的日志到了ELK里解析全靠正则硬抠字段一多就出问题性能和准确率双双下降。真正适合生产环境的做法是输出结构化日志最常见的是JSON格式每个字段都有明确的语义采集端直接解析成索引字段。一个典型的请求日志我用JSON格式大概长这样{timestamp:2026-05-20T14:23:01.812Z,level:INFO,traceId:a1b2c3d4e5f6,userId:10086,method:POST,path:/api/order/create,status:200,durationMs:132,message:order created}字段多了以后查询就很舒服了想统计某个接口的平均耗时直接基于durationMs聚合想追踪某一次完整调用链按traceId过滤就能把这次请求经过的所有服务串起来。加上traceId是投资回报率最高的一件事它把“日志海洋捞针”变成了“按编号精准检索”。2.3 给循环、重试和心跳日志做降噪日志量失控的重灾区往往不是业务主流程而是循环、定时任务、重试机制和健康检查这类高频执行逻辑。一次循环一万次日志打一条在DEBUG、十次里有一次打一条INFO批量任务跑完就是上万条垃圾日志。针对这类场景比较实用的降噪手段有几种。一是限频打印同一个事件在单位时间内只记录有限条数比如重试失败最多每30秒打一条WARN。二是首尾打点批量任务只在开始时打印任务参数、结束时打印成功量和失败量中间的单条处理异常用累计计数器来体现。三是采样输出极高流量的访问日志按比例记录或者只记录成功和失败的代表性样本。我见过最夸张的一个案例是某个定时任务每5秒扫描一次数据库每次扫描结果都打INFO一天就是17280条一个月在日志平台上占用了几十GB的索引空间。后来改成只在结果有变化时才打印日志量直接降了99%。高频场景每一条日志都要问一句“这条真的有人看吗”。2.4 日志框架选型与异步化的取舍Java生态里Logback仍是多数项目的默认选择log4j2的异步性能更强Go项目里zap基本是事实标准。选框架时除了性能还要考虑对结构化输出、动态级别调整、日志归集集成的支持度。异步日志是解决同步IO阻塞的重要手段但要注意取舍。Logback的AsyncAppender和log4j2的AsyncLogger都是把日志写入交给独立线程处理业务线程只负责投递队列这样可以显著降低日志对业务链路的影响。不过队列本身有容量上限超载以后是丢弃还是阻塞需要在“绝不丢日志”和“不能影响业务”之间做选择。我的默认方案是应用日志使用异步appender队列设置合理上限队列满时丢弃但保留弃用计数同时引入一个独立的错误日志文件走同步写入。这样即使异步队列出问题error级别的关键日志也不会丢而普通info日志丢了也就丢了不影响排障主路径。这个设计帮我挡过好几次线上io密集场景的高峰冲击。3. 线上日志引起的坑每一个都是教训3.1 同步写日志拖垮了整台应用这是日志事故里最典型也最隐蔽的。有一次线上系统大促前做压测发现接口RT从80ms飙升到2秒CPU不高内存正常数据库也无压力。上机器用jstack一看线程栈大量业务线程全阻塞在logback的appender输出逻辑里再深入看是磁盘IO到达瓶颈同步刷盘跟不上写入速度业务线程全部排队等日志写完。事后分析就是这个应用把日志输出策略配成了同步而且INFO日志量特别大每个请求都要写出好几行。磁盘本身是普通云盘IOPS有限扛不住这个写入量。解决方案分几步走先把关键路径改为异步日志降低写盘频率再把过于细碎的INFO日志降到DEBUG最后日志落地盘从普通云盘换成更高IOPS的类型。改完之后同样压测环境下RT回落到100ms以内。这个案例给我最大的教训是把日志文件写在本地磁盘再同步写入时你的应用可用性已经被磁盘IO绑架了。磁盘本身是开发者最容易忽视的单点一旦日志引发IO打满连错误日志都写不进去影响会从“接口慢”迅速恶化到“整个节点无响应”。3.2 日志文件无限增长磁盘被写满另一个高频事故是日志文件没做切割和清理磁盘被打满。印象很深的一次是某天凌晨收到磁盘告警登录一看是应用日志目录里一个几十GB的日志文件应用进程直接报“No space left on device”。排查才发现日志框架只配了单个大小切割没有配总文件数和保留策略切割出来的历史文件全部堆积。Linux系统的关键目录一旦写满后果是连锁的/var/log相关的系统日志写不进去、临时目录创建文件失败、数据库落盘报错更严重的是进程可能因为无法写入而直接退出或持续处于异常状态。磁盘满日志事故里我最推荐的配置组合是按天生成日志文件 单文件不超过200MB就滚动 最多保留7个文件 总大小上限10GB日志框架到了上限就自动删最老的文件。同时给日志目录单独挂一块盘从根本上避免与系统盘挤在一起。还要警惕周期任务在凌晨批量跑时产生的瞬时日志量这种情况即使总数不大也可能在某个时间节点突然把余量占满。所以磁盘监控一定不能只盯使用率也要关注增长速率超过日常基线时及时报警。3.3 日志里的敏感信息是你的法律风险日志把敏感信息打出去这个坑在初期的系统里最常见也最容易被忽略。用户手机号、身份证号、银行卡号、登录密码、token、内部密钥只要代码里在参数或响应里打印了一次就可能被日志采集、同步到日志平台、保留数周数月最后在某个意想不到的地方泄露出去。我见过一个真实案例某个内部系统为了方便排查把用户的登录请求体整个打进了INFO日志其中包含明文密码。后来日志平台被安全扫描发现存在多处敏感数据不仅要紧急删除历史日志还要整改所有涉及打印请求体的代码整个流程极其痛苦。疏散日志是把问题的“现场证据”留下来但绝不能把“隐私数据”变成日志的标配。从开发规范角度我有几条硬性要求不打印完整敏感字段只保留后四位或脱敏形式不打印请求体的原始报文只打印经过清洗的必要参数密钥、token一类的值严禁出现在日志中必须引用的场景使用掩码处理。日志脱敏最好在日志框架层面做统一拦截而不是依赖每个开发者自觉这样即使有人不小心打了敏感信息输出端也能兜住。3.4 异常日志的错误打法会掩盖问题异常日志的写法直接决定了事后排查的效率。很多代码里写的log.error(e.getMessage())打印出来只有一句“NullPointerException”或“Connection refused”完全看不出是哪个环节、哪条数据、哪个调用链触发的。更糟的是有些人直接用e.printStackTrace()把堆栈写到标准错误流生产环境里stdout/stderr根本没有日志采集等于白写。正确做法是log.error(create order failed, userId{}, productId{}, userId, productId, e)这种形式把上下文参数和完整堆栈一起打出来。堆栈能还原调用关系参数能还原触发条件两者缺一不可。这里要注意一个细节有些团队为了控制日志大小配置了堆栈深度截断或去掉某些类名的包前缀这会导致线上堆栈看起来很奇怪定位问题时反而更花时间。还有一类比较隐蔽的问题是“吞异常”。业务代码里catch了Exception之后只打一条日志就继续往下走日志级别还是DEBUG生产环境默认INFO根本看不到。线上表现为功能偶尔失败但没有一条ERROR日志排查时完全无从下手。我的建议是catch异常时先问这个异常影响到请求结果了吗影响了就打ERROR没影响但值得关注就打WARN完全不需要处理的至少要打个DEBUG并保留堆栈。3.5 MySQL慢查询日志与binlog的常见误区数据库层面的日志坑不比应用层少。MySQL慢查询日志是排查慢SQL的第一手资料但很多人配置有问题要么long_query_time设太小把全表扫描的记录全记下来日志量爆炸要么设成0记录所有查询基本等于性能负担翻倍。我的实践经验是先用默认的1秒跑一段时间观察top N慢SQL再根据业务特征调整阈值一般2到3秒更合适。日志平台经常从慢查询日志里发现同一个SQL反复出现这时候直接优化SQL或补索引就行不需要把慢查询日志当成全量审计日志来用。MySQL还有个常见误区是binlog。binlog是用于主从同步和基于时间点恢复的逻辑日志它必须保留不能因为嫌占磁盘就随意关闭或删除。我遇到过因为磁盘紧张直接rm了binlog的运维事故第二天主库宕机后想用binlog恢复数据结果发现日志已经被物理删除了只能从全量备份恢复到前一天的状态损失了大量业务数据。正确的做法是设置expire_logs_days或binlog_expire_logs_seconds让它按时间自动清理。4. 线上排查命令集合日志在手怎么快速查到根因4.1 第一波命令从海量日志里锁定目标范围登录一台线上机器第一时间做的永远是同一件事定位目标日志文件和初始错误特征。常见路径包括Nginx日志位于/var/log/nginx/access.log和error.log应用日志位于各自业务目录比如/data/logs/或/opt/app/logs/系统日志则在/var/log/。找不到就配置在哪个路径就切到哪个路径按项目规范来。快速浏览用什么我几乎不用cat因为大文件会把终端刷爆。tail -f跟进实时日志tail -n 200看最近200行less用PageUp/PageDown浏览大文件/关键字搜索并高亮nohup日志和console输出多的时候我习惯先tail -n 200再less进入交互模式慢慢往前翻。精准筛选错误日志的命令我会写成一个组合grep -n ERROR app.log | head -n 50 grep -n 订单创建失败 app.log.2026-05-20 | tail -n 20grep是排查命令中的基本功但注意线上大文件grep不要全量从头扫尽量结合时间节点缩小范围。更直观一些的话可以先把某一段时间内的所有WARN和ERROR提取到临时文件里再对临时文件分析避免反复扫描几百GB的原始日志。4.2 进阶统计命令awk、sort、uniq 的组合拳如果只是想看个大概趋势Linux命令行的组合拳远比打开日志平台快。我常用的几个统计手段很机械但很有效。统计日志行总数和ERROR数量grep -c ERROR app.log wc -l app.log按异常类型统计top榜单定位最高频的异常类grep ERROR app.log | awk -FException {print $1} | sort | uniq -c | sort -rn | head -n 20统计某个接口的响应时间分布找慢接口grep /api/order/create access.log | awk {print $NF} | sort -rn | head -n 5wc -l适合统计总量sort和uniq适合做聚合排序。这套组合命令的核心价值是快速回答“多不多、集中在哪、哪些异常出现频率在涨”这类问题不用等日志平台查询结果几秒内就能有相对准确的结论。如果需要确认某个临时文件里的内容再输出用redirect重定向成新的小文件后续所有命令都可以基于小文件操作效率高很多。4.3 怎么查看Nginx、MySQL、Redis 各组件的日志中间件的日志排查各有套路。Nginx重点是access.log的响应码和耗时我经常用awk做聚合awk {print $9} /var/log/nginx/access.log | sort | uniq -c | sort -rn awk {if($NF 2) print $0} /var/log/nginx/access.log | head -n 20第一条看状态码分布第二条找响应时间超过2秒的请求。顺手到配置里确认一下log_format是不是包含$request_time很多默认配置没有把这字段打进去遇到问题才想起来。MySQL排查先确保慢查询日志开着SHOW VARIABLES LIKE slow_query_log; SHOW VARIABLES LIKE long_query_time;没开就全局打开注意这个功能对性能有轻微影响线上提前评估再操作。关闭后到slow log文件路径里读日志mysqldumpslow -s t -t 10 /var/log/mysql/slow.logRedis日志主要看启动时间、持久化状态和慢日志。排查rdb或aof写入问题直接看redis的logfile配置路径定位慢命令用SLOWLOG GET命令不用去翻日志文件也能拿到近期的慢操作清单。容器化部署时中间件日志可能轻量化很多重点以stdout方式输出这时候结合docker logs或kubectl logs来查看命令路径会不一样。4.4 集中式日志平台查询技巧ELK 和 Loki 的实际用法日志平台到了线上排查阶段是另一套思路。ELKElasticsearch Logstash Kibana类的查询核心是Lucene语法。排除干扰信息用NOT多个条件用AND、OR时间范围要精确到分钟级。遇到一个报错想找关联请求时最简单的是按traceId过滤所以前期打日志带上traceId真的是救命设计。快速定位问题的有效查询模板我常写成这样message: ERROR AND traceId: a1b2c3d4e5f6 status: 500 AND latency: [100 TO *]Loki与ELK不同核心逻辑是先用标签缩小范围再做全文检索。查询语法类似logQL比如在一个job里过滤error{jobapp-order} | ERROR | orderId10086集中式平台的查询效率一小半靠工具熟练度一大半靠日志规范。如果日志是非结构化的字段解析不到位查起来约等于在grep整个大文件毫无体验。所以在日志规范里写清楚格式比在Kibana里炫技重要得多。4.5 adb logcat 抓取移动端日志的实战姿势App开发调试和线上问题排查最常用的一条命令是adb logcat。它有几个常用参数-s过滤指定标签-v time显示时间-d一次性把当前缓冲区日志输出后退出还有-f把日志写入文件。抓崩溃现场时我先清空缓冲区再复现问题adb logcat -c # 在App中复现崩溃 adb logcat -d -v time -s AndroidRuntime:E crash.log按标签过滤只保留指定模块的输出-s AndroidRuntime:E就只显示AndroidRuntime的Error级别日志。如果怀疑JNI层或native崩溃配合ndk-stack来符号化堆栈如果是ANR重点抓/ANR在ActivityManager附近的日志块。移动端日志另一个点是App内部按天写入的文件线上用户反馈问题后引导用户开启调试模式导出日志文件能拿到比任何远程日志都完整的case现场。5. 高频问题速查与价值千金的经验沉淀5.1 日志治理高频问题速查表问题原因处理方式日志文件无限增长未配置滚动策略或保留策略按天或大小滚动设置最大文件数和总大小限制接口变慢线程卡在日志写入同步IO导致业务线程阻塞改用异步appender日志落盘路径换更高性能磁盘ERROR日志很多但查不到关键信息只打了message没打上下文参数日志带上业务ID、traceId和完整异常堆栈日志里出现明文密码或手机号直接打印请求体或响应体开发规范要约束日志框架做脱敏拦截慢查询日志无输出参数配置不合适或未开启确认slow_query_log和long_query_time分析慢查询原因binlog被手动删除磁盘紧张被运维误清开启binlog自动过期清理策略禁止手动删除重启后日志丢失日志写到容器/临时目录挂载持久化目录或把日志输出到stdout由采集端收集5.2 用代价换来的几条实用经验第一个经验非常在意性能的核心链路可以把“循环体内的日志完全去掉”只在循环结束后打印聚合统计。我在高并发推荐服务里做过一次改造仅把for循环内的DEBUG/INFO日志移出去整体吞吐量提升了接近20%日志噪音也大幅下降。第二个经验日志平台的索引和存储成本也是成本。不要把所有级别的日志都灌到ELK或Loki里有些DEBUG级别的日志只保留在本地文件设置滚动保留几天就够了只有WARN及以上或特定业务关键事件才同步到集中式平台这样既保住了排障能力又能把日志平台费用控制在合理范围。日志采集端也要配置好过滤规则从源头减少无效数据。第三个经验排查线上问题要形成自己的SOP。先看监控和告警趋势确认影响面再找错误日志定位直接原因接着结合代码和上下文判断根因最后用统计命令验证覆盖范围。这个顺序不能乱否则很容易被单个孤立异常带偏方向。我在业务高峰期排查用的就是这套流程基本上能在十几分钟内给出一个比较靠谱的定位结论。第四个经验日志规范是团队工程不是个人习惯。项目启动时就要在代码规范里明确日志级别怎么用、关键字段怎么打、敏感信息怎么处理、滚动清理策略是什么还要在code review中持续盯执行。等到线上出事故了再补规范代价就大得多了。我个人在实际排查日志问题中体会最深的一点是日志体系的优化永远前置在故障发生之前。你可以没有完美的监控但一定不能没有一份能在关键时刻讲清楚问题的日志。每次写完一条日志都花两秒钟想一下三个月后一个完全不了解这段代码逻辑的人看到这行日志能推断出什么——如果能推断出足够多的现场信息这就是一条好日志如果不能它只是给系统增加的一份噪音。设计一套精炼且可观测的日志体系会是你做线上问题排查时最值得信赖的伙伴。