Linux 故障排查：系统卡、开不了机、磁盘写不进、网络断、DNS 挂、网站崩、启动慢

前言：本博客仅作记录学习使用，部分图片出自网络，如有侵犯您的权益，请联系删除

一、故障排除方法论

1、问题空间划分策略

二分法：通过每次测试将可能性分为两半，可快速缩小问题范围
排除法：每次测试都应设计为排除一类可能的原因
系统化测试：从最可能的原因开始，逐步进行测试，例如，如果网站访问超时，首先先检查其他网站是否可以访问，以确定问题是否出现在本地网络
避免重复测试：一旦某个测试结果排除了某个原因，立即通知团队，以便其他人据此调整策略

2、协同沟通机制

2.1、电话会议限制

电话会议存在较多局限性：单向沟通、信息传递效率低，技术信息传递困难、时间浪费、非生产性讨论、管理层干扰、沟通中断等。电话会议应作为最后手段使用，其他沟通方式更有效

2.2、直接对话场景

直接对话有助于更清晰地理解对方并允许多会话并行，但难以共享复杂技术信息，且通常无法记录会话内容，不利于事后分析和新成员跟进。直接对话适合团队成员同地办公，但不适合远程工作或非工作时间的问题处理。电话会议可能在这些情况下成为必要选择。理想情况下，应结合使用直接对话和其他沟通工具，以适应不同场景和需求，并确保沟通方式能够记录信息。

2.3、邮件协作规范

电子邮件是协作解决问题的有效方式，特别适用于非紧急问题，允许多个对话同时进行，便于双向交流，且易于粘贴IP地址、URL、命令，以及附加截图和日志信息。

它不是实时和交互式的，可能导致故障排除速度变慢。此外，长邮件列表难以管理和阅读，不同的回复风格可能导致重要信息被忽视。系统管理员可能用邮件作为监控报警通知，但大量报警邮件可能使关键会话邮件难以查找。最后，如果问题涉及邮件服务器本身宕机，电子邮件沟通方式将无法使用

2.4、实时聊天室

实时聊天室适合团队协作，提供即时交流和文件共享。新成员可以快速了解讨论进度。但要注意，不是所有聊天工具都保存记录，大量信息可能不易管理，且需要保护隐私。

3、快速简单测试优先

优先快速简单测试
快速定位问题
并行测试
执行慢速测试
检查物理连接

4、经验复用与记录

经验丰富的故障排除人员能够快速识别问题的根源，因为他们曾遇到过类似的问题。面对熟悉的症状时，回忆之前的解决方案通常能迅速解决问题，但也要注意不同问题可能产生相同的症状，避免过早下结论。记录问题和解决方案对于未来快速识别和解决问题至关重要。

5、记录问题和解决方案

记录问题及其解决方案对于故障排除至关重要。这个过程通常被称为事后析误，涉及团队成员聚集在一起，记录问题发生的原因、采取的隔离步骤以及结果，最终确定问题的根本原因，并采取措施防止问题再次发生

6、了解改动

7、了解系统如何工作

深入理解TCP/IP、DNS、Linux进程、编程和内存管理等技术，能提升故障排除的效率和准确性、对系统运作了解越深，解决问题的速度越快，预感更准确，避免无效劳动，快速排除问题原因。

8、谨慎使用Internet

在使用网络搜索前，需要对问题有准确和清晰的理解，以便于使用具体、有针对性的搜索词条，在复制、粘贴任何命令或代码前，必须确保完全理解它们，以避免问题恶化

9、抵制重启

重启往往掩盖了问题的根本原因，导致问题可能再次出现。重启系统应该作为最后的手段，在尝试了其他诊断步骤并收集了必要的信息之后才考虑

二、服务器为什么这么慢？耗尽了CPU、RAM和磁盘I/O资源

1、系统负载

平均系统负载是判断系统运行缓慢的关键指标。使用uptime命令查询

 $ uptime
 18:12:49 up 103 days, 8 min,2 users, load average: 0.71,0.58,0.30

1.1、什么是高平均负载

定义：高平均负载没有一个绝对的数值标准，它取决于负载产生的原因和系统的资源使用情况

负载类型：

CPU密集型：由等待CPU资源的进程引起
内存密集型：由于内存使用频繁，导致数据被移入交换区
I/O密集型：由于争夺磁盘或网络I/O资源的进程引起

负载飙升原因：可能是应用程序在不同时间点产生大量同步线程，导致系统资源竞争，随着进程完成，负载会下降

系统响应度：

CPU密集型系统通常比I/O密集型系统响应更快
I/O密集型系统可能在磁盘I/O饱和时响应缓慢，即使CPU和内存使用率不高
内存资源耗尽的系统可能因使用交换存储而消耗磁盘资源，导致进程变慢或停止

2、使用top命令解决负载问题

解决高负载问题时，使用top命令查看系统实时信息，包括运行时间、负载平均值、进程数量、内存使用情况及进程资源占用。top 默认按CPU使用率排序，便于快速定位高CPU占用进程。终止进程时，按K键，输入进程PID，确认终止即可

若需查看完整输出或保存信息，可使用批处理模式运行top命令。使用 -b 选项开启批处理模式，-n 选项控制刷新次数，

 $ top -b -n 1   # 可查看完整输出一次
 $ top -b -n 1 > top_output          # 将输出保存到文件top_output
 $ top -b -n 1 | tee top_output      # 同时查看输出并保存文件

2.1、了解top命令的输出

首先查看系统负载平均值（如0.27、0.23、0.19），判断系统是否过载，接着分析Cpu(s)行数据：us表示用户进程占用CPU时间百分比，sy为系统进程占用时间，ni是调整优先级后的进程占用时间，id是CPU空闲时间，wa是I/O等待时间，hi和si分别是硬件和软件中断时间，st是虚拟机中任务占用时间。

如果wa较高，可能是磁盘I/O问题；若id低且us或sy高，可能是CPU资源紧张。结合进程列表中的%CPU和%MEM列，可定位占用资源最多的进程

2.2、解决高用户时间的问题

当系统负载高且用户CPU时间百分比高但I/O等待时间低时，需通过top命令定位占用大量CPU资源的进程。在示例中，mysqld进程占用了53%的CPU时间，nagios2db_status占用了12%。这些百分比是基于单个CPU的，因此在多核CPU机器上可能会看到多个进程占用较高CPU时间。

   PID USER    PR  NI   VIRT   RES   SHR  S   %CPU   %MEM    TIME+     COMMAND
  9463 mysql   16  0    686m  111m  3328  S     53    5.5  569:17.64   mysqld
 18749 nagios   1  0    140m  134m  1868  S     12    6.6  1345:01     nagios2db_status
 24636 nagios  17  0   34660   10m   712  S      8    0.5   1195:15    nagios
 22442 nagios  24  0    6048  2024  1452  S      8    0.1   0:00.04    check_time.pl

如果只有一个或两个进程占用大量CPU资源，可以通过top命令终止这些进程（按K键输入PID）。如果多个进程共同导致高CPU负载，可能是系统任务过多，如Web服务器中的多个Apache进程或日志解析脚本。短期内可以通过终止或推迟部分进程来降低负载，但从长期来看，可能需要增加系统资源或将功能分拆到多台服务器上

2.3、解决内存不足的问题

top命令的内存信息输出行提供了关键的RAM使用情况。第一行显示总物理内存、已用内存、空间内存和缓存内存；第二行显示交换空间的总大小、已用和空闲情况。Linux会将文件缓存到RAM中以提高访问速度，因此即使显示的空闲内存很少，也可能是因为大量内存被缓存占用。实际可用内存应为总内存减去文件缓存。

 Mem: 1024176k total, 997408k used,  26768k free, 85520k  buffers
 Swap:1004052k tota1,   4360k used, 999692k free, 286040k cached

要判断是否真正存在内存问题，需查看实际使用内存减去文件缓存后的值是否很大，同时交换空间使用量是否很高。如果确实存在内存问题，可以通过top命令按下M键按RAM使用率排序，找出占用大量内存的进程并进行处理

   PID USER    PR  NI   VIRT   RES   SHR  S   %CPU   %MEM    TIME+     COMMAND
 18749 nagios  16   0   140m  134m  1868  S     12    6.6   1345:01    nagios2db_status
 9463 mysq1    16   0   686m  111m  3328  S     53    5.5    569:17    mysqld
 24636 nagios  17  0   34660   10m   712  S      8    0.5   1195:15    nagios
 22442 nagios  24  0    6048  2024  1452  S      8    0.1   0:00.04    check_time.pl

Linux内核的OOM（Out of Memory）终结者会在系统内存不足时介入，终止某些进程以释放内存。然而，OOM可能不会总是终止占用大量内存的进程，有时会误杀关键进程，导致系统不稳定甚至需要重启。OOM介入时，会在/var/log/syslog中记录相关日志，显示被终止的进程信息。

 $ cat /var/log/syslog
 1228419127.32453_1704.hostname:2,S:0ut of Memory: Killed process     21389(java). 1228419127.32453_1710.hostname:2,S:0ut of Memory: Ki1led process     21389(java).

2.4、解决高I/O等待时间问题

当I/O等待时间占CPU时间比重很高时，首先检查机器是否大量使用交换空间，因为硬盘速度远低于RAM，使用交换空间会导致性能下降。如果内存未耗尽，则需确定哪个进程占用了大量I/O资源。如果系统有多个分区，可使用iostat程序定位哪个分区正在执行大量I/O操作

安装iostat：基于Red Hat和Debian的系统可通过包管理工具安装sysstat包获取iostat。安装后，运行iostat可观察系统整体情况：

输出包括CPU信息和硬盘设备及其分区的I/O状态信息。各列含义如下：

tps：设备每秒的传输量。
Blk read/s：每秒从设备读取的数据量。
Blk wrtn/s：每秒向设备写入的数据量。
Blk read：从设备读取的总数据量。
Blk wrtn：写入设备的总数据量。

分析I/O负载：在高I/O负载状态下，观察每个分区的I/O负载，确定哪个分区的I/O操作最多。

运行iostat多次：可多次运行iostat获取当前精确的I/O状态，或指定刷新频率（如每2秒刷新一次）

 $ sudo iostat 2

iotop工具：iotop是top和iostat的混合体，可显示所有运行进程并按I/O统计信息排序。它需要2.6.20或更新的内核。基于Debian的系统可直接安装，基于Red Hat的系统需从第三方仓库安装。运行iotop后可看到类似以下输出：

 $ sudo iotop
 Total DISK READ: 189.52 K/S | Total DISK WRITE: 0.00 B/S
 TID  PRIO USER DISK      READ    DISK   WRITE   SWAPIN  IO> COMMAND
 8169 be/4 root 189.52K/S 0.00B/s 0.00% 0.00%    rsync --server --se
 4243 be/4 kyle 0.00B/s   3.79K/s 0.00% 0.00%    cli /usr/lib/gnome-
 4244 be/4 kyle 0.00B/s   3.79K/s 0.00% 0.00%    cli /usr/lib/gnome-
 1 be/4 root 0.00B/s 0.00B/s 0.00% 0.00% init
 # 在这个例子中，rsync进程执行了大量I/O读取操作。

3、问题发生后的高负载处理

sysstat包不仅包含iostat工具用于解决高I/O问题，还包含其他工具用于报告CPU和RAM使用情况。

3.1、配置sysstat

安装 sysstat 包。在基于 Debian 的系统（如 Ubuntu）中，sysstat 不会自动启用，需要手动修改 /etc/default/sysstat 文件，将 ENABLED="false" 更改为 ENABLED="true"。

在基于 Red Hat 的系统上，可能需要修改 /etc/sysconfig/sysstat文件，调整HISTORY选项以记录超过 7 天的统计信息。对于这两种系统，统计信息默认每 10 分钟收集一次，并在每天午夜前分割统计文件，这些操作由 /etc/cron.d/sysstat脚本执行。如果需要更改数据收集频率，可以修改该脚本。

3.2、查看CPU统计信息

sysstat 将统计信息存储在 /var/log/sysstat或 /var/log/sa文件夹中，文件名以sa开头，后跟当天日期（如sa03）。使用 sar工具可以查看这些统计信息。默认情况下，sar输出当天的 CPU 统计信息：

 $ sar
 Linux 2.6.24-22-server (kickseed) 01/07/2012
 07:44:20 PM CPU %user %nice %system %iowait %steal %idle
 07:45:01 PM all 0.00   0.00   0.54    0.00    0.00 99.46
 07:55:01 PM all 0.20   0.00   0.51    0.00    0.00 99.29
 ...
 Average: all 0.32 0.00 1.12 0.78 0.00 97.78

从输出中可以看到 CPU 的统计信息，包括用户时间、系统时间、I/O 等待时间等，最后一行提供了平均值

3.3、查看 RAM 统计信息

 $ sar -r
 Linux 2.6.24-22-server (kickseed) 01/07/2012
 07:44:20 PM kbmemfree kbmemused %memused kbbuffers kbcached kbswpfree kbswpused %swpused kbswpcad
 07:45:01 PM    322064    193384  37.52  16056  142900  88316  0  0.00
 07:55:01 PM    318484    196964  38.21  17156  144672  88316  0  0.00
 ...
 Average: 216241 73804 32.36 173900 221888 88316 0 0.00

可以看到内存使用情况，包括空闲内存、已用内存、缓冲区和缓存的大小，以及交换空间的使用情况

3.4、查看磁盘统计信息

 $ sar -b
 Linux 2.6.24-22-server (kickseed) 01/07/2012
 07:44:20 PM tps   rtps wtps  bread/s  bwrtn/s
 07:45:01 PM 8.03 0.00  8.03  0.00     106.61
 07:55:01 PM 8.78 0.14  8.64  3.35     127.59
 ...
 Average: 8.11 0.04 8.06 1.67 102.52

可以看到每秒传输的数据量（tps）、读取和写入的数据量（rtps 和 wtps）、每秒读取和写入的数据量（bread/s 和 bwrtn/s）

3.5、查看所有统计信息

使用 sar -A 选项可以查看所有类型的统计信息，包括负载平均值、CPU 负载、RAM、磁盘 I/O、网络 I/O 等

 $ sar -A

3.6、查看特定时间段的统计信息

 $ sar -s 20:00:00 -e 20:30:00       # 使用s和e指定开始时间和结束时间
 $ sar -f /var/log/sysstat/sa06      # 使用-f选项指定统计信息文件的路径

三、为什么系统无法启动？解决启动问题

1、Linux启动流程

BIOS初始化硬件并检测启动设备，按启动顺序找到可启动设备。硬盘启动时，BIOS读取MBR启动代码，启动GRUB。GRUB加载Linux内核和initramfs，提供菜单供选择操作系统或修改参数。内核启动时解压initramfs到RAM，运行init脚本检测硬件并挂载根文件系统，之后执行/sbin/init程序接管启动流程，启动其他系统进程。Ubuntu服务器使用Upstart作为init程序，但保留SystemVinit的结构和运行等级机制

2、BIOS启动顺序

如果系统无法进入GRUB提示界面，可能是BIOS启动顺序被更改或硬盘驱动器出现问题。要修正启动顺序，可在开机时按下特定按键（如Del、F1、F2或Esc）进入BIOS配置界面，找到Boot或Advanced选项下的启动顺序设置，将硬盘设置为首选启动设备。如果无法进入GRUB提示界面，可能是GRUB被擦除或硬盘驱动器失灵，需尝试修复GRUB以确认磁盘是否可用

3、修复GRUB

（1）确认GRUB问题类型

若无法进入 GRUB 提示界面，可能是 GRUB 被移除或启动顺序错误
若看到“loading stage 1.5 failed”或 grub>提示符，说明 GRUB 部分加载失败
若 GRUB 菜单加载成功但启动失败，可能是配置文件错误或分区 UUID 改变

（2）从活动系统中修复

进入系统后，编辑 GRUB 配置文件：
- GRUB1：/boot/grub/menu.lst
- GRUB2：/etc/default/grub，修改后运行update-grub。
重新安装 GRUB 到 MBR：grub-install /dev/sda（替换为实际设备）

（3）通过恢复磁盘修复

Ubuntu 恢复磁盘：
- 启动后选择“重新安装 GRUB 启动加载器”。
- 或进入 shell 窗口运行update-grub，完成后重启。
Red Hat/CentOS 恢复磁盘：
- 启动时输入linux rescue。
- 挂载根分区：chroot /mnt/sysimage。
- 重新安装 GRUB：grub-install /dev/sda。

4、禁止启动界面

当Linux系统启动失败时，若已通过GRUB界面但系统仍报错，需查看详细调试信息以定位问题。此时可进入GRUB菜单（启动时按Esc或Shift），按E键编辑启动项，找到以linux或kernel开头的内核启动参数行，去除quiet和splash参数，并添加nosplash参数以禁用启动界面，确保所有调试信息可见。编辑完成后退出并重启，即可在启动过程中看到完整输出，便于排查故障。

5、无法挂载根文件系统

当Linux系统启动时无法挂载根文件系统，通常是由于内核参数配置错误、设备识别问题、文件系统损坏或硬件故障等原因引起的。

根内核参数：

内核通过GRUB传递的root=参数确定根文件系统的位置，该参数可以指定为设备名（如/dev/sda2）、标签（如LABEL=/）或UUID（如UUID=xxx）。推荐使用UUID，因为它能唯一标识分区，避免因设备名变化或标签重复导致的挂载失败

根设备更改：

如果系统报错如“ALERT! /dev/sda2 does not exist”，可能是由于添加了新硬盘导致设备名变化。此时可进入GRUB菜单，编辑启动项，将root=参数修改为正确的设备名或UUID。若不确定设备信息，可使用fdisk -l或blkid命令查看分区结构和UUID。

若系统使用标签挂载根分区，需确保标签唯一。若存在标签冲突，可使用e2label工具修改标签，或在GRUB中临时指定设备名启动后再更新配置

根分区损坏或失效：

系统可能进入initramfs shell，提示文件系统错误。此时可使用fsck（适用于ext系列）或xfs_repair（适用于XFS）等工具进行修复。若无法进入系统，可通过GRUB添加rd.break参数进入紧急模式，手动执行修复命令。

为防止类似问题，建议定期检查磁盘健康状态，确保/etc/fstab和GRUB配置文件中使用的UUID或标签准确无误，并保持文件系统完整性

6、无法挂载二级文件系统

当Linux系统启动时，除了根文件系统外，还会根据/etc/fstab文件自动挂载其他文件系统，如/var、/home等。如果这些分区因设备名变更、标签冲突、UUID变化或文件系统损坏而无法挂载，系统将中止启动流程并进入shell界面。此时应检查/etc/fstab中的配置，确认设备名、标签或UUID是否与实际分区一致。若设备名发生变化，可临时修改启动参数或进入恢复模式，使用fdisk -l或blkid命令确认分区信息，并更新/etc/fstab中的挂载配置。若文件系统损坏，可使用fsck或xfs_repair等工具进行修复。确保所有自动挂载的分区信息准确无误，是避免启动失败的关键。

四、磁盘无法写入？解决磁盘满或磁盘损坏问题

1、磁盘满

使用df -h工具列出挂载的所有分区信息：分区大小、已用空间和可用空间。

 $hf -h
 Filesystem      Size Used Avail Use% Mounted on
 /dev/sda1       7.8G 7.4G 60K   100% /
 none            245M 19K 245M     1% /dev
 none            249M   0 249M     0% /dev/shm
 none            249M 36K 249M     1% /var/run
 none            249M   0 249M     0% /var/1ock
 none            249M   0 249M     0% /1ib/init/rw

可看到系统仅挂载了一个分区/dev/sda1，使用率100%，对于一个已经装满的文件系统，怎么解决

（1）保留区块

Linux文件系统默认保留5%空间仅供root用户使用，用于应急和防止碎片。用df查看磁盘使用率时，这部分空间被计入已用，因此显示比例偏高。可用tune2fs -l /dev/sda1 | grep -i "block count"查看保留块数量

 $ sudo tune2fs -l /dev/sdal | grep -i "block count"
 B1ock count:            2073344
 Reserved block count:   103667

（2）找到占用空间最大的目录

使用df查看磁盘空间后，可用du命令找出具体占用空间的目录。执行sudo du -ckx | sort -n > /tmp/duck-root生成按空间排序的目录列表，再用tail查看最大的目录。常见空间占用大户如/usr、/var/log等。若日志文件过大，可用

 $sudo sh -c "> /var/log/messages"

清空，或压缩、删除旧日志。为防止日志过度增长，可调整 /etc/logrotate.conf 或 /etc/logrotate.d/ 中的配置，启用自动压缩和轮转。

2、节点不足

当文件系统显示已满但 df 显示仍有空间时，可能是inode耗尽。inode是存储文件元数据的数据结构，每个文件占用一个inode。若系统中存在大量小文件，可能耗尽inode，导致无法创建新文件。

 $df -i

使用df -i 可查看inode使用情况。若inode已用完，可删除大量小文件、将其移动到其他文件系统、压缩成单个文件，或备份后重新格式化文件系统以获得更多inode。

3、文件系统只读

当Linux系统出现文件系统只读（Read-only file system）错误时，通常是由于文件系统检测到错误而自动进入保护模式，防止数据进一步损坏。此时，普通用户无法写入文件，root用户也可能受限。

快速处理步骤如下：

尝试重新挂载为读写模式 如果文件系统不是根分区，可尝试重新挂载为读写模式：
```
 sudo mount -o remount,rw /home
```
若成功，说明问题可能是临时挂载异常。
检查系统日志确认错误原因 使用以下命令查看是否有I/O错误或文件系统错误：
```
 dmesg | egrep "ext[2..4]|xfs"
```
若日志中出现“Remounting filesystem read-only”或“EXT3-fs error”等字样，说明文件系统存在错误。
根分区或重挂载失败时的处理 如果是根分区或重新挂载失败，建议重启系统。重启过程中系统会自动进行文件系统检查（fsck）并尝试修复错误。如果重启后仍无法挂载，需进入单用户模式或救援模式，手动执行修复命令。
手动修复文件系统（适用于非根分区） 若文件系统不是根分区，可先卸载再修复：
```
 sudo umount /dev/sdXN
 sudo fsck -y /dev/sdXN
```
修复完成后重新挂载即可

修复文件系统前务必备份重要数据，避免数据丢失，若频繁出现此类问题，建议检查磁盘健康状态（如使用smartctl工具）或排查是否存在硬件故障

这种只读机制是Linux系统的一种保护策略，目的是在发现异常时防止数据进一步损坏，因此不建议强行关闭此机制，除非明确了解风险

4、修复损坏的文件系统

当Linux系统因意外断电、硬件故障或系统崩溃导致文件系统损坏时，可使用fsck命令进行检查和修复。fsck（File System Consistency Check）是Linux系统中用于检查和修复文件系统错误的实用工具。

修复步骤如下：

进入救援模式 若系统无法正常启动，需使用LiveCD/USB或进入单用户模式，确保文件系统未被挂载。
卸载文件系统 在修复前，必须确保文件系统已卸载，否则可能造成进一步损坏。可使用umount命令卸载分区。
运行fsck命令 使用fsck命令检查并修复文件系统。常用选项包括：
1. -y：自动修复所有错误，无需用户干预。
2. -f：强制检查，即使文件系统看起来正常。
3. -C：显示进度条，便于观察修复进度。
4. -V：显示详细执行过程。
例如，修复/dev/sda5分区：
```
 sudo fsck -y -C /dev/sda5
```
处理超级块损坏 若文件系统损坏严重，无法找到主超级块，可使用备用超级块进行修复。首先，使用mke2fs -n /dev/sda5命令列出所有超级块的位置，然后选择一个备用超级块，使用fsck -b <备用超级块编号> -y /dev/sda5命令进行修复。
重新挂载文件系统 修复完成后，使用mount命令重新挂载文件系统，以便正常使用。

5、修复软RAID

在Linux软RAID系统中，硬盘故障是常见问题，掌握RAID故障检测与修复方法对系统维护至关重要。以下是基于搜索结果整理的简洁操作指南：

5.1、RAID故障检测方法

查看RAID状态 使用以下命令查看RAID阵列状态：
```
 cat /proc/mdstat
 sudo mdadm --detail /dev/md0
```
若某磁盘状态为failed或阵列状态为degraded，说明存在故障。
检查邮件通知
系统通常配置为在RAID故障时发送邮件通知root用户，可检查邮件或配置/etc/mdadm/mdadm.conf中的MAILADDR选项。

5.2、RAID驱动器更换步骤

标记故障磁盘并移除 若磁盘未自动标记为故障，可手动标记并移除：

 sudo mdadm --fail /dev/md0 /dev/sdX
 sudo mdadm --remove /dev/md0 /dev/sdX
 
 # 也可合并为一条命令
 sudo mdadm /dev/md0 --fail /dev/sdX --remove /dev/sdX

移除后，故障磁盘将不再显示在/proc/mdstat中。

添加新磁盘 插入新磁盘后，确保其容量不小于原磁盘，并添加到RAID阵列：
```
 sudo mdadm --add /dev/md0 /dev/sdY
```
添加后，RAID将自动开始重建。

5.3、RAID故障修复与重建

查看重建进度 使用以下命令查看重建状态：
```
 cat /proc/mdstat
 sudo mdadm --detail /dev/md0
```
重建时间取决于磁盘大小与系统性能。
更新RAID配置 修复完成后，更新配置文件以确保新配置生效：
```
 sudo mdadm --detail --scan >> /etc/mdadm/mdadm.conf
 sudo update-initramfs -u
```
这确保系统在启动时能正确识别RAID阵列。
检查文件系统完整性 重建完成后，建议检查文件系统是否损坏：
```
 sudo fsck -n /dev/md0
```
若发现问题，可使用fsck -y进行修复。

5.4、特殊情况处理

备用超级块修复 若文件系统严重损坏，可使用备用超级块进行修复：

 sudo mke2fs -n /dev/sdX  # 查看备用超级块位置
 sudo fsck -b 8193 -y /dev/sdX  # 使用备用超级块修复

RAID阵列未自动组装 若RAID阵列未自动启动，可尝试手动组装：
```
 sudo mdadm --assemble --scan
```
或手动指定设备：
```
 sudo mdadm --assemble /dev/md0 /dev/sdb1 /dev/sdc1
```
若配置文件丢失，可使用备份文件恢复：
```
 sudo mdadm --assemble --config=/path/to/backup/md0.conf /dev/md0
```

5.5、预防措施

定期备份数据：即使RAID提供冗余，定期备份仍是防止数据丢失的最佳实践。
监控RAID状态：使用mdadm --monitor或配置邮件通知，及时发现并处理故障。

五、服务器宕机

1、服务器A不能和服务器B通信

1.1、客户端或服务器问题

当服务器 dev1 无法访问 web1 时，可通过同网络中的另一台服务器 dev2 进行交叉验证，快速定位故障范围。若 dev2 也无法访问 web1，说明问题可能出在 web1 本身或网络连接上；若 dev2 能正常访问 web1，则问题集中在 dev1。假设 dev2 能访问 web1，接下来应重点排查 dev1 的网络配置、路由表、DNS 设置、防火墙规则及服务状态，逐步缩小故障范围，定位并解决问题。

1.2、链路是否接通

故障排除第一步在客户端，先确认客户端与网络的物理连接是否正常。使用ethtool工具验证链路状态，若不确定接口，可运行/sbin/ifconfig查看所有网络接口。以eth0为例，若输出中Link detected: yes，表明设备与网络物理连通；若为no，需检查网线、交换机等物理连接。确认链路畅通后，可继续后续网络测试

1.3、接口是否启用

确认物理连接正常后，需检查网络接口配置。使用ifconfig eth0查看接口信息，关键看第二行是否显示正确的IP地址和子网掩码。

 $ sudo ifconfig eth0
 eth0    Link encap:Ethernet Hwaddr 00:17:42:1f:18:be
         inet addr:10,1.1.7 Bcast:10.1.1.255 Mask:255.255.255.0
         inet6 addr:fe80::217:42ff:fe1f:18be/64 Scope:Link
         UP BROADCASTMULTICAST MTU:1500 Metric:1
         RX packets:l errors:0 dropped:0 overruns:0 frame:0
         TX packets:1l errors:0 dropped:0 overruns:0 carrier:0
         co1lisions:0 txqueuelen:1000
         Rx bytes:229(229.0B)Tx bytes:2178(2.1 KB)
         Interrupt:10

若接口未启用，可执行sudo ifup eth0启动。若配置错误或无效，需检查配置文件：Debian系查看/etc/network/interfaces</u>，Red Hat系查看/etc/sysconfig/network-scripts/ifcfg-eth0。若使用DHCP但未获取IP，应排查DHCP服务器是否正常工作

1.4、是否连通本地网络

确认网络接口已激活后，需检查默认网关配置及网关可达性。使用route -n查看路由表，关注以default开头的行，确认默认网关IP是否正确。

 $sudo route -n
 Kernel IP routing table
 Destination Gateway     Genmask         Flags Metric Ref    Use     Iface
 10.1.1.0    *           255.255.255.0   U     0       0     0       eth0
 default     10.1.1.10   0.0.0.0         UG    100     0     0       eth0

若未设置网关或需跨子网通信，需修改配置文件：Debian系检查/etc/network/interfaces，Red Hat系检查/etc/sysconfig/network-scripts/ifcfg-，或通过DHCP获取时确保服务器配置正确。配置完成后，重启网络服务使更改生效。

接着使用ping -c 5 <网关IP>测试网关连通性。若能ping通，说明本地网络配置正常；若不通，可能是网关限制ICMP、交换机端口VLAN配置错误，或硬件故障。此时可尝试ping同子网其他主机，或使用traceroute诊断路径。若问题依旧，需进一步检查网络设备或联系管理员

1.5、DNS是否工作

确认可以与网关通信后，需测试 DNS 是否正常工作。nslookup 和 dig 工具都可用于排查 DNS 问题，执行基本的域名解析测试。使用 nslookup 检查 DNS 是否可以将域名 web1 解析成 IP 地址。

 $ nslookup web1
 Server: 10.1.1.3
 Address: 10.1.1.3#53
 Name: webl.example.net
 Address: 10.1.2.5

若返回正确的 IP 地址，说明 DNS 正常工作。若出现错误，如连接超时或无法找到域名，需检查 /etc/resolv.conf 文件中的 DNS 服务器配置，确保已正确配置 DNS 服务器地址。若 DNS 服务器无法访问，需检查网络连接或联系网络管理员。

1.6、是否可以路由到远程主机

排除DNS故障后，需测试到远程主机的路由。若能ping通web1，说明数据包可路由至主机，继续测试远程端口是否开放。若无法ping通web1，尝试ping同网络其他主机，以判断是web1宕机、访问被阻止，还是路由问题。若均无法ping通，表明数据包路由异常，此时应使用traceroute工具检测路由路径。

 --成功的路由信息
 $ traceroute 10.1.2.5
 traceroute to 10.1.2.5(10.1.2.5),30 hops max, 40 byte packets
 1 10.1.1.1(10.1.1.1)5.432 ms 5.206 ms 5.472 ms
 2 webl(10.1.2.5)8.039ms 8.348 ms 8.643 ms
 
 --失败的路由信息
 $ traceroute 10.1.2.5
 traceroute to 10.1.2.5(10.1.2.5),30 hops max,40 byte packets
 1 10.1.1.1(10.1.1.1)5.432 ms 5.206 ms 5.472 ms
 2 * * *
 3 * * *

traceroute会显示数据包从本机到目标主机间的每一跳路由，若某跳出现星号或超时，表明问题出在对应路由器或线路上。若网络限制ICMP，可安装tcptraceroute工具，通过TCP协议进行路由追踪，使用方法与traceroute相同。

1.7、远程端口是否开放

当可以路由到目标机器但无法访问其Web服务器的80端口时，需验证端口是否开放。使用telnet命令测试连接

 $ telnet 10.1.2.5 80
 Trying 10.1.2.5...
 telnet: Unable to connect to remote host: Connection refused

若返回“Connection refused”，可能是端口未开启或防火墙限制。若telnet能连接，说明网络无问题，需检查服务器上的Web服务配置。更推荐使用nmap工具测试端口，因为它能检测到防火墙的存在。使用nmap -p 80 10.1.2.5命令

 $nmap -p 80 10.1.2.5
 Starting Nmap4.62(http://nmap.org)at 2009-02-05 18:49 PST
 Interesting ports on webl(10.1.2.5):
 PORT STATE SERVICE
 80/tcp filtered http

若端口状态为“filtered”，表明防火墙阻挡了数据包，需检查网关和服务器上的防火墙规则，确认80端口是否被阻挡。

1.8、在本地测试远端主机

当确认网络无问题后，需在主机端检查80端口是否可用。首先，使用netstat -lnp | grep :80命令查看80端口是否被监听。若输出显示0.0.0.0:80或10.1.2.5:80，说明Apache进程正在监听80端口；若无输出，需启动Apache服务。

若端口监听正常，检查防火墙规则。使用iptables -L查看防火墙状态。

 $ 5 sudo /sbin/iptables -L
 Chain INPUT (poliCy ACCEPT)
 target          prot opt source             destination
 
 Chain FORWARD (pO]iCy ACCEPT)
 target          prot opt source             destination
 
 Chain OUTPUT (poliCy ACCEPT)
 target          prot opt source             destination

若默认策略为DROP或存在限制80端口的规则（如REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80），需修改规则允许80端口流量，或调整默认策略为ACCEPT。

2、网络速度较慢的故障排查

2.1、DNS的问题

DNS故障会导致网络性能极差，如DNS请求超时（如30秒后才会尝试备用服务器）。dig或nslookup可检测DNS问题，但DNS故障会以意想不到的方式影响网络速度，因很多服务依赖DNS解析主机名。此外，ping、traceroute、route、netstat、iptables等工具在DNS故障时功能会退化，它们默认尝试将IP地址解析为主机名，若DNS查询失败，命令执行会拖延。为绕过DNS，可使用这些命令的-n选项，禁止IP地址解析为主机名，从而获得准确的故障诊断结果。

2.2、通过traceroute查找网络缓慢的原因

当网络连接慢且非带宽问题时，traceroute可定位瓶颈，显示数据包每跳响应时间。若某跳时间骤升或持续偏高，表明该区域可能存在网络拥塞或硬件问题。使用-n选项禁用DNS解析可加快排查速度。

2.3、使用iftop查看宽带使用情况

找出占用带宽的进程：使用工具如iftop，它不关心进程，而是列出占用带宽的网络连接。安装后运行iftop命令（需要root权限），界面会显示网络接口的整体流量状况、源IP与目标IP间的数据传输速率，以及发送和接收数据的统计。按P键可以切换显示或隐藏所有端口，按S或D键可分别只显示源主机或目标主机的端口。若DNS解析慢，可使用-n选项禁用解析功能。

3、抓取数据包

抓取数据包是排查底层网络问题的有效方法，抓取数据包时，最有效的方法是在通信的两端同时抓取，尤其是当两台主机之间有路由器或防火墙时

3.1、使用tcpdump

tcpdump是一个强大的命令行抓包工具，可在所有Linux系统中使用，需在root权限下运行。默认情况下，它会扫描网络接口，捕获并解析数据包。使用tcpdump -n命令可快速捕获数据包，而不将IP解析为主机名，避免降低速度

 sudo tcpdump -n host web1   # 捕获特定主机的数据包
 sudo tcpdump -n port 80 or port 443     # 捕获特定端口的数据包
 sudo tcpdump -w output.pcap     # 保存数据包到文件
 sudo tcpdump -C 10 -w output.pcap   # 限制文件大小
 sudo tcpdump -C 10 -W 5 -w output.pcap      # 分卷存储
 sudo tcpdump -n -l host web1 | tee outputfile   # 实时查看并保存数据包
 sudo tcpdump -n -r output.pcap      # 从文件读取数据包

3.2、使用wireshark

Wireshark是一个强大的图形化数据包分析工具，提供比tcpdump更直观的界面和高级功能。

六、主机名无法解析，解决DNS服务器问题

1、DNS客户端故障排除

DNS故障排除首先应在客户端进行，使用nslookup或dig工具可检测DNS服务器问题。

1.1、未配置名称服务器或者无法访问名称服务器

 $ nslookup webl
 ;; connection timed out; no servers could be reached

检查/etc/resolv.conf：若nslookup提示connection timed out; no servers could be reached，需检查该文件是否配置了nameserver，若无则添加正确的DNS服务器IP。

测试DNS服务器连通性：用ping命令测试与DNS服务器的连接，若同子网内无法ping通，可能是DNS服务器宕机。

手动指定DNS服务器测试：使用nslookup web1 10.1.1.3或dig web1.example.net @10.1.1.3直接对DNS服务器进行查询，确认其是否正常工作。

检查DNS配置与防火墙：确保DNS服务已启动且防火墙未拦截UDP 53端口。

1.2、丢失查询路径或名称服务器问题

处理NXDOMAIN错误：若nslookup返回server can't find web1: NXDOMAIN，可能是域名不在DNS搜索路径中。尝试使用完全限定域名（如web1.example.net）进行解析，若成功，可将域名添加到/etc/resolv.conf的search行中。

 $ nslookup webl
 Server: 10.1.1.3
 Address: 10.1.1.3#53
 ** server can't find webl: NXDOMAIN

检查名称服务器配置：若完全限定域名也无法解析，需检查名称服务器的区域配置是否正确。若为迭代名称服务器，可通过查询其他域测试迭代过程是否正常。若其他域解析正常，问题可能出在包含目标区域的远程名称服务器上。

2、DNS服务器故障排除

dig是DNS故障排除的实用工具，提供详尽的DNS查询信息。

基本用法：dig webl.example.net返回A记录，包括IP地址（10.1.2.5）和TTL（300秒）。
额外信息：输出包含权限部分（NS记录，列出区域的名称服务器）和附加部分（NS服务器的A记录），方便后续查询。
查询详情：显示查询时间、服务器和响应大小，有助于诊断DNS性能问题。
指定记录类型：通过添加记录类型（如NS、MX），可查询特定DNS记录，例如dig example.net NS查看名称服务器。

2.2、跟踪DNS查询

DNS递归解析：当查询DNS记录时，本地DNS服务器会执行递归解析，依次向根名称服务器、顶级域名称服务器和权威名称服务器发送请求，直到获取到最终的IP地址。

使用dig +trace：执行dig web1.example.net +trace可追踪完整的递归解析过程，显示每一步请求的服务器及响应信息。
解析流程示例：
- 本地DNS服务器（192.168.0.1）返回根名称服务器列表。
- 向根名称服务器（如c.root-servers.net）请求，返回.net名称服务器列表。
- 向.net名称服务器（如e.gtld-servers.net）请求，返回example.net的权威名称服务器列表。
- 向权威名称服务器（如ns2.example.net）请求，获取web1.example.net的IP地址。

输出解读：以;;开头的行显示请求发送的服务器及响应时间，帮助理解递归解析的每一步。

2.3、递归名称服务器的问题

现象：若递归DNS服务器宕机，客户端解析域名时会延迟约30秒，或出现REFUSED错误。
检查配置：查看/etc/resolv.conf中的DNS服务器列表，用nslookup或dig测试其连通性。
诊断工具：dig提供详细错误信息，如status: REFUSED表明递归请求被拒绝。
BIND配置：检查/etc/bind/named.conf及其包含文件，确认allow-recursion选项是否包含客户端IP，或recursion是否被设为no。
修复：调整allow-recursion或移除recursion no，重启BIND服务以应用更改。

2.4、什么情况下没有执行更新

DNS缓存与TTL：DNS记录有TTL，过期后服务器才重新解析。若更改未生效，可等待缓存过期或提前调低TTL。
检查名称服务器：用dig直接查询官方名称服务器，若返回旧记录，可能是区域文件错误或区域传输问题。
区域语义错误：更改区域文件后，BIND可能因语法错误忽略更改。检查/var/log/syslog或/var/log/messages中的错误信息，修正后重载BIND。
区域传输问题：
- 主服务器：检查是否发送通知，序列号是否更新。用dig example.net SOA查看主服务器。
- 从服务器：检查日志，确认是否收到通知并完成传输。若拒绝通知，检查配置是否正确。
- 序列号问题：若从服务器序列号过大，删除其区域文件并重启BIND，重新从主服务器获取更新。

七、网站宕机，追踪Web服务器问题

1、服务器是否正在运行

1.1、远程端口是否开放

使用telnet：执行telnet 10.1.2.5 80，若返回“Connection refused”，则可能是端口未启动（如Apache未运行）或防火墙阻挡。
使用nmap：执行nmap -p 80 10.1.2.5，若状态为“filtered”，表明防火墙丢弃了数据包，需检查网关和主机的防火墙规则。

1.2、在本地测试远程主机

测试监听端口：登录Web服务器，使用sudo netstat -lnp | grep :80检查80端口是否被监听。若输出显示0.0.0.0:80或特定IP地址，说明Apache正在监听该端口；若无输出，需启动Apache服务。
检查防火墙规则：执行sudo /sbin/iptables -L -n，若存在REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80规则，需修改防火墙配置以允许80端口流量。

2、使用命令行测试Web服务器

2.1、使用curl测试Web服务器

curl测试：执行curl http://www.example.net，若返回网页内容，说明Web服务器正常；若返回curl: (7) couldn't connect to host，则连接失败。
获取额外信息：使用-w参数，如curl -w "%{http_code} %{time_total} %{size_download} %{content_type}\n" http://www.example.net，可查看HTTP状态码、请求时间、数据大小和内容类型。

2.2、使用telnet测试Web服务器

连接服务器：执行telnet www.example.net 80，若连接成功，输入HTTP命令。
发送HTTP请求：输入GET / HTTP/1.1和host: www.example.net，按回车获取响应。
查看响应信息：服务器返回的HTTP状态码、日期、服务器信息等内容可用于诊断。
退出telnet：按Ctrl-]退出。

3、HTTP状态码

3.1、HTTP状态码分类

分类	分类描述
1**	信息，服务器收到请求，需要请求者继续执行操作
2**	成功，操作被成功接收并处理
3**	重定向，需要进一步的操作以完成请求
4**	客户端错误，请求包含语法错误或无法完成请求
5**	服务器错误，服务器在处理请求的过程中发生了错误

1xx状态码（信息响应）：

状态码	状态码英文名称	中文描述
100	Continue	服务器已收到请求头，客户端可继续发送请求体
101	Switching Protocols	服务器同意切换协议（如从 HTTP 切换到 WebSocket）

2xx状态码（成功）：

状态码	状态码英文名称	中文描述
200	OK	请求成功，资源正常返回（如网页加载成功）
201	Created	资源已创建（如 POST 请求成功后返回新资源）
202	Accepted	请求已接收，但尚未处理完成（如异步任务）
204	No Content	请求成功，但无返回内容（如删除操作成功）

3xx状态码（重定向）：

状态码	状态码英文名称	中文描述
301	Moved Permanently	资源永久重定向到新地址（浏览器会缓存新地址）
302	Found	资源临时重定向到新地址（下次可能恢复原地址）
304	Not Modified	资源未修改，可直接用本地缓存（协商缓存生效时返回）

4xx状态码（客户端错误）：

状态码	状态码英文名称	中文描述
400	Bad Request	请求语法错误，服务器无法理解（如参数格式错误）
401	Unauthorized	未授权，需身份验证（如未登录或 Token 失效）
403	Forbidden	服务器拒绝执行（如无权限访问资源）
404	Not Found	资源不存在（路径错误或资源已被删除）
408	Request Time-out	服务器等待客户端发送的请求时间过长，超时

5xx状态码（服务端错误）：

状态码	状态码英文名称	中文描述
500	Internal Server Error	服务器内部错误（如代码崩溃或配置问题）
502	Bad Gateway	网关错误（如反向代理服务器无法从上游获取响应）
503	Service Unavailable	服务不可用（如服务器过载或维护中）
504	Gateway Time-out	网关超时（如上游服务器未及时响应代理请求）

4、分析Web服务器的日志

日志位置：Apache日志位于/var/log/apache2/，Nginx位于/var/log/nginx/，包含access.log（访问日志）和error.log（错误日志）。
日志格式：包含IP地址、时间戳、HTTP请求、状态码、字节数和User-Agent等信息。
分析工具：
- grep：提取特定IP的日志，如egrep '10.1.2.3' /var/log/apache2/access.log。
- wc -l：统计请求次数，如egrep '10.1.2.3' /var/log/apache2/access.log | wc -l。
- perl：提取并统计IP请求数据，如perl -ne 'if(/(\d+\.\d+\.\d+\.\d+).*?04\/Jul\/2012/){$v{$1}++} END{foreach(keys %v){print "$v{$_}\t$_\n"}}' /var/log/apache2/access.log | sort -n。

5、获取Web服务器统计数据

启用状态页：
- Apache：启用status模块，配置ExtendedStatus On，设置允许访问的主机。
- Nginx：添加stub_status on配置，监听本机地址，重启服务后访问/nginx_status。
查看状态页：访问http://www.example.net/server-status获取统计数据，包括服务器版本、运行时间、网络流量、请求速率等。
记分板解读：字符表示进程状态，如.等待连接、W发送响应、K保持存活等。
命令行监控：使用watch -n 5 'curl http://localhost/server-status?auto'每5秒刷新状态页。