33、Ubuntu服务器故障排查全攻略

Ubuntu服务器故障排查全攻略

1. 根本原因分析的重要性

根本原因分析是一次宝贵的学习经历。不同的问题能让我们明白哪些事情不该做，或者怎样做得更好。比如，在处理虚拟机服务器故障时，我们得到的教训是遵循Citrix的最佳实践，使用三台服务器构建集群，而非两台。有时候，问题可能是其他技术人员未遵循正确指令或犯了错误导致的。

进行根本原因分析的价值在于，当问题再次出现时，我们能清晰回忆起上次的情况以及解决方法。毕竟，我们都容易遗忘重要细节。在组织中，根本原因分析还能向利益相关者展示我们不仅能解决问题，还能合理预防问题再次发生。

2. 查看系统日志

当确定问题范围后，我们可以着手查找问题的潜在根源，这通常需要查看服务器上的日志文件。Linux系统的日志功能强大，许多应用程序在事件发生时会记录日志。若出现问题，我们可能能在应用程序的日志文件中找到相关信息。

2.1 日志文件的类型

在Ubuntu系统中，日志文件主要分为系统日志和应用程序日志：
- 系统日志 ：由系统发行版创建，用于记录重要的系统事件，不特定于某个应用程序，如 /var/log/auth.log （授权日志）和 /var/log/dpkg.log （记录软件包安装和升级信息）。
- 应用程序日志 ：在安装应用程序时创建，记录该应用程序的相关事件。例如，安装Apache后，会在 /var/log/apache2 目录下创建日志文件；MySQL和MariaDB的日志文件则位于 /var/log/mysql 目录。

2.2 查看日志文件的方法

以下是几种常见的查看日志文件的方法：
- cat命令 ：用于打印整个日志文件内容。例如，查看Apache访问日志：

# cat /var/log/apache2/access.log

不过，该命令会打印整个文件，若文件较大，可能无法查看全量内容，还可能占用服务器资源。
- tail命令 ：默认显示文件的最后十行。例如：

# tail /var/log/apache2/access.log

若想查看更多行，可以使用 -n 选项指定行数，如查看最后100行：

# tail -n 100 /var/log/apache2/access.log

-f 选项可实时跟踪日志文件，当有新的日志条目写入时，会实时显示：

# tail -f /var/log/apache2/access.log

• less命令 ：允许使用键盘的上下翻页键滚动查看日志文件，按 Q 键退出。例如：

# less /var/log/apache2/access.log

2.3 不同日志文件的作用

• /var/log/auth.log ：授权日志，包含服务器的认证尝试信息，如本地登录和通过OpenSSH的登录。在排查安全问题或OpenSSH访问故障时非常有用。例如，若出现大量登录尝试，可能意味着存在入侵企图，应立即阻止相关IP地址。
• /var/log/syslog ：系统日志，记录了许多不同的信息，是Ubuntu日志中的“万能工具”。若某个守护进程没有自己的日志文件，其日志可能会记录在此。此外，还包含cron作业、dhclient守护进程（负责从DHCP服务器获取IP地址）以及systemd初始化守护进程的相关信息。
• /var/log/dpkg.log ：记录软件包的安装和升级信息。当服务器在更新后出现异常时，可查看此日志确定哪些软件包被更新。

2.4 处理压缩日志文件

日志文件通常会被 logrotate 工具定期压缩和轮换。在 /var/log 目录下，带有 .gz 扩展名的文件即为压缩日志。可以使用 zcat 命令直接查看压缩文件内容：

# zcat /var/log/syslog.2.gz

也可以使用 zless 命令，其功能与 less 命令类似。

2.5 dmesg命令

dmesg 是一个独立的命令，可在文件系统的任何位置执行，无需root权限。它用于查看Linux内核环形缓冲区的日志条目，在排查硬件问题时非常有用。

2.6 日志查看技巧

当遇到问题时，建议在尝试重现问题的同时查看日志文件。使用 tail -f 命令可以实时观察日志文件的更新，有助于快速定位问题。例如，在处理插入闪存驱动器无反应的问题时，通过跟踪日志，发现系统内核能识别硬件，但桌面环境未更新显示，从而确定问题是软件层面的，而非硬件故障。

以下是查看日志文件的方法总结表格：
| 命令 | 功能 | 示例 |
| ---- | ---- | ---- |
| cat | 打印整个日志文件内容 | # cat /var/log/apache2/access.log |
| tail | 显示文件最后几行，可指定行数或实时跟踪 | # tail /var/log/apache2/access.log
# tail -n 100 /var/log/apache2/access.log
# tail -f /var/log/apache2/access.log |
| less | 可滚动查看日志文件，按Q退出 | # less /var/log/apache2/access.log |
| zcat | 直接查看压缩日志文件内容 | # zcat /var/log/syslog.2.gz |
| zless | 类似less，用于查看压缩日志文件 | - |
| dmesg | 查看Linux内核环形缓冲区日志条目 | # dmesg |

mermaid流程图如下：

graph LR
    A[确定问题范围] --> B[查找潜在根源]
    B --> C[查看日志文件]
    C --> D{日志文件类型}
    D --> E[系统日志]
    D --> F[应用程序日志]
    E --> G[查看/var/log/auth.log等]
    F --> H[查看/var/log/apache2等]
    C --> I{查看方法}
    I --> J[cat命令]
    I --> K[tail命令]
    I --> L[less命令]
    I --> M[zcat命令]
    I --> N[zless命令]
    I --> O[dmesg命令]

3. 追踪网络问题

3.1 网络连接性检查

TCP/IP 网络在当今世界至关重要，但出现问题时排查起来可能很棘手。Ubuntu 提供了实用的工具来定位网络问题。

首先要检查网络连接性，因为无法连接到网络，服务器就基本无法使用。大多数情况下，Ubuntu 能识别各种网卡，并在有 DHCP 服务器的范围内自动连接到网络。排查时，先检查一些显而易见的问题，比如确保网络电缆两端都插紧，有时电缆本身可能出现故障，需要使用电缆测试仪检查是否有干净的信号。

3.2 路由问题排查

路由问题有时较难排查，但逐个测试目标点通常能找出问题所在。路由问题的典型症状包括无法访问其他子网的设备，或者虽能访问内部设备但无法访问互联网。

排查潜在的路由问题，可按以下步骤操作：
1. 查看路由表 ：使用 route -n 命令打印当前路由表信息。例如：

# route -n

假设输出显示默认网关为`10.2.150.1`，这意味着所有目标地址为`0.0.0.0`（即所有流量）的数据包都将通过该网关离开。此时应尝试使用`ping`命令测试该默认网关是否可达。

2. 进行 ping 测试 ：如果无法 ping 通默认网关，那么问题就找到了。若能 ping 通，可安装并使用 traceroute 命令。该命令默认不可用，需安装 traceroute 包：

# apt-get install traceroute

安装完成后，对目标主机（如外部 URL）运行`traceroute`命令，以找出连接中断的位置：

# traceroute example.com

`traceroute`命令会显示从本地到目标的每一跳，通过它可以看到连接链在何处中断，有可能问题不在本地网络，而是出在互联网服务提供商（ISP）处。

3.3 DNS 问题排查

DNS 问题不太常见，但掌握一些技巧也能解决。DNS 故障的症状通常是主机无法通过名称访问内部或外部资源。判断问题是出在内部还是外部主机，有助于确定是本地 DNS 服务器还是 ISP 的 DNS 服务器有问题。

排查 DNS 问题的步骤如下：
1. ping 已知 IP 地址 ：首先尝试 ping 网络上已知的 IP 地址，最好是默认网关。如果能 ping 通但无法通过名称 ping 通，可能存在 DNS 问题。同时，也可以尝试 ping 外部资源，如网站，以缩小问题范围。
2. 检查 DNS 服务器配置 ：查看 /etc/resolv.conf 文件，确定分配给机器的名称服务器是否正确。如果不正确，可以临时删除错误的条目，替换为正确的 IP 地址。但这只是临时解决方案，还需调查无效 IP 地址是如何产生的，通常这些地址是由 DHCP 服务器分配的。如果使用静态 IP 地址，可能是 /etc/resolv.conf 文件中存在拼写错误。
3. 临时切换 DNS 提供商 ：如果无法解析外部网站，可以临时将本地机器的 DNS 提供商切换为 Google 的 DNS 服务器（ 8.8.8.8 和 8.8.4.4 ）。如果切换后能访问外部资源，那么很可能是当前的转发器有问题。
4. 使用 dig 和 nslookup 命令 ： dig 和 nslookup 命令可用于测试服务器的 DNS 设置。例如：

# dig example.com
# nslookup example.com

`dig`命令会显示 DNS 区域文件中与地址（A）记录相关的信息，首次使用时会显示响应时间，后续再次运行时响应时间应更短，可用于排查缓存问题。

3.4 硬件支持问题

网络硬件支持也至关重要。如果 Linux 内核不支持网络硬件，插入网线时系统可能无法识别，或者在无线网络中无法显示附近的网络。

Ubuntu 的硬件支持大多集成在内核中，但也有例外。当遇到未被识别的网络硬件时，可按以下步骤操作：
1. 获取硬件信息 ：使用 lspci 命令结合 grep 搜索网络设备的硬件信息：

lspci | grep -i net

例如，输出可能显示有线和无线网络卡的信息：

01:00.1 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 12)
02:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a)

2. 搜索硬件支持信息 ：使用搜索引擎，以“<硬件名称> Ubuntu”为关键词进行搜索，查找相关的硬件支持信息。如果需要安装特定的软件包，搜索结果可能会提供线索。在没有网络访问的情况下，可能需要从其他计算机下载软件包，通过闪存驱动器传输到服务器。

3.5 DHCP 问题排查

DHCP 正常工作时非常方便，但出现问题时会让人沮丧。DHCP 问题通常是由于可用 IP 地址不足、DHCP 守护进程（ isc-dhcp-server ）未运行、配置无效或主机时钟不同步等原因导致的。

排查 DHCP 问题的方法如下：
1. 查看系统日志 ：如果服务器无法通过 DHCP 获取 IP 地址，可查看系统日志 /var/log/syslog 中与 dhcpd 相关的事件。虽然没有直接命令可以查看 DHCP 服务器剩余的 IP 地址租约数量，但如果租约耗尽，系统日志中可能会有相关记录。可以使用 tail -f 命令实时跟踪系统日志：

# tail -f /var/log/syslog

2. 调整租约时间 ：有时，DHCP 租约不足可能是因为设置了过长的租约时间。对于大多数网络，一天的租约时间通常就足够了。可以参考相关资料来配置 isc-dhcp-server 守护进程。

以下是网络问题排查的步骤总结表格：
| 问题类型 | 排查步骤 | 相关命令 |
| ---- | ---- | ---- |
| 连接性问题 | 检查电缆连接，使用电缆测试仪 | - |
| 路由问题 | 查看路由表，ping 默认网关，使用 traceroute 命令 | route -n
ping
traceroute |
| DNS 问题 | ping 已知 IP 地址，检查 /etc/resolv.conf 文件，临时切换 DNS 提供商，使用 dig 和 nslookup 命令 | ping
dig
nslookup |
| 硬件支持问题 | 使用 lspci 命令获取硬件信息，搜索硬件支持信息 | lspci | grep -i net |
| DHCP 问题 | 查看系统日志，调整租约时间 | tail -f /var/log/syslog |

mermaid 流程图如下：

graph LR
    A[网络问题] --> B{问题类型}
    B --> C[连接性问题]
    B --> D[路由问题]
    B --> E[DNS 问题]
    B --> F[硬件支持问题]
    B --> G[DHCP 问题]
    C --> H[检查电缆连接]
    C --> I[使用电缆测试仪]
    D --> J[查看路由表]
    D --> K[ping 默认网关]
    D --> L[使用 traceroute 命令]
    E --> M[ping 已知 IP 地址]
    E --> N[检查 /etc/resolv.conf 文件]
    E --> O[临时切换 DNS 提供商]
    E --> P[使用 dig 和 nslookup 命令]
    F --> Q[使用 lspci 命令获取硬件信息]
    F --> R[搜索硬件支持信息]
    G --> S[查看系统日志]
    G --> T[调整租约时间]

综上所述，Ubuntu 提供了丰富的工具和日志文件，通过合理利用这些资源，我们能够有效地排查服务器故障，确保服务器的稳定运行。无论是系统日志的查看还是网络问题的追踪，都需要我们仔细分析和逐步排查，以找到问题的根源并解决问题。