一、线上崩了？别慌，90%的程序员都靠这招救急
做后端、运维的同学，谁没经历过这种崩溃时刻？Java、Spring Boot服务突然变慢、报错，页面打不开，老板在群里催命，同事们急得团团转，而你对着几百兆、上G的日志文件，翻得头晕眼花，却连问题在哪都找不到。
其实，日志排查根本不用死磕——不用装复杂的工具，不用懂高深的命令，只要掌握15个基础Linux命令，就能快速“剖开”日志，找到问题根源，几分钟搞定别人几小时都解决不了的麻烦。
更关键的是，这些命令不是花里胡哨的技巧，而是一线程序员、运维每天都在用的“保命神器”，不管是日常排查小问题，还是线上紧急 outage 救急，都能派上大用场。但很多人要么不知道这些命令，要么会用却用不精，白白浪费大量时间。
今天就把这套“日志排查速通秘籍”彻底拆解，从基础到进阶，从单一命令到组合用法，新手也能直接抄作业，看完就能上手实操。
二、核心拆解：15个Linux高频日志命令，附实操示例（直接复制可用）在开始之前，先说明一下：所有命令均基于Ubuntu系统，适配Java、Spring Boot等常见服务的日志格式，我们用一份真实的Spring Boot日志作为示例（如下），所有命令实操都围绕这份日志展开，更贴近真实工作场景。
2025-01-10 10:01:12.453 INFO 12345 --- [http-nio-8080-exec-1] c.e.a.OrderController : Received request GET /orders/1022025-01-10 10:01:12.611 INFO 12345 --- [http-nio-8080-exec-1] c.e.a.OrderService : Fetching order 102 from DB2025-01-10 10:01:13.102 WARN 12345 --- [http-nio-8080-exec-1] c.e.a.OrderService : Slow DB query took 491 ms2025-01-10 10:01:13.133 ERROR 12345 --- [http-nio-8080-exec-1] c.e.a.OrderService : Failed to fetch discounts for order 102java.lang.NullPointerException: Cannot invoke "Discount.getAmount()" because "discount" is null at com.example.app.DiscountService.getDiscount(DiscountService.java:42) at com.example.app.OrderService.calculatePrice(OrderService.java:85) at com.example.app.OrderController.getOrder(OrderController.java:55)2025-01-10 10:02:04.884 INFO 12345 --- [http-nio-8080-exec-3] c.e.a.PaymentController : Received POST /payments2025-01-10 10:02:05.105 ERROR 12345 --- [http-nio-8080-exec-3] c.e.a.PaymentService : Payment failed for user 77java.sql.SQLTimeoutException: Query timed out after 30000 ms2025-01-10 10:04:22.315 DEBUG 12345 --- [http-nio-8080-exec-5] c.e.a.InventoryService : Checking stock for item ABC1232025-01-10 10:04:22.897 INFO 12345 --- [http-nio-8080-exec-5] c.e.a.InventoryService : Stock available for item ABC1232025-01-10 10:04:31.002 ERROR 12345 --- [http-nio-8080-exec-7] c.e.a.OrderService : Failed to update order 105java.lang.RuntimeException: Update conflict for order 1052025-01-10 10:05:57.431 INFO 12345 --- [http-nio-8080-exec-4] c.e.a.HealthController : GET /health took 10 ms基础命令（新手必会，30秒上手）
这5个命令是日志排查的“基石”，不管是简单查看日志，还是快速定位基础问题，都离不开它们，无需复杂操作，输入命令就能出结果。
1. tail：实时监控日志（线上救急首选）作用：实时查看日志新增内容，相当于“实时监控”，服务报错时，用它能第一时间看到最新的错误信息。
# 实时监控日志（最常用）tail -f application.log# 先查看最后20行日志，再实时监控tail -n 20 -f application.log# 实时监控，只过滤包含“Payment”（支付）相关的日志tail -f application.log | grep "Payment"
实操效果：比如支付功能报错，用最后一条命令，就能只看支付相关的日志，避免被其他无关日志干扰，快速找到“Payment failed for user 77”这类错误。
2. cat：查看完整日志（小文件专用）作用：从开头到结尾，完整打印整个日志文件，适合日志文件较小（几兆）、需要快速浏览全部内容的场景。
# 查看完整日志cat application.log# 查看完整日志，只过滤包含“ERROR”（错误）的内容cat application.log | grep "ERROR"
实操效果：第二条命令能快速筛选出所有错误日志，不用手动翻找，直接定位所有报错记录。
3. tac：反向查看日志（最新内容置顶）作用：和cat相反，从日志末尾（最新内容）开始打印，适合日志文件较大、想优先看最新日志的场景，不用翻到文件最后。
# 反向查看日志，最新内容在最前面tac application.log
实操效果：执行命令后，最新的日志（比如“GET /health took 10 ms”）会直接显示在屏幕顶部，省去翻页的麻烦，线上 outage 时，能快速查看最近的操作记录。
4. head：查看日志开头（快速验活）作用：只查看日志的前几行内容，适合快速确认日志是否正常生成、服务是否正常启动（查看启动日志）。
# 查看日志前10行（默认前10行，可省略-n 10）head application.log# 查看日志前20行head -n 20 application.log
实操效果：服务启动后，用head命令查看开头日志，能快速确认服务是否正常接收请求（比如看到“Received request GET /orders/102”，说明服务正常）。
5. wc：统计日志行数（判断日志规模）作用：统计日志文件的总行数，快速判断日志大小，进而选择合适的排查方式（行数太多，就不用cat命令，避免卡顿）。
# 统计日志总行数wc -l application.log
实操效果：如果执行后显示“3000000”（300万行），说明日志文件很大，此时用cat命令会非常卡顿，优先用后面的less、grep等命令筛选。
进阶命令（筛选过滤，精准定位问题）基础命令只能满足简单查看，遇到复杂问题（比如特定错误、慢查询），就需要用这些进阶命令，精准筛选日志，快速找到问题根源。
6. grep：日志筛选“神器”（最常用）作用：根据关键词筛选日志，可过滤错误、警告、特定请求等，是日志排查中使用频率最高的命令，没有之一。
# 筛选所有错误日志（包含ERROR关键词）grep "ERROR" application.log# 筛选空指针错误（包含NullPointer关键词）grep "NullPointer" application.log# 筛选慢查询日志（包含Slow DB query关键词）grep "Slow DB query" application.log# 不区分大小写筛选（比如筛选timeout、Timeout都能匹配）grep -i "timed out" application.log# 统计错误日志的数量grep -c "ERROR" application.log
实操效果：比如执行“grep -c "ERROR" application.log”，如果输出“3”，说明有3条错误日志；如果输出几十、上百条，说明服务存在严重问题，需要紧急处理。
7. awk：提取有用信息（结构化筛选）作用：按列、按条件提取日志中的有用信息，比如提取时间戳、日志级别、服务名称等，适合日志格式规范的场景（比如Spring Boot日志）。
# 提取日志的时间戳、日志级别（第1、2、3列）awk '{print $1, $2, $3}' application.log# 筛选“took”相关日志，且耗时超过400ms的（比如慢查询）awk '/took/ && $NF+0 > 400' application.log# 提取所有服务名称，去重后显示（第9列是服务名称）awk '{print $9}' application.log | sort | uniq
实操效果：第二条命令能快速筛选出耗时超过400ms的操作（比如示例中的“Slow DB query took 491 ms”），直接定位慢查询问题；第三条命令能查看服务涉及的所有模块，快速判断哪个模块报错最多。
8. sed：清理或提取特定日志作用：删除无用日志、替换日志内容，或提取特定片段（比如完整的错误堆栈），适合日志内容杂乱、需要精简的场景。
# 删除所有DEBUG级别的日志（过滤掉包含DEBUG的行）sed '/DEBUG/d' application.log# 替换线程名称（将http-nio-8080-exec-1替换为EXEC-1，简化显示）sed 's/http-nio-8080-exec-1/EXEC-1/g' application.log# 提取空指针错误的完整堆栈信息（从NullPointerException开始，到OrderController结束）sed -n '/NullPointerException/,/OrderController/p' application.log
实操效果：最后一条命令能提取出完整的错误堆栈，方便开发者定位具体的报错代码行（比如示例中的DiscountService.java:42），不用手动复制堆栈信息。
压缩日志命令（处理归档日志）Linux系统会自动对日志进行轮转归档，归档后的日志会变成.gz压缩文件，直接用上面的命令无法查看，需要用这3个专门处理压缩日志的命令。
9. zcat：查看压缩日志内容 # 查看压缩日志的完整内容（无需解压）zcat application.log.1.gz# 查看压缩日志，筛选错误信息zcat application.log.1.gz | grep "ERROR"10. zgrep：筛选压缩日志（压缩版grep）
# 筛选压缩日志中的错误信息zgrep "ERROR" application.log.1.gz# 不区分大小写筛选压缩日志中的超时信息zgrep -i "timeout" application.log.2.gz# 统计压缩日志中的错误数量zgrep -c "ERROR" application.log.1.gz11. zless：滚动查看压缩日志（压缩版less）
# 滚动查看压缩日志（无需解压，可上下翻页、搜索）zless application.log.1.gz
实操效果：进入zless后，操作和普通less一致，输入“/ERROR”可搜索错误信息，按“n”查看下一个匹配项，按“Shift+G”跳转到日志末尾，适合查看大型压缩日志。
工具类命令（日志管理，辅助排查）除了筛选日志，日常工作中还需要管理日志（比如查看日志大小、查找归档日志），这3个命令能帮你高效管理日志文件。
12. less：滚动查看大型日志作用：打开大型日志文件（几G甚至几十G），支持上下翻页、搜索，不会像cat命令那样卡顿，是查看大型日志的首选工具。
# 打开大型日志文件less application.log
常用操作（打开后使用）：
实操效果：打开5G的日志文件，less命令能瞬间加载，而VS Code、记事本等工具会直接卡死，非常适合线上大型服务的日志排查。
13. du：查看日志文件大小 # 查看日志文件的大小（简洁显示，单位自动适配）du -sh application.log
实操效果：执行后可能显示“1.2G application.log”，如果日志文件超过10G，说明日志轮转配置有问题，需要调整（否则会占满磁盘空间）。
14. find：查找所有日志文件 # 查找当前目录下，所有以“application.log”开头的日志文件（包含归档、压缩文件）find . -name "application.log*"
实操效果：执行后会列出所有相关日志文件，比如application.log、application.log.1、application.log.2.gz，方便快速找到需要排查的归档日志。
组合命令（复杂场景，高效排查）实际工作中，排查问题很少用单一命令，更多是将多个命令组合起来，应对复杂场景（比如查找最慢操作、统计错误最多的服务）。
15. 3个高频组合命令（直接抄作业） # 1. 查找所有耗时操作，按耗时从高到低排序，只显示前10条（定位最慢操作）grep "took" application.log | sort -k10 -nr | head# 2. 筛选所有错误日志，并显示错误后面的3行内容（查看完整错误堆栈）grep -A 3 "ERROR" application.log# 3. 统计错误日志中，每个服务的报错次数，按次数从高到低排序（定位问题服务）grep "ERROR" application.log | awk '{print $9}' | sort | uniq -c | sort -nr
实操效果：第一条命令能快速找到耗时最长的操作（比如示例中的“Slow DB query took 491 ms”），帮你定位慢查询、慢接口；第三条命令能统计每个服务的报错次数，比如输出“2 OrderService”，说明OrderService服务报错最多，优先排查这个服务。
三、辩证分析：这些命令好用，但别踩坑这15个Linux命令确实能极大提升日志排查效率，帮我们快速解决线上问题，节省大量时间，甚至能在紧急 outage 时“救命”，这是不可否认的价值——它们无需安装复杂工具，无需高深的技术储备，新手也能快速上手，堪称“运维、后端必备神器”。
但我们不能盲目依赖这些命令，忽略了背后的隐患。很多人学会这些命令后，就陷入了“只会用命令，不会找根源”的误区：比如用grep找到错误日志，就只盯着错误信息改代码，却不分析错误产生的本质原因；比如用awk筛选出慢查询，就只优化SQL，却不排查服务器资源、网络等其他因素；还有人过度依赖组合命令，忽略了日志本身的格式规范——如果日志格式混乱，awk、sed命令就会失效，再多的命令也无济于事。
更值得注意的是，这些命令只能“排查问题”，不能“解决问题”。它们是我们的“工具”，而不是“万能钥匙”：比如你用tail监控到服务报错，最终还是要靠自己的技术储备，分析报错原因、修改代码、优化配置；比如你用组合命令找到慢查询，还是要懂SQL优化、数据库索引，才能真正解决问题。
除此之外，还有一个容易被忽略的点：日志排查的核心是“思路”，而不是“命令”。同样的命令，不同的人用，效率天差地别——有的人能精准定位关键词，几分钟找到问题；有的人却盲目筛选，翻了几小时日志还是一无所获。
所以，我们该辩证看待这些命令：既要熟练掌握，用它们提升排查效率，也要避免过度依赖，注重培养自己的问题分析能力；既要会用单一命令，也要懂组合用法，更要明白命令背后的逻辑。只有这样，才能真正发挥这些命令的价值，而不是沦为“只会敲命令的工具人”。
四、现实意义：学会这些，能帮你避开多少坑？对于后端、运维工程师来说，日志排查是日常工作中最核心、最频繁的任务之一，而这15个命令，能直接解决工作中的80%以上的日志排查问题，其现实意义远超“学会几个命令”本身。
首先，节省大量时间成本。以前翻几百兆、上G的日志，可能需要几小时，甚至大半天，而用这些命令，几分钟就能筛选出关键信息，定位问题根源——比如线上服务崩了，用tail实时监控，用grep筛选错误，用sed提取堆栈，10分钟就能找到报错代码行，快速修复问题，避免损失扩大。对于程序员、运维来说，时间就是效率，更是价值，学会这些命令，能让你从繁琐的日志翻找中解放出来，把更多时间用在核心工作上。
其次，提升职场竞争力。不管是面试还是工作，日志排查能力都是后端、运维岗位的核心要求——面试时，面试官常问“线上服务报错，你怎么排查？”，如果你能熟练说出这些命令的用法、组合技巧，甚至能结合实际场景举例，一定会加分不少；工作中，别人几小时解决不了的问题，你几分钟搞定，既能得到老板、同事的认可，也能在紧急情况下凸显自己的价值，为升职加薪打下基础。
最后，减少线上损失。线上服务的每一次故障，都可能带来实实在在的损失——比如电商平台的支付服务报错，每多卡顿一分钟，就可能流失大量用户、损失订单；比如后端服务慢查询，会导致用户体验变差，甚至流失核心用户。而这些命令能帮你快速排查问题、解决问题，缩短故障持续时间，最大限度减少损失。
举一个真实的案例：有一次，某后端服务突然变慢，所有同事都在查监控、翻代码，却找不到问题，仪表盘没用，指标延迟，陷入僵局。最后，有个运维用了一条组合命令：grep "took" application.log | sort -k10 -nr | head，瞬间找到了问题——OrderService服务中的一个查询，耗时高达2.1秒，原因是缺少数据库索引。修复索引后，服务瞬间恢复正常，整个过程只用了5分钟。
这个案例告诉我们：有时候，解决问题的不是复杂的工具，而是简单实用的命令，以及清晰的排查思路。这些命令看似基础，却能在关键时刻发挥巨大作用，帮我们避开很多不必要的坑，甚至“救命”。
五、互动话题：这些日志排查坑，你踩过吗？日志排查是每个后端、运维都绕不开的话题，不管是新手还是老司机，都难免在排查日志时踩坑——比如翻了几小时日志，才发现关键词输错了；比如用cat打开大型日志，导致服务器卡顿；比如找到了错误日志，却不知道怎么分析堆栈信息。
今天就来互动一波，聊聊你在日志排查中遇到的那些事：
1. 你平时排查Linux日志，最常用的是哪几个命令？
2. 有没有遇到过“紧急 outage，翻了几小时日志都找不到问题”的情况？最后怎么解决的？
3. 除了文中的15个命令，你还有哪些独家的日志排查技巧？
欢迎在评论区留言分享，互相交流、避坑，让我们一起提升日志排查效率，少走弯路、少加班！
另外，收藏这篇文章，下次排查日志时，直接打开就能抄作业，新手也能快速上手，再也不用瞎翻日志、浪费时间～
本站是社保查询公益性网站链接，数据来自各地人力资源和社会保障局，具体内容以官网为准。
定期更新查询链接数据 苏ICP备17010502号-11