Monit 6.0.0 部署指南

Monit 6.0.0 部署指南：monitrc 全局配置逐项详解、/etc/monit.d 规则体系（process/system/file/filesystem/program 九类 check）、自愈动作与防抖熔断、Web 控制台与 XML 接口、告警邮件与事件队列、systemd 托管细节，全部步骤在 Ubuntu 22.04 实测并附真实回显。

MonitMonit监控2026/10/20

Monit 6.0.0 部署指南

‍‍​​‌​> 目标：在一台已安装 Monit 6.0.0 的 Ubuntu 22.04 服务器上完成生产可用的部署落地——monitrc 全局配置、/etc/monit.d 监控规则体系、自愈闭环验证、Web 控制台与告警邮件接入。本篇全部命令与回显在 Ubuntu 22.04.5 LTS（主机名 app-server）上实测通过；安装过程见《Ubuntu 22.04 安装 Monit 6.0.0 指南》，组件定位与架构背景见《Monit 6.0.0 介绍与选型指南》，命令行操作细节见《Monit 6.0.0 常用 CLI 命令与工具详解》。

一、环境信息

项目值
操作系统Ubuntu 22.04.5 LTS（x86_64），主机名 app-server
Monit 版本6.0.0（官方预编译二进制，monit -V 实测 Built with ssl, with ipv6, with compression, with pam and with large files）
安装路径/usr/local/monit/monit（软链 /usr/local/bin/monit）
控制文件/etc/monit/monitrc（软链 /etc/monitrc → /etc/monit/monitrc，权限 0700）
规则目录/etc/monit.d/*.conf
数据目录/var/lib/monit/（id、state、events 事件队列）
日志/var/log/monit.log
控制台http://10.89.58.3:2812（本机局域网地址，账号 admin/q1w2e3r4）
systemd 单元/etc/systemd/system/monit.service（Restart=always）

二、前置条件

  1. 已按《Ubuntu 22.04 安装 Monit 6.0.0 指南》方案 B 完成安装，monit -V 输出 6.0.0；
  2. systemd 可用（单元托管与 start program = "/bin/systemctl ..." 动作依赖）；
  3. 规划好控制台地址与账号：本篇实测绑定本机地址 10.89.58.3:2812，账号 admin / 密码 q1w2e3r4（演示口令，生产请换强密码）；
  4. 确认 2812 端口空闲：ss -ltn | grep 2812 || echo 空闲。

三、部署架构与文件布局

Monit 部署落地的全部文件如下（部署完成后的实测布局）：

/etc/monitrc                  → /etc/monit/monitrc（软链，官方二进制的查找路径）
/etc/monit/monitrc            # 全局配置（权限必须 ≤0700）
/etc/monit.d/                 # 监控规则目录（monitrc include 加载）
├── sshd.conf                 # 进程自愈规则
├── system.conf               # 系统资源规则
├── rootfs.conf               # 文件系统规则
├── passwd.conf               # 文件完整性规则
├── demo_probe.conf           # 自定义脚本探针规则
└── fake_app.conf             # 匹配式进程规则（自愈演示用）
/var/lib/monit/id             # 实例唯一 ID（M/Monit 识别用）
/var/lib/monit/state          # 监控开关状态持久化
/var/lib/monit/events/        # 事件队列落盘目录
/var/log/monit.log            # 运行日志
/etc/systemd/system/monit.service  # systemd 托管单元

💡 技术拓展：规则文件的组织方式不止 /etc/monit.d 一种。常见布局对比——

布局形式适用
单文件 monitrc所有规则写在一个文件规则少（<20 条），改动即 reload
目录式 include（本篇）monitrc 只留骨架，规则按对象拆 conf 文件规则多、多工具协同管理（Ansible 每角色丢一个 conf）
Debian 双目录式conf-available/conf-enabled 软链启用Ubuntu apt 安装包的默认布局（/etc/monit/conf-available 内置 16 个模板）

本篇实测采用 /etc/monit.d 目录式，理由是规则按对象解耦、单文件可独立启停（改名去掉 .conf 即停用），也是手工二进制部署下最干净的做法。

四、monitrc 全局配置详解

全局配置决定守护进程"怎么跑"：轮询节奏、日志、持久化、控制台与告警通道。以下为本次部署的完整 monitrc（生产模板），随后逐项详解：

cat > /etc/monit/monitrc <<'EOF'
## 轮询周期：每 30 秒一轮校验
set daemon  30
    with start delay 15

## 日志：写入本地文件
set log /var/log/monit.log

## 实例 ID 与状态文件
set idfile /var/lib/monit/id
set statefile /var/lib/monit/state

## 事件队列
set eventqueue
    basedir /var/lib/monit/events
    slots 100

## Web 控制台：绑定本机地址 10.89.58.3:2812
set httpd port 2812 and
    use address 10.89.58.3
    allow 10.89.58.0/255.255.255.0
    allow admin:q1w2e3r4

## 加载扩展规则
include /etc/monit.d/*.conf
EOF
chmod 700 /etc/monit/monitrc
mkdir -p /var/lib/monit/events /etc/monit.d
ln -s /etc/monit/monitrc /etc/monitrc

逐项说明：

  1. set daemon 30：校验循环周期（秒）。所有 for N cycles 防抖都以此为基准（30 秒周期下 for 3 cycles ≈ 90 秒确认窗口）。with start delay 15 让服务开机后延迟 15 秒再开始第一轮校验，避免系统启动高峰误报。官方不建议把周期配到 15 秒以下；
  2. set log /var/log/monit.log：日志落本地文件。不配置则走 syslog（默认模板是 set log syslog）。日志含事件、动作与错误，是排障第一现场；
  3. set idfile：实例唯一 ID 存放处。首次语法检查时自动生成（见下文实测），M/Monit 据此识别主机；误删后重新生成会导致 M/Monit 视其为新主机；
  4. set statefile：持久化每个服务的监控开关（monitor/unmonitor）状态，守护进程重启后不丢"谁被手动停了"；
  5. set eventqueue basedir + slots 100：告警发送失败（如 SMTP 不可达）或 M/Monit 离线时，事件先落盘，恢复后重投；slots 100 限制队列深度防撑爆磁盘；
  6. set httpd port 2812 and use address ... allow ...：控制接口三要素——端口、绑定地址、访问白名单。allow 支持三种写法：网段（10.89.58.0/255.255.255.0）、账号密码（admin:q1w2e3r4）、主机名（allow localhost）。这既是浏览器控制台，也是 monit CLI 的通信通道：CLI 按 monitrc 里的 use address 连接守护进程，所以绑定非 127.0.0.1 地址时 CLI 会连该地址（本篇实测 use address 10.89.58.3 后 monit status 实际请求 [10.89.58.3]:2812）。只读本机用时可绑 localhost + allow localhost；
  7. include /etc/monit.d/*.conf：规则拆分。⚠️ 通配至少要匹配到一个文件，否则语法检查直接失败（见第十节 Q2）。

4.1 语法检查与实例 ID 生成（实测）

monit -t

实测输出：

 New Monit id: a2684ffcdf61b436e4a46030f70c8cf4
 Stored in '/var/lib/monit/id'
Control file syntax OK

⚠️ 注意：若权限忘了 chmod，实测报错原文：

The control file '/etc/monit/monitrc' permission 0644 is wrong, maximum 0700 allowed
Monit exiting due to parsing errors in the configuration file.

执行 chmod 700 /etc/monit/monitrc 后重试即通过。

4.2 告警邮件通道（可选配置）

全局配置中还常用以下三件套接入邮件告警（本节先配置验证语法，投递实测见第八节）：

set mailserver smtp.example.com port 587
    username "monit@example.com" password "q1w2e3r4"
    with timeout 30 seconds

set alert ops@example.com

set mail-format {
  from: monit@$HOST
  subject: monit alert --  $EVENT $SERVICE
  message: $EVENT at $DATE on $SERVICE by $HOST
          $DESCRIPTION.
}
  • set mailserver：SMTP 服务器，支持认证与多服务器容灾（多行依次尝试）；内网无 SMTP 时配 localhost 交给本机 MTA 转投；
  • set alert：告警接收人，可加事件过滤 set alert ops@example.com but not on { instance, action }，也可只对个别规则 then alert；
  • set mail-format：邮件模板，可用变量 $EVENT/$SERVICE/$DATE/$HOST/$DESCRIPTION/$ACTION，$HOST 为本机 hostname。

五、监控规则详解与实测

规则是部署的主体。每条规则的通用语法骨架：

check <类型> <名字> with <定位>
    [group <分组>]
    [start program = "..." / stop program = "..."]
    [if <条件> [for N cycles] then <动作>]
    [if N restarts within M cycles then timeout]
    [every <cron 表达式>]

下面按对象类型逐类落地并给出实测回显。所有规则文件写入 /etc/monit.d 后统一执行 monit -t 检查、monit reload 生效（实测输出 Reinitializing monit daemon）。

5.1 进程自愈：check process（pidfile 式）

守护类进程优先用 pidfile 定位，精确无误报。本篇以 sshd 为例（Ubuntu 22.04 的 sshd pidfile 在 /run/sshd.pid）：

cat > /etc/monit.d/sshd.conf <<'EOF'
check process sshd with pidfile /run/sshd.pid
    group core-services
    start program = "/bin/systemctl start ssh"
    stop program  = "/bin/systemctl stop ssh"
    if failed host 127.0.0.1 port 22 protocol ssh then restart
    if 5 restarts within 5 cycles then timeout
EOF

逐项说明：if failed host 127.0.0.1 port 22 protocol ssh 不止测端口连通，还做一次 SSH 协议握手（换成 protocol default 则只测 TCP）；then restart 触发时 Monit 依次执行 stop program、start program；if 5 restarts within 5 cycles then timeout 是熔断——反复拉起失败就停止自动重启（状态变 Timeout），防止无限循环；group 把服务编组，供 monit -g core-services restart 批量操作。

实测状态回显（monit status sshd）：

Process 'sshd'
  status                       OK
  monitoring status            Monitored
  monitoring mode              active
  on reboot                    start
  pid                          2989
  parent pid                   1
  uid                          0
  effective uid                0
  gid                          0
  uptime                       0m
  threads                      1
  children                     0
  cpu                          0.0%
  cpu total                    0.0%
  memory                       0.0% [3.2 MB]
  memory total                 0.0% [3.2 MB]
  security attribute           unconfined
  filedescriptors              5 [0.5% of 1024 limit]
  total filedescriptors        5
  read bytes                   0 B/s [52.1 kB total]
  disk read bytes              0 B/s [0 B total]
  disk read operations         0.0 reads/s [67 reads total]
  write bytes                  0 B/s [44 B total]
  disk write bytes             0 B/s [0 B total]
  disk write operations        0.0 writes/s [4 writes total]
  port response time           6.384 ms to 127.0.0.1:22 type TCP/IP protocol SSH
  data collected               Mon, 19 Oct 2026 23:12:52

5.2 进程自愈：check process（matching 式）

无 pidfile 的脚本/守护进程用 matching 正则定位。本篇用一个演示应用实测完整自愈闭环：

cat > /usr/local/bin/fake_app.sh <<'EOF'
#!/bin/sh
while true; do sleep 5; done
EOF
chmod 755 /usr/local/bin/fake_app.sh

cat > /etc/monit.d/fake_app.conf <<'EOF'
check process fake_app matching "fake_app"
    group probes
    start program = "/bin/sh -c '/usr/local/bin/fake_app.sh >/dev/null 2>&1 &'"
    stop program  = "/usr/bin/pkill -f fake_app.sh"
EOF

active 模式下（默认），若进程不存在且配置了 start program，Monit 在下一轮校验时自动拉起——reload 后实测 summary 即出现 fake_app OK Process。

自愈闭环实测：kill -9 杀掉该进程，等待一个校验周期（30 秒）后查看：

monit summary fake_app
grep fake_app /var/log/monit.log | tail -4

实测输出：

 Service Name                     Status                      Type
 fake_app                         OK                          Process

[2026-10-19T23:20:02+0000] error    : 'fake_app' process is not running
[2026-10-19T23:20:02+0000] info     : 'fake_app' trying to restart
[2026-10-19T23:20:02+0000] info     : 'fake_app' start: '/bin/sh -c /usr/local/bin/fake_app.sh >/dev/null 2>&1 &'
[2026-10-19T23:20:10+0000] info     : 'fake_app' process is running with pid 3074

闭环成立：error 检出 → 自动 restart → 拉起确认，全程无人干预。这就是 Monit 的核心价值。

⚠️ 注意：matching 是全进程表正则匹配，模式串要足够特异（匹配到临时 shell 就会误判）。实测教训：用 pgrep -f fake_app.sh 手工排查时，排查命令自身包含 fake_app.sh 字样也会被 pgrep 命中（自杀式误杀），同理 Monit 规则里匹配串写得过宽会把无关进程算数。建议匹配完整路径（如 matching "/usr/local/bin/fake_app"）。

另一个生产要点：若被监控进程同时由 systemd 托管了 Restart=on-failure/always，systemd 会在 Monit 轮询前抢先拉起，两者不冲突但 Monit 的自愈更多承担"条件性重启"（端口无响应、资源超限），托管进程建议二选一或明确分工。

5.3 系统资源：check system

系统级检查默认存在（以 hostname 命名），在 monitrc 或规则目录里定义同名 check system 可追加阈值规则：

cat > /etc/monit.d/system.conf <<'EOF'
check system app-server
    if loadavg (5min) > 4 then alert
    if memory usage > 85% then alert
    if cpu usage > 95% for 10 cycles then alert
    if swap usage > 25% then alert
EOF

实测状态回显（monit status app-server，6.0.0 新增的 swap 换页速率字段可见）：

System 'app-server'
  status                       OK
  monitoring status            Monitored
  monitoring mode              active
  on reboot                    start
  load average                 [1.79] [1.56] [1.54]
  cpu                          8.7%usr 5.2%sys 0.0%nice 0.3%iowait 0.0%hardirq 1.1%softirq 0.0%steal 0.0%guest 0.0%guestnice
  memory usage                 8.0 GB [25.6%]
  swap usage                   524 kB [0.0%]
  swap pagein/s                0
  swap pageout/s               0
  uptime                       7h 49m
  boot time                    Mon, 19 Oct 2026 15:47:22
  filedescriptors              11424
  data collected               Mon, 19 Oct 2026 23:37:02

💡 技术拓展：if loadavg (5min) > 4 的阈值不是通用常数，负载阈值的常用定标方法——

方法公式/口径适用
核数倍数法5min 负载 > 1.5×CPU 核数告警通用起步值（4 核机器配 6）
队列长度法loadavg 持续 > 2×核数视为过载批处理型主机
经验绝对值> 4 告警小型 VPS（1–2 核）

本篇实测机为多核共享环境，按"经验绝对值 4"演示告警阈值；生产请按本机核数定标。6.0.0 还支持 if pageout > 100 per second for 10 cycles then alert 识别内存压力（官方经验：持续 >100 pages/s 需排查，>1000 属严重颠簸）。

5.4 文件系统：check filesystem

cat > /etc/monit.d/rootfs.conf <<'EOF'
check filesystem rootfs with path /
    if space usage > 85% then alert
    if inode usage > 85% then alert
EOF

逐项说明：path / 也可换成 UUID（with path /dev/xxx 或 label）；空间与 inode 双阈值都建议配——小文件风暴场景空间未满 inode 先耗尽。实测状态回显（输出节选）：

Filesystem 'rootfs'
  status                       OK
  monitoring status            Monitored
  monitoring mode              active
  on reboot                    start
  space total                  785.9 GB (of which 4.5% is reserved for root user)
  space free for non superuser 508.1 GB [64.7%]
  space free total             543.1 GB [69.1%]
  inodes total                 52396032
  inodes free                  46444696 [88.6%]
  data collected               Mon, 19 Oct 2026 23:14:42

5.5 文件完整性：check file

cat > /etc/monit.d/passwd.conf <<'EOF'
check file passwd_file with path /etc/passwd
    if changed checksum then alert
    if size > 1 MB then alert
EOF

逐项说明：6.0.0 起 checksum 默认算法为 SHA256（旧版默认 MD5，可用 if failed sha256 checksum 显式指定）；还支持 if changed timestamp、if failed permission 644、if changed pidfile 等测试。实测状态回显：

File 'passwd_file'
  status                       OK
  monitoring status            Monitored
  monitoring mode              active
  on reboot                    start
  permission                   644
  uid                          0
  gid                          0
  size                         1.2 kB
  hardlink                     1
  access timestamp             Mon, 19 Oct 2026 23:12:01
  change timestamp             Mon, 19 Oct 2026 23:12:01
  modify timestamp             Mon, 19 Oct 2026 23:12:01
  checksum                     8e47203adfd25c49a8ea01725a2106a9234e9eb9ad33eaf7b0f6de8d30944657 (SHA256)
  data collected               Mon, 19 Oct 2026 23:14:42

5.6 自定义探针：check program

任意健康检查脚本纳入 Monit 调度，按退出码判定：

cat > /usr/local/bin/demo_probe.sh <<'EOF'
#!/bin/sh
exit 0
EOF
chmod 755 /usr/local/bin/demo_probe.sh

cat > /etc/monit.d/demo_probe.conf <<'EOF'
check program demo_probe with path "/usr/local/bin/demo_probe.sh"
    group probes
    every "* * * * *"
    if status != 0 then alert
EOF

逐项说明：脚本 stdout 会被捕获并在 status 中展示（last output 字段）；every "* * * * *" 是 6.0.0 的 cron 风格调度（每分钟跑一次，不受主周期 30 秒影响）——实测 6.0.0 对旧写法 every 2 cycles 会打废弃告警（见第十节 Q4）；if status != 0 then alert 之外还可用 if status != 0 for 3 cycles then exec "..." 联动动作。

实测状态回显（脚本正常时）：

Program 'demo_probe'
  status                       OK
  monitoring status            Monitored
  monitoring mode              active
  on reboot                    start
  last exit value              0
  last output                  -
  data collected               Mon, 19 Oct 2026 23:14:42

异常路径实测：把脚本改成 exit 1，等下一次调度后：

monit status demo_probe | head -8
grep demo_probe /var/log/monit.log | tail -2

实测输出：

Program 'demo_probe'
  status                       Status failed
  monitoring status            Monitored
  monitoring mode              active
  on reboot                    start
  last exit value              1
  last output                  -

[2026-10-19T23:22:39+0000] error    : 'demo_probe' status failed (1) -- no output
[2026-10-19T23:23:30+0000] error    : 'demo_probe' status failed (1) -- no output

summary 中该项同步变红（实测 demo_probe Status failed Program）。改回 exit 0 后下一轮自动恢复 OK。

5.7 远程探测：check host（黑盒拨测）

对远端服务做协议级探测（示意规则，按需启用）：

check host nas.lan with address 192.168.1.10
    if failed ping then alert
    if failed port 443 type TCPSSL protocol https
       and certificate validity > 30 days then alert

逐项说明：if failed ping 发 ICMP（需 root，Monit 默认 root 运行没问题）；type TCPSSL protocol https 做 TLS 握手 + HTTP 语义校验；certificate validity > 30 days 证书到期预警——这是黑盒拨测最常用的三板斧。协议关键字覆盖 ssh/smtp/http/mysql/redis/memcached/pgsql/ldap/sip/mqtt 等 30 余种（官方手册 protocol 清单）。

💡 技术拓展：端口探测的深度分三档——TCP 连通（type TCP，仅三次握手）、协议握手（protocol <名>，发协议包并校验应答语义）、内容断言（HTTP 可再加 and request "/health" hostheader "..." 检查返回内容/状态码）。档位越深误报越少、开销越大，本篇 sshd 规则用的是协议档（protocol ssh）。

5.8 规则生效与回显核对

全部规则落地后统一生效：

monit -t
monit reload
monit summary

实测输出：

Control file syntax OK
Reinitializing monit daemon
Monit 6.0.0 uptime: 7m
 Service Name                     Status                      Type
 app-server                       OK                          System
 sshd                             OK                          Process
 fake_app                         OK                          Process
 passwd_file                      OK                          File
 rootfs                           OK                          Filesystem
 demo_probe                       OK                          Program

六类对象全部 Monitored 且 OK，部署主体验收通过。

六、Web 控制台与接口实测

控制台与 CLI 共用 2812 端口。浏览器访问 http://10.89.58.3:2812，输入 admin / q1w2e3r4 即可看到全部服务状态、启停按钮与配置回显。

命令行实测（无认证 401、认证后 200）：

curl -s -o /dev/null -w '%{http_code}\n' http://10.89.58.3:2812/
curl -s -u admin:q1w2e3r4 -o /dev/null -w '%{http_code}\n' http://10.89.58.3:2812/

实测输出：

401
200

页面标题实测（HTML 头部节选）：

<!DOCTYPE html><html><head><title>Monit: app-server</title>

机器可读接口（供脚本/聚合器抓取）：

curl -s -u admin:q1w2e3r4 'http://10.89.58.3:2812/_status?format=xml' | head -c 600

实测输出：

<?xml version="1.0" encoding="ISO-8859-1"?><monit><server><id>a2684ffcdf61b436e4a46030f70c8cf4</id><incarnation>1792451744</incarnation><version>6.0.0</version><uptime>128</uptime><poll>30</poll><startdelay>15</startdelay><localhostname>app-server</localhostname><controlfile>/etc/monit/monitrc</controlfile><httpd><address>10.89.58.3</address><port>2812</port><ssl>0</ssl></httpd></server>

💡 说明：XML 含每服务完整状态节点，是自建聚合面板的标准数据源。实测传 format=json 会退回纯文本状态页（Monit 只支持 XML 与默认文本两种输出），需 JSON 时自行用 XML 转换。

七、systemd 托管细节与守护进程行为

本部署的单元文件（安装篇 5.4 节模板）有两个值得实测确认的行为：

  1. Restart=always 与 monit quit 的交互：monit quit 会杀掉守护进程（实测输出 Monit daemon with pid [2825] killed），但 systemd 立即按 Restart=always 把它拉起（实测 Main PID 由 2825 变为 3217，服务保持 active）。因此规范停服务操作是 systemctl stop monit，monit quit 只在非 systemd 托管场景使用；
  2. start delay 与 Initializing 状态：systemctl restart monit 后立即查询，实测 summary 显示 demo_probe Initializing Program——处于 start delay/首轮采集期，属正常过渡态，等一个周期后转为 OK；
  3. 状态持久化生效：守护进程重启后，此前被 monit unmonitor 的服务保持 Not monitored，被监控的恢复 Monitored（由 statefile 保证）；
  4. daemon 自愈：进程意外退出时 systemd 5 秒内拉起；若进程活着但控制台无响应（罕见），monit reload 可让守护进程重读配置。

八、告警邮件投递实测

把 4.2 节的邮件配置指向一个不可达的 SMTP（本机 25 端口无 MTA），故意触发一个事件，观察 Monit 的失败处理：

[2026-10-19T23:24:02+0000] error    : Cannot open a connection to the mailserver localhost:25 -- Operation now in progress
[2026-10-19T23:24:02+0000] error    : Mail: Delivery failed -- no mail server is available
[2026-10-19T23:24:02+0000] error    : Alert handler failed, retry scheduled for next cycle

💡 说明：这三行日志证明告警链路已生效且失败可观测——投递失败的事件会按第五节 set eventqueue 的配置落盘（/var/lib/monit/events/），SMTP 恢复后自动重投。生产环境接入真实 SMTP 时把 set mailserver 换成可用服务器即可，格式不变。若不需要邮件告警，删除 set mailserver/set alert 两段即可（无接收人时 Monit 不产生投递动作）。

九、部署验收清单

部署完成的最终验收，逐项执行并对照：

验收项命令预期
语法monit -tControl file syntax OK
服务systemctl is-active monitactive
监听ss -ltn（过滤 2812）有 *:2812 或 <绑定地址>:2812 监听行
对象monit summary全部规则出现且状态 OK
自愈kill 掉 matching 式进程后等一个周期summary 恢复 OK，日志有 restart 记录
控制台curl -u admin:q1w2e3r4 -o /dev/null -w '%{http_code}' http://<绑定地址>:2812/200
XMLcurl -u admin:q1w2e3r4 '...:2812/_status?format=xml'返回 <monit> 开头 XML
日志tail /var/log/monit.log有周期性 'xxx' status OK(校验) 记录

十、常见问题（FAQ）

Q1：The control file '/etc/monit/monitrc' permission 0644 is wrong, maximum 0700 allowed

控制文件权限必须 ≤0700（内含控制台口令）。chmod 700 /etc/monit/monitrc。

Q2：Include failed -- No such file or directory '/etc/monit/conf.d/*.conf'

include 通配必须至少匹配一个文件（目录为空也报错）。往目录放一个规则文件，或注释 include 行。

Q3：CLI 报 Cannot connect to [10.89.58.3]:2812 -- Connection refused

守护进程未监听或还在 start delay。依次查：systemctl is-active monit、monitrc 是否配了 set httpd、是否处于启动延迟窗口（实测延迟 15 秒内必现此错，稍候重试）。另外 CLI 连接的地址就是 use address 绑定值，确认没有配置改动未 reload。

Q4：日志告警 The 'every N cycles' syntax is deprecated ...

6.0.0 废弃了 every N cycles，改 cron 风格：实测告警原文为

warning  : /etc/monit.d/demo_probe.conf:2: The 'every N cycles' syntax is deprecated, use cron-style 'every "*/N * * * *"' for periodic N minutes or 'every "* * * * *"' for once per minute instead

每分钟一次用 every "* * * * *"、每 2 分钟用 every "*/2 * * * *"、精确时刻用 every "15 8 * * 1"（每周一 08:15）。

Q5：改了规则文件不生效

Monit 只在启动与 reload 时读配置。执行 monit -t && monit reload（实测输出 Reinitializing monit daemon）。若 monitrc 语法坏了，CLI 自身也会解析失败（实测：include 目标缺失时连 monit summary 都报 parsing errors），先修好语法再 reload。

Q6：Mail: Delivery failed -- no mail server is available

SMTP 不可达，事件进本地队列等待重投。核对 set mailserver 地址端口与防火墙；本机无 MTA 又想用外部中继时，set mailserver smtp.xxx.com port 587 username "..." password "..."。

Q7：matching 式进程误匹配/漏匹配

用 monit procmatch "模式串" 预演匹配结果（输出命中进程列表与总数），确认只命中目标进程再写入规则；模式串用完整路径而非进程名片段。

十一、参考链接

  1. 官方手册（check 语法全集）：https://mmonit.com/monit/documentation/
  2. 6.0.0 Release Notes：https://mmonit.com/monit/changes/
  3. 本专栏关联篇：《Ubuntu 22.04 安装 Monit 6.0.0 指南》《Monit 6.0.0 介绍与选型指南》《Monit 6.0.0 常用 CLI 命令与工具详解》