monitoring-plugins安装加速

monitoring-plugins 安装加速：从镜像、缓存到源码编译的完整提速方案

`monitoring-plugins` 是 Nagios/Icinga 生态中最常用的检测插件集合，包含 `check_http`、`check_ping`、`check_disk`、`check_load` 等数十个命令。默认从官方源安装时，受制于网络链路和编译依赖，常常耗时较久。本文整理几种可落地的加速思路，按“改动成本从低到高”排列。

> 说明：具体耗时与网络环境、发行版版本、镜像站状态有关，请以本地实测为准。

一、优先使用发行版仓库与就近镜像

大多数发行版都提供打包好的 `monitoring-plugins`，直接安装即可，无需自行编译： bash

Debian / Ubuntu

sudo apt update sudo apt install -y monitoring-plugins

RHEL / CentOS / Rocky / AlmaLinux

sudo dnf install -y monitoring-plugins 加速的关键在于把仓库指向就近镜像。

APT（Debian/Ubuntu）：编辑 `/etc/apt/sources.list` 或 `/etc/apt/sources.list.d/` 下的文件，替换为国内镜像，例如： text deb https://mirrors.example.edu/debian bookworm main contrib non-free DNF/YUM（RHEL 系）：替换 `/etc/yum.repos.d/` 中的 `baseurl` 为镜像地址，随后： bash sudo dnf clean all sudo dnf makecache `makecache` 会一次性拉取并缓存元数据，后续安装不再反复请求索引，是体感最明显的提速点。

启用 EPEL（RHEL 系需要）： bash sudo dnf install -y epel-release

二、开启本地包缓存

如果同一批机器都要安装，缓存可以省下重复下载。

APT 缓存：`/var/cache/apt/archives/` 会保留已下载的 `.deb`。在批量部署时可先在一台机器下载，再分发： bash sudo apt-get install -y --download-only monitoring-plugins

然后将 /var/cache/apt/archives/*.deb 拷贝到其他机器

sudo dpkg -i /path/to/*.deb DNF 缓存： bash

/etc/dnf/dnf.conf

keepcache=1

三、代理与镜像双管齐下

如果直连官方源缓慢，可通过代理访问： bash export http_proxy="http://proxy.example.com:8080" export https_proxy="http://proxy.example.com:8080" export no_proxy="localhost,127.0.0.1" APT 也可单独配置代理文件 `/etc/apt/apt.conf.d/95proxy`： text Acquire::http::Proxy "http://proxy.example.com:8080"; Acquire::https::Proxy "http://proxy.example.com:8080"; 注意：代理与镜像不一定同时最优。若镜像本身就在内网或同城，通常直连镜像比走代理更快，建议分别实测后择一。

四、源码编译时减少等待

部分场景需要自行编译 `monitoring-plugins`，此时加速要点在于减少重复编译与依赖拉取。

1. 先装齐依赖，避免 configure 反复中断：

bash sudo apt install -y build-essential libssl-dev libcurl4-openssl-dev \ libmysqlclient-dev libpq-dev libldap2-dev libradcli-dev

1. 使用 `make -j` 并行编译：

bash ./configure --prefix=/usr/local/nagios make -j"$(nproc)" sudo make install

1. 缓存 configure 结果：同一环境多次编译时，保留生成的 `config.cache` 可跳过大量探测：

bash ./configure -C

五、方案对比

六、常见坑

• 镜像不同步：更换镜像后先运行一次 `apt update` 或 `dnf makecache`，确认没有 404。
• 架构不匹配：缓存的 `.deb`/`.rpm` 只能用于同架构机器。
• 依赖缺失导致反复重试：编译前用包管理器补齐 `-dev`/`-devel` 依赖，比中途查错更省时间。
• 并行度过高：`make -j` 数值超过 CPU 核心数或内存不足时可能触发 OOM，建议以 `nproc` 为上限。

小结

对大多数用户而言，“就近镜像 + makecache + 本地缓存” 三步即可获得明显提速；只有在必须源码编译时，才需要关注依赖补齐、`-j` 并行与 `config.cache` 复用。建议先测量一次基线耗时，再逐项引入上述手段，用实测数据判断哪一项真正有效。