1. 课程导入与体系概览

在企业生产环境中，RHEL（Red Hat Enterprise Linux）服务器往往承载数据库、中间件、Web 服务、容器平台与内部业务系统。监控运维的目标不是“把图画得漂亮”，而是用尽可能低的成本，尽早发现异常、快速定位根因、缩短恢复时间，并让容量与性能变化可预测。换句话说，监控体系要回答四个问题：系统现在是否健康？如果不健康，问题在哪一层？变化趋势会不会导致未来故障？故障发生后如何闭环改进？

很多初学者把监控等同于“装一个 Zabbix 或 Prometheus，然后看 CPU、内存曲线”。这只能算数据采集，离体系化运维还有距离。一个可用的 RHEL 监控体系至少包含：明确的监控对象分层、统一的指标与阈值口径、告警分级与通知路径、故障处理与复盘机制，以及可持续维护的采集与展示工具链。本课程后续 29 章将围绕这些能力逐步展开，本章先建立整体地图。

一、监控对象分层：从硬件到业务

RHEL 服务器监控不能只盯一个层面。推荐按“自下而上”分为五层，每层关注不同的对象与指标：

• 硬件与基础设施层：物理机/虚拟机、CPU、内存、磁盘、网卡、电源、RAID 卡、温度。关键指标如磁盘 SMART 状态、RAID 降级、网卡丢包、内存 ECC 错误。
• 操作系统层：RHEL 内核、进程、文件系统、systemd 服务、日志、时间同步。关键指标如 load average、inode 使用率、swap 换入换出、OOM 事件、服务 active 状态。
• 中间件与运行时层：Nginx、Tomcat、Java 虚拟机、PostgreSQL/MySQL、Redis、消息队列。关键指标如连接数、队列积压、GC 时间、慢查询、线程池饱和。
• 应用与业务层：接口成功率、响应时间、订单量、支付失败率、登录会话数。这一层最贴近用户，但需要应用埋点或日志解析。
• 网络与安全层：带宽、延迟、TCP 重传、防火墙丢包、SSH 暴力破解、证书到期。安全事件与性能问题常常交织。

分层的意义在于：当告警发生时，可以按层排查，避免“一上来就重启服务”。例如业务层接口超时，可能根因在数据库慢查询，也可能在磁盘 I/O 饱和，甚至只是网卡丢包。分层让排查有路径。

二、运维闭环：从告警到改进

监控的价值在闭环中体现。一个完整的闭环通常包含五个环节：采集 → 判断 → 告警 → 处置 → 复盘。采集要保证指标真实、时间准确、粒度合理；判断要区分“瞬时抖动”和“持续劣化”；告警要分级，避免半夜被无关通知叫醒；处置要留下操作记录；复盘要产出可执行的改进项，例如调整阈值、增加采集项、优化 SQL 或扩容。

以“磁盘使用率超过 85%”为例。采集层由 node_exporter 或 Zabbix Agent 上报 node_filesystem_avail_bytes；判断层设置 85% 预警、92% 严重；告警层通过企业微信或邮件通知值班人；处置层先定位是日志、临时文件还是数据库增长，再决定清理或扩容；复盘层则要回答“为什么没提前发现”，并考虑增加日志轮转策略或容量趋势预测。这样一次告警才真正转化为运维能力。

三、课程实战环境与工具链总览

本课程使用一套可复现的 RHEL 实验环境。假设有三台 RHEL 9 服务器：node1（应用与 Nginx）、node2（MySQL 与 Redis）、node3（监控服务器，运行 Prometheus + Grafana + Alertmanager）。三台机器均关闭 SELinux 的强制模式用于实验，生产环境请按需保留。时间同步使用 chrony，主机名与 hosts 解析提前配置。

工具链方面，课程会覆盖以下组合：

• Prometheus + node_exporter + mysqld_exporter：拉取式指标采集，适合云原生与动态环境。
• Grafana：统一展示面板，支持多数据源与告警可视化。
• Alertmanager：告警分组、抑制、静默与路由。
• Zabbix：传统企业常用，适合网络设备与 Agent 混合场景。
• ELK/EFK 或 journald + rsyslog：日志集中与检索。
• systemd、top、vmstat、iostat、ss、sar：RHEL 自带命令行诊断工具。

下面给出一个最小可用的 Prometheus 采集配置示例，用于抓取三台 RHEL 节点的 node_exporter 指标。示例中的 IP 与主机名属于教学假设，实际部署时请替换为真实地址。

# /etc/prometheus/prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'rhel-nodes'
    static_configs:
      - targets:
          - '192.168.10.11:9100'   # node1
          - '192.168.10.12:9100'   # node2
          - '192.168.10.13:9100'   # node3
        labels:
          env: 'lab'
          role: 'rhel-server'

启动后，可在 Prometheus 的 Status → Targets 页面观察三个 target 是否均为 UP。若某个 target 显示 DOWN，优先检查 node_exporter 服务是否运行、防火墙是否放行 9100 端口、SELinux 是否拦截。这个简单的“采集是否成功”判断，就是后续所有监控工作的基础。