Linux 与日志排查基础

• 文件与目录命令
• 日志查看命令
• 测试环境操作

cd 切换目录；ls 列出文件（-l 显示详情、-a 显示隐藏文件、-h 人类可读大小）；cp 复制（-r 递归、-i 覆盖提示）；mv 移动/重命名；rm 删除（-r 递归、-f 强制，谨慎使用）；tail 查看文件尾部（-f 实时跟踪日志、-n 指定行数）；head 查看文件头部（-n 指定行数）。测试场景中常用 ls 查看应用目录、cp 备份配置、tail -f 实时跟踪应用日志、head 查看日志开头。注意 rm 危险操作需谨慎，用前确认路径。

这些是排障的基础"敲门砖"，重点掌握 tail -f 跟踪日志、ls 定位文件、cp 备份现场。命令简单但组合起来能覆盖大部分测试环境操作。

• 实时跟踪
• 日志检索与过滤
• 文本处理

实时跟踪用 tail -f 日志 观察新增日志；检索用 grep 关键字 日志（-i 忽略大小写、-n 显示行号、-A/-B 显示上下文、-E 正则、-C 计数）。快速定位异常：先用 grep 找到 ERROR/Exception 关键字所在行，用 -A/-B 看异常前后上下文，用 awk 按列提取时间、级别、类名等字段，用 sed 替换或抽取特定行。典型组合如 grep ERROR app.log | awk '{print $1,$2,$NF}' 提取时间与异常类，或 tail -f app.log | grep ERROR 实时过滤异常。通过关键字+时间范围+上下文一步步缩小到异常发生点。

定位异常的核心是"过滤 + 上千下文"。grep 找点、awk 取字段、sed 处理、tail -f 实时，四者组合能高效从海量日志中定位异常。

• 进程状态查看
• 资源占用监控
• 结束进程

ps 查看进程快照，ps -ef 或 ps aux 查看所有进程及 PID、CPU、内存、启动命令，ps -ef | grep 应用名 定位目标进程。top 实时查看进程 CPU/内存占用排序，top -p PID 监控指定进程，M 按内存排序、P 按 CPU 排序；也可用 top -H 看线程。kill 结束进程，kill PID 发送 TERM 信号优雅退出，kill -9 PID 强制结束（用于僵死进程）。处理异常进程时先确认 PID 再 kill，避免误杀关键进程。

ps 看状态、top 看动态占用、kill 做干预。定位 CPU/内存异常先从 top 找到高占用进程，再决定 kill 与重启。

• 端口监听判断
• 连通性测试
• 接口返回验证

netstat/ss 查看端口监听与连接状态，ss -tlnp 或 netstat -tlnp 查看监听端口及对应进程，判断服务是否起来。ping 测试 IP 连通性（ICMP），判断网络是否可达。telnet 测试 TCP 端口连通性，telnet ip port 能连上说明端口开放。curl 查看 HTTP 接口返回，curl -v URL 显示详细请求/响应，curl -X POST -d '{}' 发送请求，-H 加头，-w 输出耗时。排查顺序：先 ping 确认网络，再 telnet/ss 确认端口，最后 curl 验证接口返回，即可定位是网络、端口还是应用问题。

四者分工明确：ping 管网络层、telnet/ss 管端口层、curl 管应用层。逐层验证能快速判断故障在网络、服务监听还是接口本身。

• 时间线还原
• 多服务关联
• 上下文分析

完整流程：先确定问题发生的时间窗口，多服务日志按时间戳对齐（要求各服务时钟一致，最好使用 NTP 同步）；用 traceId 作为关联键，把同一请求在多个服务的日志串联起来；按时间顺序排列事件，找出异常发生点；再分析异常前后的上下文（异常前的警告、参数、调用，异常后的降级、重试），判断根因与影响范围。分析时要关注时间连续性（有无空档）、异常前的先兆（如 WARN、超时）、异常后的连锁反应。跨服务时用 traceId 比纯时间对齐更可靠，两者结合最稳妥。

日志还原时间线 = 时间对齐（横轴）+ traceId 关联（纵轴）+ 上下文分析（细节）。时间戳是基础，traceId 是精确定位，上下文是判断因果。

• 磁盘空间查看
• 内存使用查看
• 故障定位

df 查看文件系统磁盘整体使用情况，df -h 看各挂载点剩余空间，可判断磁盘是否写满（Use% 到 100%）。du 查看目录/文件占用大小，du -sh 看指定目录整体占用，du -sh * 列出各子目录占用，用于定位大目录。free 查看内存使用，free -h 看总内存、已用、可用及 swap。磁盘写满会导致应用无法写日志、MySQL 无法写入、服务启动失败；内存不足会导致 OOM、进程被杀、swap 频繁。定位流程：先 df 看磁盘，再用 du 找大目录清理；再 free 看内存，用 top 找高内存进程。测试环境此类故障常因日志增长、临时文件堆积、缓存溢出引起。

df/du/free 是资源型故障的"体检工具"。磁盘看 df/du，内存看 free/top，定位到资源瓶颈后清理或扩容即可恢复。

• 权限模型
• 权限命令
• Permission denied 排查

Linux 权限模型为 rwx（读/写/执行）作用于 owner/group/other 三类用户。chmod 修改权限（数字如 755 或符号如 u+x），chown 修改文件属主与属组（chown user:group file），sudo 以管理员/其他用户身份执行命令（sudo 命令）。遇到 Permission denied 时排查：先 ls -l 看文件属主、属组与权限，确认当前用户是否在属主/属组且权限匹配；若属主不符合，用 sudo 或 chown 调整；若不是当前用户，切换到有权限的用户；还要检查目录的 x 权限（可进入）与父目录权限。测试中常见于日志文件、配置文件、脚本无执行权限。

Permission denied 的本质是"当前用户对文件 rwx 权限不足"。排查顺序是"看权限→看属主→调整权限或切换用户"。

• 组合命令流水线
• 统计字段提取
• 常见统计场景

组合命令用管道串联：grep 模式 日志 | awk '{print $字段}' | sort | uniq -c | sort -rn。统计错误码分布：提取状态码字段后 sort+uniq -c 计数再按次数降序；统计接口耗时：用 awk 提取耗时字段，再 sort 取最大或算分位数；统计异常频率：grep -c ERROR 计数，或按异常类型字段分组统计。典型命令如 grep 'HTTP' access.log | awk '{print $9}' | sort | uniq -c | sort -rn 统计各状态码数量。awk 负责提取字段，sort 排序，uniq -c 去重计数，sort -rn 按次数降序，形成标准的"提取-计数-排序"流水线。

日志统计的精髓是"管道组合"：grep 过滤、awk 提字段、sort+uniq 聚合并计数。这一流水线可复用解决大量分布/频率类统计问题。

• 后台运行
• 定时任务
• 常驻进程管理

命令 & 把命令放入后台运行，但终端关闭可能被终止；nohup 命令 & 忽略挂断信号，使进程在终端退出后仍运行，输出重定向到 nohup.out（可指定 > log 2>&1）。crontab 定时任务：crontab -e 编辑任务，crontab -l 查看，格式为"分 时 日 月 周 命令"。测试环境常用来：用 nohup & 启动常驻服务/脚本，用 crontab 定时执行清理、数据初始化、监控脚本。注意 nohup 进程要记 PID 便于管理，crontab 中命令用绝对路径并重定向日志。

nohup 解决"后台常驻"，crontab 解决"定时执行"。测试环境常驻进程与定时脚本的管理是这两者的组合应用。

• docker 命令
• kubectl 命令
• 容器状态查看

docker 环境：docker ps 查看运行中容器，docker logs -f 容器 实时查看容器日志，docker exec -it 容器 bash 进入容器内部排查，docker inspect 查看容器配置，docker stats 查看资源占用。Kubernetes 环境：kubectl get pods 查看 Pod 状态，kubectl logs <pod> -n <ns> 查看容器日志（-f 实时、--tail 指定行数），kubectl describe pod 查看 Pod 详细事件（含镜像拉取、启动、重启、错误原因），kubectl exec -it pod -- bash 进入容器。排查顺序：先看 Pod 状态（kubectl get），再 describe 看事件与原因，最后 logs 看应用日志，必要时 exec 进入内部排查。

容器排查的关键是"先看状态与事件，再看日志，最后进容器"。kubectl describe 能看调度/启动/重启原因，docker/kubectl logs 看应用日志，exec 进现场。

• 数据库连接
• 查询与执行计划
• 数据问题定位

mysql 连接：mysql -h host -u user -p，psql -h host -U user -d db；连接后执行 SQL 查询验证数据。定位数据问题：直接查询接口对应的表，确认库内数据与接口返回是否一致；若库内数据对但接口错，则是后端逻辑问题。查看执行计划：mysql 用 EXPLAIN SELECT ...，psql 用 EXPLAIN ANALYZE，可看是否全表扫描、是否走索引、扫描行数、join 方式，用于定位慢 SQL 与数据量导致的性能问题。还可查看锁与事务（SHOW PROCESSLIST、information_schema.innodb_trx）定位锁等待。数据问题排查需 SELECT 权限，联表查询验证字段对应关系。

数据库命令行是"数据问题"的直接取证工具。查询验证数据、EXPLAIN 看执行计划、processlist 看锁，三位一体定位数据与性能问题。

• 负载与资源指标
• top/vmstat 使用
• 瓶颈方向判断

load average 表示系统运行队列中的平均进程数，反映系统整体负载；CPU 使用率高说明 CPU 是瓶颈；IO wait（wa）高说明磁盘/IO 等待是瓶颈；内存压力表现为内存不足触发 swap（si/so 高）。用 top 看 CPU 使用率、内存、load 与各进程占用，用 vmstat 看 r（运行队列）、us/sy（用户/系统 CPU）、wa（IO wait）、si/so（swap in/out）。判断方向：load 高而 CPU 高→CPU 密集型；load 高而 wa 高→IO 瓶颈；load 高而 si/so 高→内存不足导致 swap；us 高为计算密集、sy 高为系统调用密集。快速定位让 top 与 vmstat 结合，先看整体再定位到进程。

资源瓶颈判断的核心是"看懂 top 与 vmstat 的关键列"。CPU、IO、内存三者的高负载表现不同，通过指标组合快速判断瓶颈方向。

• logrotate 轮转机制
• 保留周期影响
• 截断后排查

logrotate 按大小或时间定期切割日志（如按天、按 100M），并保留若干份历史（如保留 7 份）。切割时机影响排查：若按天切割，跨天问题需看多份日志；若按大小切割，大流量时可能切割频繁，异常可能被拆到多个文件。保留周期影响可回溯范围：周期短则历史日志被删，无法查旧问题。日志被截断（轮转或进程重启）时避免漏查：一是用 tail -f 前确认当前文件，轮转后需跟踪新文件（如用 tail -f -F 跟随文件名变化）；二是按时间跨多个轮转文件搜索；三是监控与日志平台（ELK）集中归档避免本地截断丢失。合理配置保留策略（如保留 7~30 天）保障排查。

轮转是"双刃剑"：防磁盘满但可能丢历史。排查要跨越切割点，用 -F 跟随、多文件搜索、集中归档来避免漏查。

• 压缩打包命令
• 文件传输命令
• 应用场景

tar 打包压缩：tar -czvf archive.tar.gz dir 打包并 gzip 压缩，tar -xzvf 解压；zip：zip -r a.zip dir 压缩，unzip a.zip 解压。scp 远程传输：scp -r 本地路径 用户@主机:路径 复制文件/目录到远程；rsync 增量同步：rsync -avz 源 目标，支持断点续传与增量，适合大文件与持续同步。测试场景中常用 tar 打包日志/测试产物，scp 传到共享或分析环境，rsync 同步大目录或增量传输。注意 scp/rsync 需要 SSH 权限与免密或密码认证。

打包用 tar/zip，传输用 scp/rsync。rsync 适合大文件增量同步，scp 适合简单单次复制，组合使用可高效收集与分发测试产物。

• 大文件定位
• 磁盘清理
• 安全删除

定位大文件：du -sh * 按目录列出占用大小定位大目录，find . -type f -size +100M 查找大于 100M 的文件，find . -type f -exec ls -lh {} \; 结合大小排序找出大文件。linux 还可 du -h --max-depth=1 | sort -rh 按大小排序。安全清理：先确认文件用途（日志、临时文件、旧备份），用 du -sh 确认占用，对可删文件（如旧的日志、.log 轮转文件、临时文件、缓存）用 rm 删除，或用 > 文件 清空日志而不删除文件句柄（避免影响正在写入的进程）。注意大文件删除前要确认是否被进程占用，避免误删。

定位大文件 = du 找目录 + find 找文件。清理讲究"先确认后删除"，对运行中进程的日志用清空而非删除，避免句柄问题。

• 环境变量命令
• 配置文件加载顺序
• 环境配置影响

env 查看当前环境变量；export 设置/导出环境变量使子进程可见（export VAR=value）；source 在当前 shell 执行脚本（source 文件 或 . 文件），使变量在本次会话生效。配置文件加载顺序：登录 shell 加载 /etc/profile、~/.bash_profile、~/.profile，非登录 shell 加载 ~/.bashrc；环境变量通常在配置文件里定义，依次加载可能覆盖。测试影响：环境变量决定服务连哪个库、哪个环境、开关状态，若配置错（如连错环境、开关未开）会导致测试环境行为异常。排查配置问题用 env 查看当前值，对比配置文件与预期，检查加载顺序与覆盖。

环境变量是"环境的路由"，配置加载顺序决定最终生效值。测试环境异常先查 env 与配置文件，确认环境指向与开关。

• 平台差异
• 路径与换行符
• 兼容性规避

主要差异：路径分隔符（Linux / vs Windows \）、换行符（Linux LF vs Windows CRLF）、权限模型（Linux rwx vs Windows ACL）、命令兼容性（Linux 命令 vs Windows cmd/PowerShell）。规避方法：脚本中统一用相对路径或跨平台路径处理（如 Python os.path、Java File.separator，避免硬编码分隔符）；配置文件统一用 LF 换行并避免 BOM（或用工具转换）；测试脚本配置差异环境用环境变量或脚本分支；权限判断用跨平台逻辑而非写死 755；CI 用统一的容器/镜像环境降低差异。测试用例要考虑平台差异导致的行为不同（如文件路径、大小写敏感）。

跨平台差异是"隐藏的坑"，尤其换行符与路径分隔符会导致脚本在另一端失败。规避核心是"抽象平台差异、统一环境、避免硬编码"。

• 结构化日志优势
• jq 字段提取聚合
• 落地要点

结构化日志（JSON 格式）相比纯文本 grep 的优势：字段可精确提取与聚合（按 traceId、错误码、耗时、服务筛选），无需依赖正则猜测文本位置；可做数值聚合（求平均耗时、分位数、按字段分组统计）；字段语义清晰，便于切分与关联。jq 是 JSON 处理工具，如 jq '.level' 提取字段、jq -r 'select(.level=="ERROR")' 过滤、jq 'group_by(.code) | map({code:.[0].code,count:length})' 分组统计。落地要点：日志统一输出 JSON 格式并固定字段 schema；关键字段（traceId、时间、级别、服务、耗时）必须存在；用 ELK 或 jq 分析；避免敏感信息入日志。落地后定位从"grep 猜"升级为"结构化查询"。

结构化日志的价值在"可机器分析"。jq 让字段提取与聚合精确且可重复，是纯文本 grep 的升级，落地关键是统一 schema 与关键字段。