Red Hat 系统管理实战：日志分析、性能调优、SELinux 与存储策略全解-代码聚汇网

1. 从一次“假报警”说起：系统管理笔记的由来

做 Red Hat 系运维久了，你会发现一个规律：真正把系统搞挂的，往往不是某个高深的内核参数，而是那些文档里一笔带过、日常没人搭理的细节问题。上个月值班，一台运行 PostgreSQ L 的生产服务器突然 load average 飙到 30，但 top 里 CPU 和内存都显示“一切正常”，业务方却在群里炸了锅。我登上去翻了半天日志，最后在 /var/log/messages 里发现每秒钟几百条 oom-killer 记录，原来是日志因为磁盘满被迫写入了内存 tmpfs，而 tmpfs 吃光了内存，触发了内核的 OOM 机制——一个典型的日志、磁盘、内存三个子系统纠缠在一起的连环故障。

这件事让我下定决心把手头关于日志分析、性能调优、SELinux 策略配置和存储管理的零散笔记整理成体系。这些内容单独看都不算难，但组合在一起，就是一台 Red Hat 服务器从“能跑”到“跑得稳、扛得住、还算安全”的全部底子。这篇文章里所有操作都在 RHEL 8/9（以及兼容的 Rocky Linux、AlmaLinux）上实测过，命令差异不大，CentOS 7 偶尔会有个别包名不同，我在关键地方会标注出来。

不管你是刚接手服务器的新手，还是已经在生产环境摸爬滚打几年的老手，这篇笔记的价值在于：不只告诉你命令怎么写，还告诉你踩过的坑在哪里、为什么这个参数要这么调、日志里哪些信息是烟雾弹哪些才是真信号。下面我们按四个主题逐一拆开聊。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 日志分析不玄学：从日志格式到故障现场的完整链路

日志分析被不少人说得神乎其神，仿佛掌握了什么“玄机”就能未卜先知。实际上，日志分析的底层逻辑就一句话：把系统的行为按时间线还原出来，找到第一个最不像“正常”的记录。 难点从来不在工具，而在于你知不知道每个组件的日志长什么样、正常状态是什么样。

2.1 日志格式里藏着的信息层级

Red Hat 系统里日志主要走两个阵营：传统的 syslog 体系（在 RHEL 8 之后由 rsyslog 接管）和 systemd 的 journald 体系。很多人一上来就 journalctl -xe，其实这两个体系是可以协同工作的，前提是你了解它们的边界。

rsyslog 的日志文件本体是明文文本，每个字段都靠空格和冒号分隔。以 /var/log/messages 里最常见的一行为例：

code复制Jun 28 14:32:17 hostname kernel: [12345.678901] Out of memory: Killed process 1234 (postgres) total-vm:1234567kB, anon-rss:890123kB, file-rss:0kB

拆开看是五层信息：

时间戳（Jun 28 14:32:17）——注意它不带年份，所以跨年排查日志时务必先确认文件是否做过 logrotate 归档；
主机名（hostname）——在集中式日志收集场景下，这是区分来源的关键；
产生日志的模块（kernel）——代表内核消息，同理还有 systemd、NetworkManager、sudo 等；
内核时间戳（[12345.678901]）——这是内核自己的滴答计数，对不上墙钟时间很正常，但在分析内核 panic 或 oom 顺序时非常有用；
日志正文——真正的信息所在，但也是最容易被误读的部分。

journald 体系则不同，它把这些字段结构化存储了。journalctl 你可以用 -o verbose 查看完整字段，比如 _PID、_COMM、_EXE、SYSLOG_IDENTIFIER 等。这在做关联分析时很贴心——一条日志不再是一行字符串，而是可以用字段过滤的一条记录。但要注意，journald 日志默认是易失的，如果没做持久化，重启后就查不到历史日志了。RHEL 8 开始默认把 journal 写到 /run/log/journal/（tmpfs），想要持久化，得手动创建 /var/log/journal/ 目录：

bash复制mkdir -p /var/log/journal
systemctl restart systemd-journald

2.2 故障定位的实操顺序：先看时间窗，再找异常指纹

真正的日志排查不是从头到尾读文件，而是先锁定时间窗，再找异常指纹。拿开头的 OOM 故障举例子，当时我的操作顺序是：

先用 uptime 确认负载异常的起始时间点；
用 journalctl --since "2024-06-28 14:30:00" --until "2024-06-28 14:35:00" -k 拉取该时间窗的内核日志，确认是不是内核级事件；
再用 journalctl --since ... --until ... -u postgresql 拉取同一时间窗的 PostgreSQL 服务日志，对比两边的时间线。

这一套下来，OOM 的发生时间和 PostgreSQL 开始报错的时间精确到秒级对齐，问题就锁定了。之所以强调时间窗，是因为系统在故障发生时往往在同一时间段产生几十种不同类型的日志，没有时间窗概念很容易被噪音带偏。journalctl 的时间语法兼容 YYYY-MM-DD HH:MM:SS，也支持 yesterday、-1h 这种相对时间，实际操作中非常实用。

再分享一个我常用的“异常指纹”概念。日志里的错误五花八门，但真正值得关注的错误通常带有几个典型特征：短时间内同一错误重复出现（循环报错）、多个不同模块在同一时间点报类似错误（级联故障）、错误信息里包含进程名和资源数值（资源耗尽型故障）。对应地，我用三个小命令就能快速定位：

bash复制# 统计当前时间窗内最频繁出现的前20条日志
journalctl --since "-1h" | awk '{print $NF}' | sort | uniq -c | sort -rn | head -20

# 只看内核级错误
journalctl -k -p err -b

# 只看某个服务最近的异常
journalctl -u nginx.service --since "-1h" -p warning

-p 参数控制日志级别过滤，级别从 emerg、alert、crit、err、warning、notice、info 到 debug 递减，实际生产环境建议日常看 warning 以上，排查问题时再下调到 info。级别太低，日志量会爆炸，反而找不到重点。

2.3 ELK 不是银弹，但集中分析确实能治“找日志”的命

当服务器数量超过三五台，逐台登录翻日志就变成了体力活。ELK（Elasticsearch + Logstash + Filebeat + Kibana）这类方案的价值在于把日志集中到一个地方，用统一的查询语言做全文检索。但在上手 ELK 之前，我想泼一盆冷水：如果你连单机日志怎么分析都还没搞清楚，上 ELK 只会得到一堆检索不到的索引。 日志分析的核心永远是“你要找什么”，工具只是加速这个过程。

在 Red Hat 上部署 Filebeat 作为日志采集端是比较常见的轻量方案。以 RHEL 9 为例，安装和配置核心逻辑大概是这样的：

bash复制# 添加 Elastic 官方仓库（以 8.x 为例）
rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch
cat > /etc/yum.repos.d/elastic.repo <<'EOF'
[elastic-8.x]
name=Elastic repository for 8.x packages
baseurl=https://artifacts.elastic.co/packages/8.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md
EOF

dnf install filebeat -y

Filebeat 的配置核心是一组输入和输出：输入告诉它去哪儿读日志，输出告诉它把日志送到哪儿。对 Red Hat 系来说，最建议采集的日志是 /var/log/secure（认证和 sudo 记录）、/var/log/messages（系统总日志）、/var/log/audit/audit.log（审计日志，下一章讲 SELinux 时还会用到）。一个最小可用的配置大概是：

yaml复制filebeat.inputs:
  - type: filestream
    id: secure-log
    enabled: true
    paths:
      - /var/log/secure
    fields:
      log_type: auth

  - type: filestream
    id: messages-log
    enabled: true
    paths:
      - /var/log/messages
    fields:
      log_type: sys

output.elasticsearch:
  hosts: ["http://your-elasticsearch-host:9200"]

注意 filestream 是 Filebeat 7.13 之后推荐的新输入方式，替代老式的 log 输入。它的好处是每个输入流都有独立的 ID（id 字段），Filebeat 会根据这个 ID 维护读取状态，即使配置文件改了，也不会重复读已有日志。如果用的是老版本，配置里写 type: log 也能正常工作，但同一个文件被多个输入配置引用时容易产生重复采集的坑。

至于 Logstash，我认为如果你的日志不需要复杂的清洗转换，完全可以跳过，直接在 Filebeat 里做轻量处理就够用。反之，如果确实需要把多行日志合并成一条事件（比如 Java 堆栈的异常日志），Logstash 的 multiline 插件仍然是最成熟的方案，用 filebeat 的 multiline 选项也能实现类似效果，但正则处理复杂场景时没有 Logstash 灵活。

2.4 MySQL 慢日志的“玄机”与心跳检测

热词里有一条“mysql日志分析玄机”，我猜说的是 MySQL 慢日志（slow query log）的分析。做后端的人对慢日志又爱又恨：爱的是它能帮你找到拖垮数据库的元凶 SQL，恨的是日志一旦开启，量大得惊人，而且默认只记录执行时间超过阈值的语句，结果往往是问题 SQL 早就被刷掉了，留下的全是“看起来慢但其实没毛病的”查询。

我的经验是：在 MySQL 里开启慢日志不是目的，建立慢查询的“基线”才是目的。 比如你的业务正常情况下 95% 的查询都在 50ms 以内，那 long_query_time 设为 1 秒就不合适——太宽松了，看不到性能劣化的趋势。更合理的做法是设置 0.5 秒甚至 0.2 秒，配合 log_queries_not_using_indexes=ON 把没用索引的查询也记录下来，然后定期用 mysqldumpslow -s t 按执行时间排序分析。

另外有个细节很多人不知道：慢日志记录的执行时间只是“在服务器上执行的时间”，不包含网络传输和客户端处理时间。所以排查“用户感知慢”但慢日志里找不到对应 SQL 时，别忘了检查客户端到数据库的链路是否健康。我遇到过一台云主机，CPU 和数据库指标全绿，但业务方反馈接口超时，最后定位到是云盘突发 IOPS 耗尽，硬生生把每次查询的磁盘读延迟拉到 200ms 以上——这种问题慢日志是看不出“慢”的，因为它的时间维度只在 MySQL 进程内部。

3. 性能调优不求玄学参数：找到真实瓶颈再动手

性能调优大概是运维领域最容易引发“玄学”讨论的板块了。今天听人说 vm.swappiness=10 好，明天又有人说该调 net.core.somaxconn，一顿操作猛如虎，结果压力测试一跑，瓶颈还在原地。原因很简单：调优得先分清瓶颈是在 CPU、内存、磁盘还是网络，然后针对它做优化，而不是把前人的参数抄一遍。

3.1 别急着调参：用这三板斧定位真实瓶颈

top、iostat、sar 是我定位性能问题的三板斧，每个都有不可替代的视角：

top 看的是进程和 CPU 的整体分布。 真正的 CPU 瓶颈有几个特征：us（用户态）长时间高、sy（内核态）也高，但 wa（I/O 等待）低；或者单核跑满但整体利用率不高——比如老版本 PostgreSQL 的并行查询在某些场景下只能吃满单核。看完 top 按 P 排序，很快能找到吃 CPU 的进程。注意 top 里有个常常被忽略的指标 hi 和 si（硬中断和软中断），如果 si 很高，说明网络包或者定时器中断处理不过来，常规的进程级调优无法解决，得看网卡多队列或者驱动问题。

iostat 看的是磁盘的真实压力。 我习惯用 iostat -x 1 5 观察 %util、r_await/w_await、svctm 这几个指标。%util 在 100% 附近说明磁盘接近饱和，但注意它不等于“磁盘不能用”，在 SSD 时代 util 的计算方式容易让人误判，更该关注的是 await 的绝对值。SATA SSD 的写延迟通常 0.1-2ms，NVMe 通常更低，如果 w_await 稳定超过 20ms，大概率是磁盘硬件或队列深度有问题，这时候光调系统参数是没用的，得换硬件或者改业务模型。

sar 看的是历史趋势。 在抓现场的同时，sar -u、sar -r、sar -d 可以回放过去几个小时的负载变化。这个价值极大——许多频繁但短暂的资源尖峰，在你登上去看一眼的瞬间已经消失，但 sar 能告诉你它什么时候来过、持续多久、有多大。RHEL 上要确认 sysstat 的采集服务开着：

bash复制systemctl list-units | grep sysstat
systemctl enable --now sysstat

3.2 CPU 和内存调优：用案例说话

CPU 调优最关键的三个层面是调度策略、中断绑核和内核参数。对多数应用来说，sched_autogroup 和 CFS 调度器的默认配置已经够用，真正值得调整的是两类场景：一是延迟敏感型应用（例如交易系统、实时通信），二是 CPU 密集型的批处理任务。

延迟敏感型场景，可以考虑使用 tuned 提供的 latency-performance profile：

bash复制tuned-adm profile latency-performance

这个 profile 做的事情包括设置 CPU 为 performance 调频模式、禁用节能状态、把 sched_min_granularity 调小等。别看这只是一条命令，RHEL 对性能调优的封装做得很好，比我当年在 CentOS 7 上手动改一堆 sysctl 靠谱得多。手动设置的话，核心的几个参数是：

text复制kernel.sched_min_granularity_ns = 3000000
kernel.sched_wakeup_granularity_ns = 2500000
kernel.sched_migration_cost_ns = 500000
vm.swappiness = 10

sched_min_granularity_ns 控制 CPU 时间片分配的最小粒度，值越小调度越频繁，交互体验越好，但切换上下文开销也大；sched_wakeup_granularity_ns 控制唤醒抢占的激进程度，值越大越不容易发生抢占；vm.swappiness 则控制内核使用 swap 的倾向，10 表示尽量少用 swap 但不到万不得已不用，对物理内存足够大的服务器来说，这个值能让内存页优先留在 RAM 里。三个参数默认值在某些内核上可能略有不同，修改前先 sysctl -a | grep sched_ 看一眼当前值。

内存层面的调优，除了 swappiness，更常被忽略的是 vm.dirty_ratio 和 vm.dirty_background_ratio。这对参数控制脏页（被修改但还没写回磁盘的内存页）的积累上限和开始后台回写的阈值。默认值通常分别是 30 和 10，也就是脏页占内存 10% 时内核开始后台回写，占 30% 时才强制同步写。对写密集型的数据库服务器，这个默认值往往太高，一个大事务可能导致显著的写停顿。我一般会调低：

text复制vm.dirty_background_ratio = 5
vm.dirty_ratio = 15

注意这是建议值，具体得看业务模型。调整时要结合 iostat 观察写延迟，如果回写太激进导致磁盘频繁刷盘，反而影响吞吐。

3.3 软中断和网络调优：不只看带宽，更看小包处理能力

网络性能调优有个经典误区：以为带宽是关键。真实生产里，小包（比如大量 TCP 短连接、DNS 查询、Redis 短请求）的 PPS（每秒包数）才是压垮网卡的元凶。单核处理软中断的极限大概在几十万 PPS 左右，如果网卡不支持 RSS（Receive Side Scaling）或多队列，所有网络包都会挤在一个 CPU 核心上，top 里 si（软中断）数值会直接爆表。

Red Hat 系查看网卡多队列设置：

bash复制ethtool -l eth0

输出里的 Combined 行显示当前和最大的收发队列数。如果当前值明显小于最大值，可以尝试调高：

bash复制ethtool -L eth0 combined 8

但敲这个命令前得先确认两件事：驱动是否支持动态调整队列数（多数现代网卡支持），以及调高后是否会影响 IRQ 亲和性设置。RHEL 8 上 irqbalance 服务默认会负责把中断分散到不同 CPU 上，所以如果 irqbalance 处于运行状态，手动绑核的操作反而可能引起冲突。建议的做法是维持 irqbalance 运行，只通过 ethtool 调整队列数量即可。

另一个常见调优点是 TCP 缓冲区。net.core.rmem_max 和 net.core.wmem_max 默认值在部分场景下偏小，尤其是需要高吞吐传输的场景。可以适当调大：

text复制net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728

把最大缓冲区调到 128MB 适合大数据传输，但对延迟敏感的小包场景，缓冲区过大反而增加内存占用和队列延迟。所以每次调网络参数，一定要先明确业务到底是大包高吞吐还是小包高并发，两种场景的参数方向几乎是相反的。

3.4 自己写压测脚本，比盲目看能看到的指标更可靠

性能调优的闭环不只是“调参数”，还得有“验证参数有效”的手段。最简单的验证方法是把压测工具跑起来，对比前后数字。但我发现很多人压测喜欢直接用 ab 打一个 Hello World 页面，这种测试结果对你的实际业务几乎没有参考意义。

我习惯用 stress-ng 给系统制造可控压力，比如先单压 CPU、再单压内存、再混合压测，验证系统的瓶颈点是不是和我们预想的一致：

bash复制dnf install stress-ng -y
stress-ng --cpu 4 --timeout 60s
stress-ng --vm 2 --vm-bytes 2G --timeout 60s

网络压测推荐 wrk 或者 iperf3，前者做 HTTP 层的并发测试，后者看纯带宽。Write 一个简单的 wrk 压测命令：

bash复制wrk -t4 -c100 -d30s http://your-service:8080/

这里的 -t4 表示 4 个线程，-c100 表示 100 个并发连接。压测过程中同时开着 top 和 iostat，看服务进程的 CPU 占用和磁盘状况，就能知道是哪个环节先支撑不住。如果 CPU 打满但负载上不去，说明是代码层逻辑或者锁的问题；如果 CPU 还有余量但吞吐上不去，多半是网卡、内核参数或者后端依赖的问题。调优最忌讳的就是不看压测过程的资源表现，只盯着最终 QPS 数字。

最后强调一个性能调优的时间投入原则：性能调优要遵守“边际收益递减”规律。 如果你的服务 QPS 是 200，调到 250 可能需要花三天时间找参数、压测、验证，但把代码里一个 O(n²) 的循环换成 O(n)，QPS 可能直接翻一倍。永远优先怀疑应用逻辑，再怀疑操作系统。

4. SELinux 实操防盗指南：从“为什么没生效”到“正确放行网络访问”

SELinux 是 Red Hat 系永远的话题中心。新手恨它，因为它默认开启却没人讲清楚它做了什么；老手爱它，因为它确实能挡住不少应用层漏洞带来的横向风险。这一章我们不讲理论条条框框，专门聊几个热词里出现的高频问题：改完策略没编译进去怎么办、怎么允许一个用户程序访问网络、SELinux 在手机上是什么、以及如何优雅地放行自定义应用。

4.1 权限修改后没有生效：九成是忘了编译和加载模块

不少人在 /etc/selinux/config 里把 SELINUX=permissive 改成 enforcing 后重启，然后发现 getenforce 还是 Permissive，或者改了某个 boolean 值之后没任何反应。这里要分两种情况说明：

情况一：修改 /etc/selinux/config 后没重启。 这个文件只在系统初始化时读取，运行中修改需要重启才生效。不想重启的话，用 setenforce 1 临时切换运行级别，但注意这只对当前启动周期有效，重启后仍以 config 文件为准。

情况二（那才是热的）：“selinux权限修改以后没被编译进去是为什么”。 这个通常指你自定义了一个 .te（SELinux 类型强制）策略文件，然后执行了 semodule -i myapp.pp，但发现策略没有生效，甚至 semodule -l 都看不到这个模块。最常见的原因有两个：

你没有先编译 .te 文件就尝试安装策略包，或者编译时用了错误的 SELinux policy 版本。正确流程应该是：

bash复制# 先写 myapp.te，例如允许某个自定义服务绑定非标准端口
checkmodule -M -m -o myapp.mod myapp.te
semodule_package -o myapp.pp -m myapp.mod
semodule -i myapp.pp

checkmodule 负责把 .te 编译成模块，semodule_package 把模块打包成策略包，最后 semodule -i 安装。中间任何一步报错，模块都不会进入策略库。

setsebool 改的 boolean 虽然在运行中有效，但你没让它持久化。setsebool -P 后面必须带大写的 -P 参数才会写入策略文件。没有 -P 的话，重启就回到默认值。

code复制setsebool -P httpd_can_network_connect on

我在生产上看到过太多人在 setsebool 时漏掉 -P，结果过了个维护窗口后访问权限又奇怪的没了，然后怀疑人生。

4.2 SELinux 如何“禁用户程序网络访问”，以及怎么正确放行

热词里“selinux 禁用户程序网络访问示例”问的是：怎么让某个用户自己的程序不能随便访问网络，只有明确授权的程序才能联网。这个需求非常合理——对服务器来说，一个被攻破的 Web Shell 如果连外网都出不去，横向渗透和反弹 Shell 就都做不成了。

SELinux 默认的安全策略对用户程序访问网络有严格限制。普通用户启动的进程如果没有特定的 SELinux 类型（type），是不能绑定非常规端口或作为客户端访问网络服务之外的资源的。但很多人测试时会遇到“设置了 SELinux 模块/类型，程序还是没法联网”的问题，这就得从类型和端口定义两头查了。

举一个非常经典的场景：你写了一个自定义的 Python Web 服务，需要通过 8081 端口向外提供 API，同时还要向外访问一个别的机器的 3306 端口。SELinux 默认只允许少数服务类型绑定某些端口，比如 httpd_t 对应 80/443，mysqld_t 对应 3306。你的自定义程序如果要绑定 8081，只授予它 httpd_t 类型还不够，还得让这个类型被允许在这个端口上监听：

bash复制# 列出 httpd_t 当前允许监听的端口
semanage port -l | grep http

# 给 httpd_t 增加 8081 端口
semanage port -a -t httpd_port_t -p tcp 8081

与此同时，httpd_t 对外访问网络的能力要单独开启。SELinux 的网络访问控制分为监听（bind）和连接（connect）两类，httpd_can_network_connect 这个 boolean 控制的是 Apache 等 httpd_t 类型进程往外发起 TCP 连接的能力：

bash复制setsebool -P httpd_can_network_connect on

如果你的程序用的不是官方预设的类型，而是自己定义的类型，那就要在策略文件里明确声明对外连接的许可。比如这样一段 .te：

code复制policy_module(myapp, 1.0)

require {
    type myapp_t;
    type http_port_t;
    class tcp_socket { bind connect read write getattr setopt shutdown name_bind name_connect };
}

# 允许绑定非标准端口
allow myapp_t self:tcp_socket create_stream_socket_perms;
allow myapp_t http_port_t:tcp_socket name_bind;

# 允许对外连接（允许访问 http_port_t 类型的远端端口）
allow myapp_t http_port_t:tcp_socket name_connect;

tcp_socket 这个类的 name_bind 是本地绑定端口，name_connect 是往外发起连接。这两者经常被混淆，你在自定义策略时写错了连不上是很常见的。编译安装的流程就是我 4.1 节说的那三步。

如果不想自己造轮子，Red Hat 官方推荐的更简单方案是使用 semanage permissive -a myapp_t，把某个类型放进 permissive 域。这样相关的违规操作会被记录但不会被阻止，适合调试阶段快速确认“是否是 SELinux 在拦截”。但生产环境千万不要长期这么干，permissive 类型等于把你自己的程序从 SELinux 保护里摘出去了，这和使用 setenforce 0 没有本质区别。我调试时用 permissive 定位问题，定位完马上换回 enforcing 并写好精确的 allow 规则。

4.3 手机上的 SELinux 与服务器的 SELinux：概念同源，目标不同

“手机的selinux在哪里开启”这个问题乍一听和服务器没关系，但顺着这个热搜词，反而能帮你把 SELinux 的边界理解得更清楚。Android 系统的内核就是 Linux，自然继承并改造了 SELinux 框架。Android 用 SELinux 的方式，是把每个 App（甚至 App 里的每个进程）放进独立的安全上下文，再通过 sepolicy 文件定义它允许访问的资源。手机上的“开启/关闭”入口隐藏在开发者选项和安全设置里，不同厂商差异很大，但从机制层面看，和 Red Hat 上把一个 nginx 进程关进 httpd_t 类型没有本质不同，只是策略粒度和更新频率不同。

对服务器运维来说，理解手机 SELinux 的真正价值在于：你能直观感觉到“安全策略不是一劳永逸的”—— Android 每次大版本更新都会增加大量新策略，同理，Red Hat 系统升级后原有的自定义策略模块也可能失效。我见过有人从 RHEL 7 升到 RHEL 8 后，之前编译的 .pp 模块导入失败，就是因为策略语言的版本和格式变了，需要重新用新版本工具链编译。凡是自定义过 SELinux 模块的系统，升级前务必导出现有模块清单，升级后逐个验证。

4.4 Audit 日志：排查 SELinux 拦截的唯一可靠依据

很多人的 SELinux 调试卡在“不知道规则哪里错了”上。其实 SELinux 的拦截行为全部记在审计日志里，调出来一目了然。RHEL 上查看：

bash复制grep -E "denied|avc:" /var/log/audit/audit.log | tail -50

典型的一条 AVC 拒绝长这样：

code复制type=AVC msg=audit(1719560000.123:456): avc:  denied  { name_connect } for  pid=1234 comm="python3" dest=3306 scontext=myapp_t:s0 tcontext=system_u:object_r:mysqld_port_t:s0 tclass=tcp_socket permissive=0

解读这一行，你会立刻知道四个关键信息：被拒绝的操作是 name_connect（要往外连的端口），进程是 python3，上下文是 myapp_t，目标是 mysqld_port_t。拿到这四个值，写 allow 规则就有的放矢了——你甚至可以用 audit2allow 工具根据日志自动生成一部分策略：

bash复制grep "denied" /var/log/audit/audit.log | audit2allow -M myapp-local
semodule -i myapp-local.pp

audit2allow 生成的是“最小可运行策略”，它会把日志里出现过的 deny 全部转换成 allow 规则。好处是快，坏处是规则粒度比较粗，把所有被拒的操作都放行了。我的建议是：第一次用 audit2allow 跑通业务，然后人工审查生成的 .te 文件，删掉明显多余的部分（比如一次调试中本就不该被允许的端口连接），收紧成精确策略。

还有一个小提示：audit.log 里 AVC 记录的时间和实际墙钟时间存在时差（审计时间戳和系统时间可能不同步），排查时以消息正文里的 comm=、pid= 和 dest= 为准，不要只依赖时间过滤。否则你会发现时间窗对不上，误以为策略没生效。

5. 存储管理不是只会 LVM：从分区布局到故障恢复的完整思路

存储这块，新手容易把它等价于“会用 fdisk 分区、会 mkfs 格式化”，但真正出问题的时候，你会发现存储管理考验的是对设备映射（Device Mapper）层次的理解、对物理块到逻辑卷映射关系的把握、以及对空间规划的前瞻性。Red Hat 系默认用 LVM2 管理存储，这套层次结构一旦理清楚，磁盘扩容、迁移、快照都只是几行命令的事。

5.1 Red Hat 的分层存储模型：物理卷、卷组、逻辑卷

服务器上的磁盘从裸设备到能被文件系统使用，要经过这么几层：

物理磁盘或分区 → 物理卷（Physical Volume，PV）→ 卷组（Volume Group，VG）→ 逻辑卷（Logical Volume，LV）→ 文件系统。

画在脑子里大概是：

物理盘是原材料；
PV 是把原材料切成“标准砖块”（物理区段 Physical Extent，PE）；
VG 是一堆砖块组成的“池子”；
LV 是从池子里圈出的一块地，在上面盖房子（建文件系统）。

这个分层最大的价值在于：你把“磁盘空间”和“分区大小”解耦了。 传统分区方案里，一块盘分多少就是多少，满了只能加新盘、拷数据、重新分区。但 LVM 的 VG 池子可以横跨多块物理盘，LV 的容量可以随时扩、缩，今天这行命令值得每一位运维刻在脑子里：

bash复制# 扩容 LV 到 100G（假设 VG 里还有空闲空间）
lvextend -L 100G /dev/vgdata/lvdata
# 调整文件系统大小
xfs_growfs /data

# 如果是 ext4，则用
resize2fs /dev/vgdata/lvdata

这里有个经典的坑：lvextend 只扩了块设备的大小，文件系统不会自动跟着扩。RHEL 7 之后的 XFS 文件系统只能扩不能缩，所以扩容时用 xfs_growfs（把文件系统扩大到块设备对应大小），而 resize2fs 是 ext4 的扩/缩容工具。搞混这两个命令，轻则文件系统大小没变，重则直接把数据搞坏。RHEL 8 以上默认文件系统是 XFS，所以生产环境中你大概率只会用到 xfs_growfs。

5.2 VDO 压缩去重：存储空间的“财务管家”

RHEL 8 开始，原生的 VDO（Virtual Data Optimizer）模块被正式纳入存储栈。VDO 做的事情很直接：在块设备层做零块剔除（zero-block elimination）和去重（deduplication），再配合压缩（compression），对数据冗余度高的场景（虚拟机镜像、备份存储、容器镜像）效果立竿见影。

创建一个 VDO 卷的思路是这样的：

bash复制dnf install vdo kmod-kvdo -y
vdo create --name=vdo1 --device=/dev/vgdata/lvvol --vdoLogicalSize=500G

--device 参数指向一个底层块设备（这里可以是一个 LV），--vdoLogicalSize 是 VDO 对外宣称的逻辑容量，它比你给的实际容量大得多——因为 VDO 认为数据经过去重压缩后占不了那么多物理空间。这个设计思路很像压缩文件：逻辑大小参照未压缩的总大小，实际占用的物理空间是压缩后的。

VDO 卷创建后，对它进行格式化、挂载和其他普通设备没有区别：

bash复制mkfs.xfs /dev/mapper/vdo1
mkdir /vdo-data
mount /dev/mapper/vdo1 /vdo-data

想查看 VDO 实际节省了多少空间，用：

bash复制vdostats --human-readable

VDO 的坑在于：它确实会带来额外的 CPU 开销。 去重和压缩都要计算、查表，如果服务器 CPU 本来就不富裕，建议只对冷数据或写入不频繁的数据用 VDO，而对热数据库的数据目录最好别开。我踩过一次就是给 MySQL 的数据盘上了 VDO，结果并发写入一上来，硬生生把写延迟从 2ms 拉到了 20ms。所以，VDO 不是所有场景的万能药，它更像一个特定场景下的存储优化选项。

5.3 存储故障演练：从“磁盘满了”到“PV 丢失”的应急路径

存储管理最见功力的时刻是在故障发生时。常见故障按严重程度从低到高排列：

磁盘空间满，服务只读：先确认根因。是日志爆炸（去清日志）还是数据增长过快（扩 LV）？df -h、du -sh 定位到具体目录，然后用日志旋转配置（logrotate）杜绝“日志慢慢写满磁盘”的情况再次出现。RHEL 的 /etc/logrotate.conf 默认按周切割日志，但对高产生的应用日志，建议针对单个服务单独写 /etc/logrotate.d/ 配置，提升切割频率并加 compress 选项。
PV 所在的物理盘坏掉，需要换盘：如果 VG 里还有另一块盘，可以临时把受损 PV 上的数据迁移走。如果确认数据块损坏，LVM 会标记这个 PV 为 missing，处理方式是加入新盘后重建镜像或恢复（取决于你是否配置了镜像 LV）。日常就修复不了数据，所以没有备份的存储操作，一律默认会丢数据，这句话送给每一个准备在生产上动存储的人。
误删 LV，急需恢复：lvremove 没有回收站，删掉一个 LV 之后上层文件系统的数据基本无法直接恢复。唯一的希望是你之前创建过 LVM 快照。lvcreate --snapshot 可以做一致性快照，然后挂载快照卷提取数据。快照要是没有，只能靠备份恢复。当然如果你有 VDO 或者做了文件系统级快照，恢复路径更多一些。

存储故障我也给一个经验性的建议：所有涉及存储的重要操作，先拍快照，再动手。 云主机就先打一个云盘快照，物理机就用 LVM 快照。快照这东西平时一文不值，灾难时就是救命稻草。这也解释了为什么 LVM 快照操作值得反复练习到肌肉记忆的程度：

bash复制lvcreate -L 10G -s -n snapshot-lvdata /dev/vgdata/lvdata
mount /dev/vgdata/snapshot-lvdata /mnt/snapshot

这个命令瞬间生成一个“当时的文件系统状态”的挂载点，虽然也会消费性能（写时复制），但在不追求极致性能的场景下，安全性远大于它带来的开销。

5.4 存储性能基准：别用感觉替代测量

存储调优前，先给当前的磁盘性能建立一个数字基线。RHEL 上最常用的是 fio，它的灵活度和真实业务模拟能力远超 dd 或 bonnie++。一个典型的随机读测试：

bash复制dnf install fio -y
fio --name=randread --ioengine=libaio --direct=1 --rw=randread --bs=4k --size=1G --numjobs=4 --runtime=60 --group_reporting

参数拆解：--rw=randread 表示随机读，--bs=4k 是块大小（模拟数据库页的访问粒度），--numjobs=4 是并发数，--direct=1 绕过页缓存直接测块设备的真实能力。这个测试结果出来后，你就有了磁盘随机读的 IOPS 基线——后续无论是调内核参数、换文件系统还是上 VDO，都可以拿它做前后对比。

但要注意：fio 只是“标准动作”的测试，不代表你的业务真的也是这样访问磁盘的。要精确评估业务影响，最好还是用真实流量做回放，或者在非高峰期把压测工具指向真实的数据集（比如用 pgbench 模拟 PostgreSQL 负载）。存储调优和性能调优的原则是同一个：没有测量就没有优化，没有对比就没有结论。

6. 写在最后：系统管理不是会敲命令，而是会判断优先级

这篇笔记写了四个主题，日志、性能、SELinux、存储，每一块单独拿出来都能写成一本书，但我觉得把它们放在一起才最有价值——生产环境从来不是单点问题，日志里发现的磁盘告警可能来自一个膨胀的日志文件，SELinux 的拦截可能让你误判成应用网络故障，存储延迟升高可能会表现为应用层的超时。运维的核心能力，就是从这些不同来源的信号里，快速还原出一条完整的事件链。

我自己踩过最深的坑，就是“单点思维”。当年第一次遇到 SELinux 拦截日志时，第一反应是关掉 SELinux，眼不见心不烦；第一次遇到慢查询时，第一反应是加索引，结果索引加了一堆，数据库写入反而更慢。后来才明白，一个好的系统管理员不是所有命令都会背，而是知道自己手里的每一张牌（日志、性能数据、安全策略、存储布局）在什么场景下该打哪一张，以及不打哪一张。

如果你刚入行，我的建议是：把这四个主题分开练，每一个都从“遇到问题 → 打开日志/工具 → 定位根因 → 动手解决 → 记录复盘”跑完一遍，形成自己的操作手册。练熟之后再试着把它们串起来，你就能看到一条日志告警背后可能连着的整整一条链路。那种“一眼看穿问题”的感觉，就是经验——它不是玄学，它只是你见过足够多案例后的模式识别。希望这篇笔记能帮你少走几步弯路。

Red Hat 系统管理实战：日志分析、性能调优、SELinux 与存储策略全解