企业官网建设流程全解析

Linux是后端开发和运维人员必须掌握的操作系统。无论是部署应用、排查故障还是性能调优，都离不开Linux命令行。但很多开发者只掌握cd、ls、ps等基础命令，面对CPU飙高、内存泄漏、磁盘满、网络不通等线上问题时缺乏系统的排查思路。本文整理Linux运维中最实用的命令和排查方法论，帮助读者快速定位和解决常见服务器问题。

一、系统信息与资源概览

登录服务器后，第一步是了解系统基本状况。uname -a查看内核版本，cat /etc/os-release查看发行版信息，uptime查看系统运行时间和负载均值，top或htop实时查看进程资源占用。负载均值（load average）三个数字分别表示1分钟、5分钟、15分钟的平均运行队列长度，对于CPU密集型任务，负载不超过CPU核心数即为正常；如果1分钟负载远高于15分钟，说明系统正在承受突发压力。

# 系统基本信息
uname -a # 内核版本
cat /etc/os-release # 发行版
uptime # 运行时间和负载
lscpu # CPU详细信息
free -h # 内存使用（人类可读格式）
df -h # 磁盘使用
du -sh /var/log/* # 目录大小排序

# 实时监控
top # 经典进程监控（按P排序CPU，按M排序内存）
htop # 更友好的交互式监控（需安装）
vmstat 2 # 每2秒输出虚拟内存统计
iostat -xz 2 # 每2秒输出IO统计（需sysstat包）

二、CPU问题排查

CPU使用率高是最常见的性能问题。排查思路是：先用top找到占用CPU最高的进程，再用top -Hp <PID>查看该进程下哪个线程占用最高，然后用jstack（Java应用）或pstack/gdb定位线程在做什么。如果是Java应用，还可以用Arthas等诊断工具直接查看方法调用栈。需要区分用户态CPU高（us）和系统态CPU高（sy）：用户态高通常是应用代码计算量大或死循环；系统态高可能是频繁系统调用、IO等待或内核问题。

# 找到CPU最高的进程
top -b -n 1 | head -20

# 查看进程下的线程
top -Hp 12345

# Java线程定位：将线程ID转为16进制，在jstack中搜索
printf '%x\n' 12346 # 线程ID转16进制
jstack 12345 | grep -A 20 0x3039

# 查看系统调用（需strace）
strace -p 12345 -c # 统计系统调用耗时
strace -p 12345 -e trace=network # 只看网络相关系统调用

# 火焰图（需要perf工具）
perf record -F 99 -p 12345 -g -- sleep 30
perf report -n --stdio

三、内存问题排查

内存问题包括内存使用率高、OOM（Out Of Memory）、内存泄漏。free命令输出中，available列才是真正可用的内存，buff/cache是系统用作缓存的内存，在需要时可以回收。不要看到used高就认为内存不足。排查OOM可以用dmesg | grep -i 'killed process'查看内核OOM Killer的日志。Java应用的内存问题需要区分堆内存和堆外内存：堆内存用jmap -heap和jstat -gcutil分析，堆外内存（直接内存、元空间、线程栈）用Native Memory Tracking（NMT）分析。

四、磁盘问题排查

磁盘问题主要是磁盘空间满和磁盘IO高。磁盘满用df -h查看各分区使用率，找到满的分区后用du -sh /* | sort -rh找到大文件或大目录。常见的磁盘占用大户包括日志文件（/var/log）、Docker镜像和容器（/var/lib/docker）、临时文件（/tmp）、core dump文件。日志文件可以用logrotate配置自动轮转和清理。磁盘IO高用iostat -xz 2查看哪个磁盘设备IO利用率高（%util接近100%说明磁盘瓶颈），再用iotop或pidstat -d找到占用IO最高的进程。

# 磁盘空间排查
df -h # 查看分区使用率
du -sh /var/* | sort -rh | head 10 # 找大目录
find / -type f -size +1G 2>/dev/null # 找大于1G的文件
find /var/log -name "*.log" -mtime +7 -delete # 删除7天前的日志

# 磁盘IO排查
iostat -xz 2 # 磁盘IO统计
iotop -oP # 实时查看IO最高的进程
pidstat -d 2 # 每2秒查看进程IO
lsof | grep deleted # 查看已删除但仍被进程占用的文件（空间未释放）

# inode满（文件数量过多）
df -i
find /path -type f | wc -l

五、网络问题排查

网络问题包括连接不通、端口不通、延迟高、丢包。排查思路是从底层到上层：先ping测试网络连通性，再telnet或nc测试端口，然后用curl测试HTTP服务，最后用tcpdump抓包分析。DNS问题用nslookup或dig测试域名解析。连接数过多用ss -s查看汇总，ss -antp查看具体连接状态。TIME_WAIT过多是高并发场景的常见问题，可以通过调整tcp_tw_reuse和tcp_fin_timeout参数缓解。

# 连通性测试
ping -c 4 192.168.1.100 # 测试网络连通
traceroute 192.168.1.100 # 路由追踪
mtr 192.168.1.100 # 组合ping+traceroute（需安装）

# 端口测试
telnet 192.168.1.100 8080 # 测试TCP端口
nc -zv 192.168.1.100 8080 # netcat测试端口
nc -ul 53 # 测试UDP端口

# DNS测试
nslookup api.example.com
dig api.example.com +trace

# HTTP测试
curl -v http://api.example.com/health
curl -w "\nHTTP Code: %{http_code}\nTotal Time: %{time_total}s\n" -o /dev/null http://api.example.com

# 连接状态
ss -s # 连接汇总
ss -antp | grep :8080 # 查看8080端口连接
ss -ant | awk '{print $1}' | sort | uniq -c # 按状态统计连接数

# 抓包
tcpdump -i any port 8080 -nn -vv # 抓取8080端口数据包
tcpdump -i eth0 -w capture.pcap # 保存到文件后用Wireshark分析

六、日志查看与分析

日志是排查问题的第一手资料。系统日志在/var/log目录下，CentOS/RHEL用/var/log/messages，Ubuntu/Debian用/var/log/syslog。systemd管理的服务用journalctl查看日志。应用日志通常在应用部署目录下。查看日志的常用命令组合：tail -f实时跟踪，grep过滤关键词，less分页查看，awk/sed做统计分析。对于大日志文件，不要直接用vim打开，应该用grep定位到相关行后再用less查看上下文。

# 系统日志
journalctl -u nginx -f # 实时跟踪nginx服务日志
journalctl -u nginx --since "1 hour ago" # 最近1小时的日志
journalctl -k --since "10 min ago" # 最近10分钟的内核日志
dmesg -T | tail -50 # 内核环形缓冲区日志

# 应用日志常用操作
tail -f app.log # 实时跟踪
tail -n 200 app.log # 最后200行
grep -n "ERROR" app.log | tail -20 # 找最近的错误
grep -C 5 "NullPointerException" app.log # 查看异常前后5行
less app.log # 分页查看（/搜索，q退出）
awk '{print $1}' app.log | sort | uniq -c | sort -rn | head 10 # 统计Top10

七、线上排查的通用方法论

面对线上问题，保持冷静，按照“先止损、再定位、后复盘”的顺序处理。止损优先：如果是流量突增导致服务不可用，先扩容或限流；如果是某个服务异常，先切流量或回滚版本。定位问题时遵循“由表及里、由简到繁”的原则：先看监控大盘（CPU、内存、磁盘、网络、应用指标），再看日志，最后深入代码。排查过程中做好记录，包括时间线、操作命令、现象变化，方便事后复盘。问题解决后必须复盘，找到根因并制定改进措施，避免同类问题再次发生。

结语

Linux运维能力的核心不是记住多少命令，而是建立系统的排查思路。CPU、内存、磁盘、网络四大类问题各有典型的排查路径，掌握top、vmstat、iostat、ss、tcpdump、journalctl这些核心工具，就能应对绝大多数线上问题。建议在平时就搭建好监控告警体系（Prometheus + Grafana），将排查经验沉淀为Runbook，这样线上出问题时才能快速响应、从容应对。