真实面经题目 · 原创解析
这类 Linux 日志排查题考察的不是背命令，而是能否在生产环境中安全、快速、可复现地定位问题。核心思路是先限定日志范围，再用管道逐步缩小：时间窗口、关键字、traceId、状态码、接口路径、调用方、异常栈，最后用统计命令判断问题规模和集中点。回答时要体现两个能力：一是熟练组合 tail、grep、awk、sed、sort、uniq、wc、xargs、less、journalctl；二是知道大文件、线上机器、权限、性能和误操作风险。
我会先确认日志来源、时间范围、服务实例和关键字段，例如请求时间、traceId、接口路径、状态码、耗时、错误码。排查时不会直接全量扫大文件，而是先用 journalctl、less 或按日期切分后的日志文件定位窗口；如果是正在发生的问题，用 tail -f 或 tail -n 配合 grep 观察实时错误。接着用 grep 过滤 ERROR、Exception、timeout、状态码 5xx 等关键字，再用 awk 提取接口、状态码、耗时或 traceId 字段，用 sort、uniq -c、wc 统计高频错误、受影响请求量和异常集中时间段。如果拿到 traceId，会优先按 traceId 串起一次请求链路，结合上下文行查看完整异常。对于压缩日志或大文件，会使用 zgrep、less、grep 的定向过滤，避免把文件一次性加载到内存，也不会在生产高峰期执行过重命令。最后输出结论时会说明影响范围、根因线索、证据命令和下一步验证方式。
排查日志前先问清楚：问题发生的准确时间、用户或请求标识、服务名、机器实例、接口路径、返回码、是否持续复现。日志排查最怕无边界全量搜索，尤其生产日志可能有几十 GB。一个合格回答应先说明会把范围限制到某个时间窗口和某几台机器，再开始管道过滤。
如果故障正在发生，可以用 tail -f 或 tail -n 先看最新日志，再接 grep 过滤关键字，例如 ERROR、Exception、timeout、refused、reset、5xx。tail 适合观察趋势和复现过程，但不适合做历史全量分析。实时观察时要避免输出过多内容刷屏，可以加 grep --line-buffered 保持管道实时输出。
历史日志要先找时间范围。如果日志中时间格式固定，可以用 grep 过滤日期小时，或用 awk 根据时间字段筛选区间。systemd 管理的服务优先考虑 journalctl -u 服务名 --since '2026-05-30 10:00:00' --until '2026-05-30 10:30:00'，这样比直接扫文件更稳定，也能减少无关数据。
grep 不应只搜一个 ERROR 就结束。第一层搜严重级别，如 ERROR、WARN；第二层搜异常类型，如 NullPointerException、timeout、Connection refused；第三层搜业务字段，如 orderId、userId、traceId、接口路径；第四层结合 grep -C、-A、-B 查看上下文，避免只看到异常栈的一行而漏掉真正原因。
当日志格式稳定时，awk 是核心工具。可以提取状态码、接口、耗时、IP、traceId 等字段，再交给 sort 和 uniq 统计。例如访问日志中常见需求是统计 5xx 数量、Top N 接口、慢请求分布、某个客户端 IP 的请求量。回答时要强调先确认字段位置或分隔符，不能盲目按空格切，因为 JSON 日志、异常栈和带空格字段会破坏简单切分。
sort、uniq -c、wc 的价值在于量化问题。比如 wc -l 判断错误总量，sort | uniq -c | sort -nr 找高频错误，awk 提取接口后统计哪个接口 5xx 最多，提取分钟粒度时间戳后统计错误是否集中爆发。生产排障不能只说发现了某个异常，还要回答影响多少请求、集中在哪个时间段、是否仍在增长。
如果日志有 traceId，应优先按 traceId 查完整请求链路。先用 grep 找到入口日志，再沿着同一个 traceId 查下游调用、数据库访问、RPC 错误和最终响应。需要时用 grep -n 拿到行号，再用 sed -n 打印附近范围，避免在巨大文件中反复手动翻找。traceId 排查能把很多错误收敛成一次请求到底在哪里失败。
less 不会一次性把整个文件加载进内存，适合打开大日志后用 / 搜索关键字，用 n 跳到下一处，用 & 只显示匹配行。相比 vim 直接打开超大日志，less 对生产机器更安全。查日志时可以先用管道过滤到较小结果，再交给 less 浏览，例如 grep 某时间段和关键字后分页查看。
当日志分散在多个文件或目录中，可以用 find 配合 xargs 批量 grep。重点是处理文件名空格和参数过长问题，生产中更稳妥的写法会使用 find 的 -print0 和 xargs -0。还要避免对整个日志目录无差别递归扫描，应该加文件名、修改时间、大小等限制。
生产机器上查日志要控制 CPU、磁盘 IO 和输出量。避免在高峰期对几十 GB 文件做无条件 grep、sort 全量排序或把日志复制到终端。必要时先抽样、按时间过滤、限制文件范围，或在日志平台执行查询。涉及敏感数据时不能随意复制用户信息、token、手机号等内容。
我会先看日志是否由 systemd 管理。如果是服务日志，可以用 journalctl 指定服务名和 --since、--until 精确过滤时间段，再 grep ERROR 或异常关键字。如果是普通文件日志，会先根据文件名选择对应日期的日志，再用 grep 过滤小时分钟，或者用 awk 按日志首字段的时间进行区间判断。关键点是不要直接扫所有历史日志，而是先缩小到问题发生窗口，再过滤错误级别和业务字段。
我会先确认访问日志格式，比如接口路径和状态码分别在哪些字段。如果是 Nginx 或网关日志，可以用 awk 筛选状态码大于等于 500 且小于 600 的行，然后提取接口路径字段，交给 sort、uniq -c、sort -nr 做频次统计。还会补充一点：真实生产里要注意 URL query 参数会导致同一个接口被拆成很多条，必要时先去掉 query string，按规范化路径统计，结果才有排障价值。
我会用 grep 在相关服务日志中搜索这个 traceId，先确认入口请求、请求参数摘要、响应状态和耗时。然后继续在同一 traceId 下找下游调用、数据库操作、缓存访问、RPC 返回码和异常栈。如果日志分布在多台机器，就按服务实例或日志平台扩大搜索范围。最后根据时间顺序还原链路，判断是入口参数问题、业务逻辑异常、下游超时、数据库慢查询，还是返回码映射错误。
我不会直接用 vim 打开，也不会无条件 sort 整个文件。会先按文件名、修改时间、时间窗口和关键字缩小范围，使用 grep、awk、sed、less 这类流式或分页工具。需要统计时尽量只提取必要字段再排序，必要时加 head 先抽样确认格式。生产高峰期还要考虑 IO 压力，避免在业务机器上执行长时间全盘扫描，可以转到日志平台、备机或离线副本分析。
grep 更适合按行过滤，快速找关键字、错误级别、traceId、接口路径；awk 更适合处理结构化字段，比如提取状态码、耗时、IP、接口并做简单统计；sed 更适合按行号或范围取上下文，例如已知错误在第 20000 行附近，可以取前后几十行看完整调用过程。三者配合时，一般先 grep 缩小候选，再 awk 提取字段，必要时 sed 查看上下文。
我会把日志按分钟或秒级时间桶聚合，统计每个时间桶内的 ERROR 数量、5xx 数量或特定异常数量。可以用 awk 截取时间字段到分钟粒度，然后 sort、uniq -c 看分布。如果某一分钟开始错误量明显上升，再结合发布、配置变更、依赖异常、流量变化去验证。只看总错误数不够，因为同样一千条错误，集中在一分钟和分散在一天的处理优先级完全不同。
不能在生产高峰期对大目录做无范围递归搜索，不能直接打开超大日志文件，不能把敏感日志随意复制到外部，不能执行会大量占用 CPU、内存、磁盘 IO 的命令而不加限制，也不能只凭一条异常日志下结论。查日志要可控、可复现、可回滚，必要时使用只读账号、日志平台或离线副本，避免排障动作本身影响线上服务。
