超级会员免费看
Ubuntu 服务器故障排查与日志查看全攻略
一、故障排查前期准备
在开始排查 Ubuntu 服务器的故障之前，有两个重要的操作可以帮助我们初步定位问题来源：查看 Bash 历史记录和当前登录用户。
1.
查看 Bash 历史记录
- 方法一：查看用户主目录下的
.bash_history
文件内容。
- 方法二：以该用户身份执行
history
命令。
2.
查看当前登录用户
- 执行
w
命令，不仅可以看到当前登录到服务器的用户，还能获取其 IP 地址。如果不清楚某个用户账户对应的是谁，可以在 DHCP 服务器中查看该 IP 地址的归属，以便直接询问相关人员。
通过这两个操作，我们可以初步判断是否有人正在处理某个问题，或者是否是某人的操作导致了问题的出现。
二、问题定位与范围确定
在识别问题空间和范围后，我们就可以开始缩小问题范围以找出原因。
1.
明显问题的处理
：如果问题比较明显，例如网站停止工作，且发现 Web 服务器上的 Apache 配置最近被更改，那么可以通过调查更改内容以及是谁进行了更改来解决问题。
2.
网络问题的处理
：如果是网络问题，如用户无法访问网站，潜在的问题空间会更大，可能的原因包括：
- 互联网网关故障。
- DNS 或 DHCP 服务器故障。
- 互联网服务提供商出现问题。
- 会计部门忘记支付互联网账单。
只要能够确定一个潜在的目标列表，专注于对这些目标进行故障排查，就离找到问题不远了。
下面是一个简单的问题定位流程图：
graph TD
A[发现问题] --> B[查看 Bash 历史和登录用户]
B --> C{问题是否明显}
C -- 是 --> D[调查明显更改]
C -- 否 --> E[考虑网络等多种可能]
D --> F[解决问题]
E --> G[确定排查目标列表]
G --> H[逐步排查]
H --> F
三、根本原因分析
解决服务器或网络上的问题后，下一步是进行根本原因分析，以防止问题再次发生。根本原因分析可以是向经理提交的报告，也可以是自己记录的备忘录，它是一个重要的学习机会。
1.
根本原因分析的内容
- 展示导致问题最初发生的事件。
- 列出为纠正问题所完成的步骤。
- 如果问题可能再次出现，应包含如何防止其在未来发生的信息。
2.
根本原因分析的准确性问题
：根本原因分析很难做到 100% 准确。有些情况下，根本原因可能很明显，例如用户 Bob 删除了公司重要文件目录，通过查看服务器日志和 Bob 的 Bash 历史记录可以明确问题所在。但大多数情况下，根本原因并不那么清晰。
例如，曾经遇到过一对 Citrix 虚拟机服务器同时崩溃的情况，调查发现文档中提到集群至少需要三台机器，而当时只有两台，因此推测是服务器设置不当导致的问题。但无法确定这就是问题的根本原因，因为无法确定服务器出现问题时的具体情况，且设置服务器的人员已经离职。
根本原因分析应包含以下详细信息：
| 信息项 | 说明 |
| ---- | ---- |
| 问题描述 | 对问题的详细描述 |
| 故障应用或硬件 | 出现故障的应用程序或硬件 |
| 首次发现时间 | 问题首次被注意到的日期和时间 |
| 调查发现 | 调查过程中发现的信息 |
| 解决措施 | 为解决问题所采取的步骤 |
| 问题原因 | 导致问题发生的事件、配置或故障 |
四、系统日志查看
如果难以找到根本原因，或者想获取更多关于问题的信息，可以查看日志文件。Ubuntu 系统有强大的日志记录功能，许多应用程序在事件发生时会写入日志文件。
1.
日志查看方法
-
传统方法
：查看
/var/log
目录下的日志文件，这些文件是标准的文件和目录，可以使用查看文本文件的命令来查看日志文件内容。虽然这种方法逐渐被淘汰，但大多数应用程序仍然将日志文件存储在该目录中。
-
新方法
：使用
journalctl
命令查看应用程序的日志信息。该命令是
systemd
的一部分，专门用于查看日志。例如，要查看
ssh
服务的日志信息，可以使用以下命令：
journalctl -u ssh
- `-u` 选项是必需的，用于指定要查看的服务。服务的名称与使用 `systemctl` 命令启动、停止或重启服务时的名称相同。建议在检查 Linux 系统的日志信息时，优先考虑使用 `journalctl` 命令。
不过，并非所有服务都通过
journalctl
记录信息，因此了解传统的日志查看方法也很重要。
-
不同日志文件的查看与用途
-
cat命令 ：可以使用cat命令查看日志文件内容，例如查看 Apache 访问日志：
-
cat /var/log/apache2/access.log
但该命令会打印出整个文件，无论文件大小如何，可能会导致无法查看所有内容，并且在服务器性能较差时，可能会占用大量资源。
- **`tail` 命令**：默认情况下，`tail` 命令显示文件的最后十行。例如查看 Apache 访问日志的最后十行：
tail /var/log/apache2/access.log
如果想查看更多行，可以使用 `-n` 选项指定行数，如查看最后 100 行：
tail -n 100 /var/log/apache2/access.log
`tail` 命令的 `-f` 选项非常有用，它允许实时跟踪日志文件，即随着日志文件中写入新条目，会在终端中实时滚动显示。例如：
tail -f /var/log/apache2/access.log
- **`less` 命令**：`less` 命令允许使用键盘上的上下翻页键滚动查看日志文件，比 `cat` 命令更适合查看日志文件。可以按 `q` 键退出文件查看。例如：
less /var/log/apache2/access.log
五、不同类型日志文件的作用
-
授权日志（
/var/log/auth.log）-
需要使用 root 账户或
sudo来查看该文件。 - 包含有关服务器认证尝试的信息，包括服务器本身的登录以及通过 OpenSSH 的登录。
- 当服务器出现严重问题时，可以查看在问题发生前后登录到服务器的用户。
- 如果自己或用户在通过 OpenSSH 访问服务器时遇到问题，可以在此日志中查找线索，例如公钥认证失败可能是由于密钥文件权限不正确，相关错误信息会记录在此日志中。
- 大量的登录尝试可能表明存在入侵企图，异常高的密码失败尝试次数可能意味着有人正在尝试暴力破解登录服务器，此时应立即阻止其 IP 地址。
-
需要使用 root 账户或
-
系统日志（
/var/log/syslog）- 包含许多不同方面的日志信息，是 Ubuntu 日志的“万能工具”。
- 如果某个守护进程没有自己的日志文件，很可能其日志会写入该文件。
- 有关 cron 作业的信息也会记录在此，当 cron 作业执行不正常时可以查看该日志。
-
可以从该日志中的
dhclient事件了解 IP 地址的更新情况，以及在无法获取 IP 地址时查看相关的失败消息。 -
系统
systemd初始化守护进程的日志也会记录在此，可查看与服务器启动以及应用程序运行相关的消息。
-
软件包管理日志（
/var/log/dpkg.log）- 记录与软件包安装和升级相关的日志条目。
- 如果在网络中推出更新后服务器出现异常，可以查看该日志，了解最近更新了哪些软件包以及安装的时间戳。
- 如果用户安装了未经授权的应用程序，可以将该日志与认证日志关联，确定当时登录的用户，然后检查该用户的 Bash 历史记录进行确认。
六、压缩日志文件的查看
日志文件通常会在一段时间后通过
logrotate
工具进行轮转，
/var/log
目录中会出现带有
.gz
扩展名的压缩日志文件，例如
syslog.2.gz
。
1.
传统方法
：先对压缩文件进行解压缩，然后使用前面提到的方法打开文件。
2.
便捷方法
：使用
zcat
命令直接查看压缩文件内容，例如：
zcat /var/log/syslog.2.gz
还有
zless
命令，其功能与
less
命令类似。
七、硬件故障排查命令
dmesg
命令可以查看 Linux 内核环形缓冲区中的日志条目，在排查硬件问题时非常有用，例如查看内核识别了哪些磁盘。与其他日志文件不同，
dmesg
本身就是一个命令，可以在文件系统的任何位置执行。在排查硬件问题时，系统日志也有帮助，但使用
dmesg
命令也是一个不错的选择。
八、日志查看的技巧与应用场景
-
日志类型分类
：在 Ubuntu 系统中，有系统日志和应用日志两种类型。系统日志（如
auth.log和dpkg.log）记录重要的系统事件，不特定于某个应用程序；应用日志在安装其所属的父软件包（如 Apache 或 MariaDB）时生成，会将日志条目记录到自己的日志文件中。有些守护进程（如isc-dhcp-server）不会创建自己的应用日志，可能会使用系统日志。 -
日志查看技巧
：当遇到问题时，在尝试重现问题的同时查看日志文件非常重要。使用
tail -f命令的跟随模式可以实时观察日志文件生成新条目，这种技术在处理行为异常的守护进程时非常有效，也有助于缩小硬件问题的范围。例如，插入闪存驱动器无反应时，通过跟随日志可以判断是硬件问题还是软件问题。
总之，Ubuntu 系统中的日志文件对于故障排查非常有帮助，当遇到问题时，查看相关日志条目并进行 Google 搜索，通常可以得到有用的答案，或者至少能找到相关的错误报告，让我们知道问题并非只存在于自己的系统中。
Ubuntu 服务器故障排查与日志查看全攻略（续）
九、日志查看的综合应用案例
下面通过几个具体的案例，展示如何综合运用前面提到的日志查看方法和技巧来解决实际问题。
案例一：Apache 网站无法访问
当发现 Apache 网站无法访问时，我们可以按照以下步骤进行排查：
1.
查看 Apache 访问日志
：使用
tail -f
命令实时跟踪 Apache 访问日志，查看是否有异常请求或错误信息。
tail -f /var/log/apache2/access.log
- 查看 Apache 错误日志 ：如果访问日志中没有发现有用信息，可以查看 Apache 错误日志，了解具体的错误原因。
tail -f /var/log/apache2/error.log
- 检查配置文件 ：根据日志中的错误信息，检查 Apache 的配置文件是否存在问题。常见的问题包括配置文件语法错误、虚拟主机配置错误等。
- 重启 Apache 服务 ：如果配置文件有修改，重启 Apache 服务使配置生效。
sudo systemctl restart apache2
案例二：DHCP 服务器无法分配 IP 地址
当 DHCP 服务器无法为客户端分配 IP 地址时，可以采取以下措施：
1.
查看系统日志
：使用
tail -f
命令查看
/var/log/syslog
文件，查看
dhclient
事件和相关错误信息。
tail -f /var/log/syslog
-
检查 DHCP 配置文件
：根据日志中的提示，检查 DHCP 服务器的配置文件
/etc/dhcp/dhcpd.conf是否存在问题。常见的问题包括地址池配置错误、子网掩码错误等。 - 重启 DHCP 服务 ：如果配置文件有修改，重启 DHCP 服务使配置生效。
sudo systemctl restart isc-dhcp-server
案例三：SSH 登录失败
当 SSH 登录失败时，可以通过以下步骤排查问题：
1.
查看授权日志
：使用
tail -f
命令查看
/var/log/auth.log
文件，查看 SSH 登录相关的错误信息。
tail -f /var/log/auth.log
-
检查 SSH 配置文件
：根据日志中的错误信息，检查 SSH 服务器的配置文件
/etc/ssh/sshd_config是否存在问题。常见的问题包括端口配置错误、密钥认证配置错误等。 - 重启 SSH 服务 ：如果配置文件有修改，重启 SSH 服务使配置生效。
sudo systemctl restart ssh
十、日志查看的注意事项
在查看和分析日志文件时，需要注意以下几点：
1.
权限问题
：有些日志文件需要 root 权限才能访问，如果遇到权限不足的错误，可以使用
sudo
命令提升权限。
2.
日志文件大小
：日志文件可能会非常大，使用
cat
命令查看时可能会导致终端卡顿或服务器性能下降。建议使用
tail
或
less
命令查看部分内容。
3.
日志轮转
：日志文件会定期进行轮转，旧的日志文件会被压缩保存。在查看历史日志时，需要注意文件的扩展名和存储位置。
4.
多方面分析
：单一的日志文件可能无法提供完整的信息，需要结合多个日志文件进行综合分析，才能准确找到问题的根源。
十一、总结与建议
通过对 Ubuntu 服务器日志文件的查看和分析，我们可以快速定位和解决各种故障问题。以下是一些总结和建议：
1.
建立日志查看习惯
：养成定期查看日志文件的习惯，及时发现潜在的问题。
2.
备份日志文件
：定期备份重要的日志文件，以防数据丢失。
3.
自动化日志分析
：可以使用一些工具（如 ELK 堆栈）对日志文件进行自动化分析，提高故障排查的效率。
4.
持续学习
：不断学习和掌握新的日志查看方法和技巧，以应对日益复杂的服务器环境。
下面是一个简单的故障排查总结流程图：
graph TD
A[发现问题] --> B[查看相关日志]
B --> C{是否找到问题原因}
C -- 是 --> D[解决问题]
C -- 否 --> E[综合分析多日志]
E --> F[定位问题根源]
F --> D
D --> G[进行根本原因分析]
G --> H[预防问题再次发生]
总之，掌握 Ubuntu 服务器的日志查看方法和技巧是保障服务器稳定运行的重要手段。通过合理运用日志信息，我们可以快速定位和解决各种故障问题，提高服务器的可靠性和性能。希望本文对大家在 Ubuntu 服务器故障排查方面有所帮助。
扫一扫
2225
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
