2026 服务器租用干货：Checkmk 监控站点内存与 RRD 小文件 inode 规划，别让监控先倒下

2026 服务器租用干货：Checkmk 监控站点内存与 RRD 小文件 inode 规划，别让监控先倒下

干运维的都懂一种黑色幽默：半夜业务真出事了，打开手机一看——告警平台自己失联了。上去查，监控服务器 OOM 被杀，或者磁盘 inode 归零、RRD 写不进去，历史图全断。业务还没倒，监控先倒。这种事故很难看，因为别人问你"为什么没告警"，你只能回答"监控系统挂了"。

Checkmk 是个好东西，配置舒服、自动发现强、agent 轻。但它有一个特点容易被低估：它的资源消耗不跟着"流量"走，而是跟着"对象数量 × 指标数量 × 检查频率"走。你加一百台机器，业务侧可能毫无感觉，监控侧却是实打实多出几千个 RRD 文件、几千次调度、几千条历史。很多团队租监控服务器的时候按"这玩意儿又不跑业务，给个小配置就行"的思路下单，半年后翻车。

这篇不写监控工具横评，只算账。下面这四本账算明白了，你租多大、盘怎么分、间隔设多少，自己就能拍板：

• 内存账：Checkmk 的一个 site 就是一整套独立实例（内核 + 配置 + 状态历史），不是"一个进程"。单 site 8 GB 起步（预估），2,000 台以上建议 32 GB 起（预估）。
• inode 账：RRD 文件数是"主机数 × 每台服务数 × 每服务指标数"，单个文件几十 KB。容量可能只用了 30 GB，inode 却先被 30 万个小文件吃光。
• CPU/IO 账：检查间隔从 1 分钟压到 30 秒，开销是翻倍，不是"多一半"。瓶颈在随机写 IOPS，不在磁盘吞吐。
• 归档账：history、notify.log、事件归档是长线增长项；omd backup 别指望它又快又全，RRD 要不要进备份是必须先做的取舍。

Checkmk 的 site 到底是什么：一个 site 就是一套独立内核

site 里装的东西，比你想的多

新手最容易犯的认知错误，是把 Checkmk 当成一个"程序"。它不是。Checkmk 的基本部署单位叫 site（由 OMD 框架管理），你用 omd create monitor 建出来的那个 site，是一个目录树 /omd/sites/monitor/，里面装着：

• 监控内核：Raw 版是 Nagios 内核，商业版可以切到 CMC（Checkmk Micro Core）。内核负责调度、状态机、通知触发。
• 配置与状态：var/check_mk/ 下的自动发现结果、主机与服务清单、历史文件，还有 etc/check_mk/conf.d/ 那堆规则。
• RRD 数据库：var/check_mk/rrd/<主机名>/ 下按服务与指标拆分的海量小文件。
• 日志：var/log/ 下的 notify.log、core/log（nagios.log 或 cmc.log）、web.log、mkeventd 日志等。
• Web 与查询层：Apache/Nginx 站点、Livestatus socket、Python 进程池。

换句话说，一个 site = 一套完整的监控系统。你在同一台机器上开三个 site，就等于跑了三套监控系统，三份内存、三份内核调度、三份 Python 进程。这一点不夸张，很多人的机器卡死就是因为"顺手多建了一个测试 site 没删"。

为什么"一个大 site 装所有"会翻车

反过来，把所有东西塞进一个 site 也不是最优解。单 site 的问题不是性能上限低——CMC 内核扛几万台主机是没问题的——而是爆炸半径：一次误配规则、一次错误的批量删除、一次升级失败，影响的是全量监控。而且单 site 的历史文件与 RRD 目录会变得非常庞大，备份一次动辄几十分钟到几小时，真出事时你根本等不起恢复。

我的习惯是：1,500 台以内，一个 site 够了，别折腾；超过这个量级，或者有明显的安全域/地域划分（比如生产、办公网、中国香港与海外节点分开），再考虑拆。拆 site 的钱不是白花的，它换来的是故障隔离和可接受的备份窗口。

site 内存账：CMC 与 Nagios 内核差在哪，一个 site 该给多少内存

CMC 与 Nagios：差在"fork"这件事上

Nagios 内核是老派 C 程序，调度逻辑是每执行一次检查就 fork 一个子进程，跑完回收。这个模型很稳，但代价是进程创建开销、上下文切换、以及每轮检查的调度抖动。当你的检查项上到几万个、间隔又压到 1 分钟以内时，fork 本身的开销开始变得可观。

CMC 是 Checkmk 自己写的 C++ 内核，设计目标就是解决这个：检查调度在内核内做，配合 helper 机制，不再每查一次 fork 一次；状态历史走内存结构 + 高效落盘；还带 smart ping 这类减少无效探测的优化。按我们自己的观察与社区普遍反馈（不同版本差异较大，以下为预估，需以你所用版本的实测为准）：同样的检查量，CMC 的 CPU 占用大致能比 Nagios 低 30%–50%，内存占用低 20%–40%；更关键的是在高检查量下 CMC 的调度延迟更稳定，不容易出现"这一轮检查晚了 20 秒"的现象。

要注意的是：CMC 是商业版能力，Checkmk Raw 版用的还是 Nagios。所以你在 Raw 版上做容量规划，得按 Nagios 的那套更保守的数字来留余量。别拿商业版的评测数据去给 Raw 版下单，那是要出事的。

一个 site 的内存下限，我给个保守数

内存这块我不喜欢给"最低配置"，因为最低配置只保证能起来，不保证半夜不 OOM。按实际跑过的规模，我给的建议（预估，单位 GB，含内核 + Web + Python 进程池 + 系统自身）：

• 50–100 台 / 1,500–3,000 个 service：8 GB。4 GB 也能跑，但一旦你打开事件控制台、开了几个 dashboard，内存就贴着上限走。
• 300–500 台 / 8,000–15,000 个 service：16 GB。这个量级是中小企业最常见的规模，16 GB 是比较舒服的水位。
• 1,000–2,000 台 / 3 万–6 万个 service：32 GB。CMK 的 Livestatus 查询、Web UI 多用户并发会额外吃内存，别只看内核。
• 5,000 台以上：64 GB 起，并且强烈建议拆 site，而不是继续堆单机内存。

这里有个容易被忽略的点：内存压力往往不是来自"主机数"，而是来自"服务数 × 指标数"。一台交换机跑 SNMP 自动发现，可能一个接口一个 service，48 口交换机加上 Fan/Power/CPU/Mem 一类的检查，单个设备就贡献六七十个 service。20 台这样的交换机，service 数量顶得上 300 台普通 Linux 服务器。所以看到"我方只有 80 台设备"就下单 8 GB 内存的，多半要在半年后升级。

多 site 拆分的内存代价

每多一个 site，固定开销大致是 300–600 MB 的常驻（内核 + Python + Web 进程池基础占用，预估）。也就是说 32 GB 的机器上开 4 个 site，可用的"业务内存"其实只剩 30 GB 不到。这个数字不算大，但如果你打算在一台机器上开十几个小 site 做租户隔离，就要认真算一下，别把内存规划成"每个 site 2 GB × 20"。

RRD 小文件账：容量还剩一半，inode 却先归零

一个公式先摆出来

Checkmk 的性能数据（PNP4Nagios 那套图形数据）存在 RRD 文件里，路径是 var/check_mk/rrd/<主机>/<服务>_<指标>.rrd。一个指标一个文件，不是一台主机一个文件，也不是一个服务一个文件。所以：

RRD 文件数 ≈ 主机数 × 每台服务数 × 每服务指标数

举两个真实感的例子：

• Linux 服务器：一台装了 Checkmk agent 的机器，自动发现后常见 25–40 个 service（CPU load、CPU util、内存、文件系统若干、磁盘 IO、网卡若干、进程数、uptime、agent 版本……）。平均每个 service 带 1–3 个指标，取中位 2 个，那一台就是 50–80 个 RRD 文件。
• SNMP 交换机：一台 48 口接入交换机，接口 service 48 个 + 若干整机检查，每个接口常见 4–6 个指标（带宽、速率、错误包、丢包、组播/广播等），一台设备轻松 250–400 个 RRD 文件。

照这个口径算：500 台 Linux + 30 台交换机 ≈ 500×65 + 30×300 ≈ 32,500 + 9,000 ≈ 4 万个 RRD 文件。单个 RRD 文件按 40–80 KB 算（取决于 RRA 数量与版本，常见在 30–200 KB 区间），4 万个文件总共也就 2–3 GB。是不是小得离谱？这就是陷阱所在。

为什么"容量还剩一半，inode 已经没了"

每个文件都要占一个 inode，不管它是 40 KB 还是 40 MB。4 万个文件吃掉 4 万个 inode。而 inode 数量是格式化时就定死的——这就是问题。

举个血淋淋的算例：你给监控服务器挂了一块 200 GB 的数据盘，容量看 RRD 那 3 GB 用量，简直奢侈。但如果这块盘当初是按 mkfs.ext4 -T largefile（或者 -i 1048576，1 个 inode 对应 1 MB）格式化的，200 GB 只会有 约 20 万个 inode。4 万 RRD + 一些杂项好像还行？别急，再加上自动发现反复增删产生的残留目录、多个 site 各一份、历史归档目录、日志轮转留下的文件，inode 消耗速度会比你估的快。当你扩到 2,000 台主机、RRD 数涨到 15 万+，inode 就见底了，而此时 df -h 显示的容量使用率可能只有 12%。

更惨的是现象迷惑人：inode 耗尽时，你会看到"磁盘空间不足"的写入失败，去看 df -h 却明明有 180 GB 空闲。很多人第一反应是"盘坏了"或者"是不是 quota 限制"，查半天才想起来 df -i。而监控系统的表现是：RRD 更新失败 → 图形断更 → 部分视图报错 → rrdcached 日志刷屏，最后整台机器变得极慢。

ext4 与 XFS 的差异，怎么选

• ext4：inode 数量在 mkfs 时按 bytes-per-inode（默认 16 KB 一个 inode）一次性算好并分配，事后不能增加（只能重新格式化并恢复数据）。好处是可预期、能提前算；坏处是选错密度就完蛋。对小文件场景，我建议显式指定更密的密度，例如 mkfs.ext4 -i 8192（预估口径，请以你的文件系统版本与实测为准）。
• XFS：inode 是动态按需分配的，按 chunk（默认每 chunk 64 个 inode）按块组分配，不存在"inode 总数用光"这个经典死法，只要你还有剩余空间就能继续建文件（受 imaxpct 限制，默认允许最多一定比例的空间用于 inode）。对"大量小文件且数量不好预估"的场景，XFS 的容错性明显更好，这是我给 Checkmk 数据盘的首推。

一句话建议：数据盘一律用 XFS；如果因为既有规范必须用 ext4，格式化时把 inode 密度调密，并且把 df -i 加进监控项——是的，监控系统要监控自己，而且 inode 使用率必须是一项独立告警，不能只看容量。

RRD 是原地更新：随机写 IOPS 与检查间隔一起翻倍的账

原地更新意味着随机写，不是顺序写

RRD 是环形数据库，文件创建后大小基本固定，之后每次收到新数据都是在文件内部的固定偏移位置改写若干字节。这听着很省事，实际是最典型的随机小写：4 万个文件、每秒几百次更新，每个更新落在某个文件的某个偏移上。

这种情况下磁盘的瓶颈是 IOPS 与写放大，不是吞吐。你拿一块顺序读写 500 MB/s 的 SATA SSD 跑 fio 很漂亮，但 4 KB 随机写混合读的 IOPS 可能只有几千；换成机械盘，随机 IOPS 掉到一两百，直接跪。所以监控服务器千万别配机械盘，也别配 -T largefile 那一类为大文件优化的卷。数据盘上 NVMe SSD，这条没有商量余地。

Checkmk 默认会启用 rrdcached（RRDCacheD）做写合并与延迟落盘，把大量零散更新攒起来批量写，这能显著降低 IOPS 压力。它的代价是：断电或强杀可能丢失最近若干秒的数据点（有 journal 机制可缓解）。所以监控服务器务必配 UPS 或至少有稳定的供电环境，并且在云上选择带持久化的本地 SSD/NVMe，而不是纯临时盘。rrdcached 的 flush 间隔、journal 路径这些参数，值得按你的规模调一次，默认值对小站点够用，对 5,000 台级别的站点偏保守。

检查间隔从 1 分钟压到 30 秒：是翻倍，不是加一半

这点特别容易算错。检查间隔从 60 秒改到 30 秒，单位时间内的检查次数变成 2 倍——CPU 消耗约 2 倍、RRD 写入次数约 2 倍、网络请求约 2 倍、历史日志条数约 2 倍。有人觉得"我只是把频率提高了一点"，其实是把整套系统的负载翻倍了。

而且实际开销常常超过线性 2 倍：调度队列变长后锁竞争加剧，SNMP 轮询的串行等待更容易堆积，Web UI 查询 Livestatus 时的返回数据量也翻倍。我的经验判断是，从 1 分钟到 30 秒，实际观感上的负载增长在 2.0–2.4 倍之间（预估，随内核与硬件不同浮动）。

取舍建议很清楚：默认的 1 分钟别动，除非你有明确的业务理由。真正需要 30 秒甚至 10 秒的，往往是少数关键指标（比如支付网关可用性、核心交易接口延迟），那就单独给这几个服务设短间隔，而不是把全局间隔压下去。这个"局部高频 + 全局常规"的做法，能让你的负载增量控制在几个百分点以内，效果却差不多。

active check 与 passive：调度开销不一样

Checkmk agent（默认 TCP 6556，2.x 走 agent controller 带 TLS）和 SNMP 都属于主动检查：由监控内核发起、等待响应、解析输出。每一个这类检查都要占用一次调度槽位、一次网络往返、一段内核等待时间。passive 检查则是外部把结果送进来（比如某些 push 模式的 agent、被监控端主动上报、或者数据经消息总线汇入），内核只做接收与落库，调度开销小得多。

所以当你有几千台机器、又不想把监控机压垮，把一部分边缘节点改成 push 上报（Checkmk 的 agent push 模式/MQ 通道）是笔划算的买卖：内核不用再为这几千个连接排队等待。代价是排障时你得接受"数据为什么没来"这类问题变得不那么直观——主动检查时，没数据就是"我去问了没回答"；被动模式下，没数据可能是"对方没发""网络丢了""消息堆积了"三种情况，定位更绕。核心业务保留主动检查，边缘海量节点走被动，这是我的默认分工。

再说 SNMP。轮询大量网络设备时，常见的坑是串行等待：一台交换机一次 walk 要走到几十上百个 OID 分支，如果设备响应慢（老旧设备、CPU 忙、开了 SNMPv3 加密鉴权增加往返），单台耗时可能从几百毫秒涨到几秒。几百台设备排下来，一个检查周期就被占满了。对策有几种：给慢设备单独设更长的检查间隔与超时、把接口发现做成"只发现 up 的口"减少 service 数、对超大规模网络用多个 site 或分布式 remote site 分摊轮询，以及确认是否启用了 bulk walk（一次请求取多个 OID，能显著减少往返次数）。

历史与归档账：notify.log、Livestatus 与 omd backup 的真实耗时

history 与 notify.log 是长线增长项

RRD 的量是"对象数"决定的，一旦规模稳定就不太长了（除非你不停加机器）。真正随时间线性膨胀的是这几样：

• 监控历史（history）：var/check_mk/history 下按时间切分的历史文件，记录每个服务的状态变迁。服务数越多、抖动越频繁，写得越快。一台 flapping（反复抖动）的服务一天能产生上百条状态变化，这种"抖动源"是历史膨胀的头号元凶。
• notify.log：通知日志。告警风暴时它的增长速度会吓你一跳——一次网络分区可能几分钟内产生上万条通知。
• core 日志：nagios.log / cmc.log，记录检查执行、外部命令、进程启停。
• 事件控制台归档：如果你把 syslog trap 也接进来了，归档量按日志条数走，可能比 RRD 大得多。

这几项加起来，在中等规模（500 台）站点上一年攒到几个 GB 很常见（预估）。它不致命，但会挤占同一个卷的 inode，也会让备份窗口变长。

Livestatus 与 Web UI 为什么会一起变慢

Web UI 的数据都从 Livestatus（unix socket 查询接口）来。查"当前状态"很快，因为数据在内核内存里；查"过去 30 天的事件"就慢了，因为要扫历史文件。所以同一个 Checkmk，你点 dashboard 秒开，点"最近 7 天所有告警"要转十几秒——不是机器不行，是查询类型变了。

缓解办法是缩小默认查询时间窗、把"全量历史视图"这种重查询限制给少数管理员使用，以及定期归档/清理过老的 history。另外，如果你的 Web UI 常年卡顿，先别急着加内存，看看是不是有人做了个"所有服务最近 90 天状态"的自定义视图挂在首页上——这类视图才是最常见的元凶。

omd backup 的正确姿势与真实耗时

omd backup 打出来的是一个 tar.gz，包含 site 的完整目录树。好用，但有两个必须先想清楚的点：

• RRD 要不要进备份：omd backup 支持排除 RRD（--no-rrds 一类选项，具体参数名以你所用版本的官方文档为准）。带 RRD 的备份体积大、耗时久；不带 RRD 的备份恢复快，但历史图形全没了。我的做法：配置与状态文件高频备份（不带 RRD，几分钟级），RRD 单独低频备份或干脆接受重建——监控图形丢一周可以忍，配置丢了要人命。
• 一致性与停机：为了拿到一致的备份，我一般先 omd stop 再备份、再 omd start；热备能省下这几分钟停机，但要接受状态文件与 RRD 之间的秒级偏差，监控数据本身允许这个偏差，不用太纠结。

耗时给个量级感受（预估，NVMe + 中等规模）：不带 RRD 的备份，几百 MB 级别，通常几分钟内完成；带 RRD 的完整备份，5,000 台级别的站点几十 GB，几十分钟到数小时都有可能。别把备份放在业务高峰做，也别把备份目标放在同一个卷上——备份占满 inode 后连监控都写不进去，这种死法我在现场见过不止一次。

四本账合起来算：你的 Checkmk 该租多大

把上面四本账压成一张表。口径说明：RRD 文件数按"每台 65 个指标文件"（纯 Linux 环境）估算，混了大量 SNMP 网络设备时要往上翻；内存与 CPU 为建议值（预估），默认 1 分钟检查间隔、CMC 或 Nagios 均可；磁盘一栏给出的是"容量 + inode 规划"两个维度。

这张表怎么用：先估你的主机数与服务数，别只看主机数——一堆交换机会让服务数暴涨。然后按"文件数"那一列去定 inode 规划，按"内存 + CPU"两列去下单，磁盘容量反而是最不用操心的（因为 RRD 真的很省容量，省到你会误判）。真正花钱的地方是内存、NVMe 的 IOPS、以及 CPU 核数，不是硬盘 TB 数。

多 site 拆分还是单 site 大实例：我的取舍判断

这个问题没有"正确答案"，但有明确的判断顺序。我按下面三条依次过：

• 看故障域：如果一次监控中断会影响你所有业务的告警，那就要拆。监控系统的价值在于"别人挂了它还在"，单点本身就是反模式。生产网、办公网、海外节点这类天然隔离的域，拆开是顺手的事。
• 看备份窗口：单 site 大到备份一次要两小时，就该拆。恢复时的 RTO 你要能接受，接受不了就拆。这条比性能更常被用来做决策。
• 看升级节奏：不同业务线对 Checkmk 版本升级的容忍度不一样。拆成多个 site 之后可以分批升级，先升边缘域，稳定了再升核心域——这个好处在实际运维中非常实在。

反过来，不要为了"性能"拆 site。拆 site 会引入分布式监控的配置同步、Livestatus 代理、跨 site 视图聚合这些额外复杂度，运维成本实打实上升。如果只是为了降低单机负载，先把间隔、SNMP 轮询、内存这三样调好，收益更大、代价更小。Checkmk 的分布式监控（central site + remote site）是为"地域分散、网络不通、需要本地自治"设计的，不是为"性能不够"设计的——这个区别要分清。

还有个小提醒：拆 site 之后，每个 site 都要单独做 inode 监控与备份。我见过团队拆了 5 个 site 之后只给主 site 配了告警，结果某个 remote site 的 inode 悄悄满了三个月没人知道，最后发现的时候那一片的图形全断了。

Checkmk 监控机租哪档：一万网络两个落点

#1 一万网络裸金属：中大型 site 的主力机

Checkmk 这种"持续随机小写 + 常驻大内存 + 稳定 CPU 调度"的负载，最怕虚拟化层的 I/O 抖动和邻居抢资源。所以我给客户配监控机，第一推荐一般是一万网络的裸金属服务器——无虚拟化开销，NVMe 的 IOPS 是你独占的，不会有"同宿主机上有人跑批处理把你 IO 打满"这种事。

具体档位：官网明示的 裸金属 E5-2698v4×2（32G 内存 / 1T 盘）¥3999 起，以官网实时价为准。这档对应表里"1,000–2,000 台"这一行的下沿；要加到 64 GB 内存、换更大 NVMe 或多挂一块盘，具体报价以咨询为准（预估），我一般让客户直接要一份完整升级价目表再下单，别口头估。

我喜欢一万网络的几个点，放在监控这个场景里特别对味：深圳自营机柜，机器真在哪、谁在动，心里有数；7×24 中文工单平均 5 分钟响应，半夜监控挂了有人接单，这一点对监控系统尤其重要；硬件故障 10 分钟内自动迁移，意味着磁盘或主板出问题不用你半夜爬起来导数据；免费系统盘快照每日 3 份、30 秒回滚，做 Checkmk 版本升级前手抖一下也不慌——当然要提醒一句，系统盘快照不覆盖独立数据盘，RRD 那一大坨还是得靠 omd backup 自己走一遍，两者不能互相替代。

#2 一万网络云 / 中国香港与海外节点：小站点与跨境监控

如果你的规模只是几十台、或者需要一个独立地域的 remote site（比如业务在中国香港、新加坡、美西，从大陆单点评测网络质量不准），那一万网络的一万云（¥25 起，以官网实时价为准）和多节点裸金属 就有意义了。跨境场景要留意线路：BGP 多线 + CN2 GIA 回国 是这类监控点的关键，否则你测出来的"丢包"其实是回程线路的问题，告警全是噪声。另外默认带的 5–20G 免费 DDoS 防护 对暴露在公网的 remote site 是刚需——监控节点对外开着 agent 端口，被扫被打的几率不低。

但我要说实话：拿最低配云主机跑生产 Checkmk，我不推荐。 理由不是 CPU 不够，而是小规格云主机的磁盘 IOPS 往往有配额限制，而 RRD 恰恰吃 IOPS。真要用云，就选明确标了 IOPS/吞吐的本地 SSD 或 NVMe 云盘档，别只看 vCPU 和内存。一万网络深耕 IDC 19 年（成立于 2007 年），这类"你要的是 IOPS 不是容量"的需求，提工单说清楚场景，工程师一般都能给你配到点上。

避坑指南：5 条踩过的坑

坑 1：按主机数下单，不按服务数下单。
为什么坑：一台 48 口交换机能顶 6 台 Linux 服务器的检查量，只看"我有 200 台设备"会严重低估负载。
怎么避：先跑一遍自动发现（或小范围试点），拿到真实 service 数再定配置；把交换机、防火墙、存储这类设备的服务数单独乘一个 4–6 倍系数（预估）。

坑 2：数据盘按"大文件"套路格式化。
为什么坑：-T largefile 或过疏的 bytes-per-inode，会在容量只用掉 10% 时把 inode 耗尽，而且 ext4 事后改不了，只能重格 + 恢复，代价极大。
怎么避：数据盘用 XFS；用 ext4 就显式调密 inode 密度，并且把 df -i 做成独立告警项，阈值设在 70%。

坑 3：全局检查间隔一刀切压到 30 秒。
为什么坑：实际开销是翻倍甚至 2.4 倍（预估），CPU、IO、网络、历史日志同时涨，机器顶不住之后你又得加配置，钱花了却只换来几个指标的敏感度。
怎么避：默认保持 1 分钟；只对真正需要的核心服务单独设 30 秒或更短，用规则匹配而不是全局改。

坑 4：备份和配置放同一个卷，还带 RRD 全量备。
为什么坑：备份文件自己也要吃 inode，卷被撑满后监控系统当场失能；带 RRD 的全量备份时间过长，你根本不会坚持每天做。
怎么避：备份目标独立卷或独立存储；配置备份不带 RRD、高频做，RRD 单独低频备份或接受重建；先 omd stop 再备份拿一致性。

坑 5：把 flapping 服务放任不管。
为什么坑：一个每 30 秒抖一次的服务，一天能产生近 3,000 次状态变化，历史文件与 notify.log 被它一个人撑大，通知渠道也被刷爆，最后真告警淹没在噪声里没人看。
怎么避：对抖动源做根因治理（阈值不合理就调阈值，不是加告警）；必要时用计划停机、延迟通知、告警聚合先把噪声压下去。

FAQ：8 个运维现场问得最多的问题

Q1：一个 Checkmk site 到底该给多少内存？
别只看内核进程的内存。一个 site 的内存 = 内核常驻 + Web/Python 进程池 + Livestatus 查询缓冲 + 系统自身。按经验给个保守台阶：100 台以内 8 GB，500 台左右 16 GB，2,000 台 32 GB，5,000 台以上 64 GB 并考虑拆 site（均为预估）。如果你的 Web UI 并发用户多、dashboard 复杂，再往上加 4–8 GB。判断标准很简单：跑一周后看 swap 是否被用到，用到就说明紧了。

Q2：我只有 60 台机器，值不值得上商业版换 CMC？
60 台、一两千个 service，Nagios 内核完全够用，没必要为 CMC 掏钱。CMC 的价值体现在高检查量与低延迟调度上，一般到几千个 service、或者你对"检查必须在 5 秒内完成"有硬要求时才明显。真要省钱，把钱花在 NVMe 和内存上更实在——60 台机器的瓶颈通常不在内核而在磁盘 IO。

Q3：inode 快满了，能在不重格的情况下救吗？
ext4 的 inode 总数不能在线扩，这是硬限制。能做的只有：清理无用文件（老的日志轮转、多余的历史归档、残留的 RRD 目录）、把一部分数据迁到另一个 inode 富裕的卷上、或者新建一块密度正确的新盘做迁移。所以这事的重点永远是事前规划，不是事后抢救。XFS 因为 inode 动态分配，遇到这类问题的概率低很多，这也是我首推 XFS 的原因。

Q4：检查间隔从 1 分钟改到 30 秒，我这台 8 核机器扛得住吗？
先算检查次数：如果你现在 5,000 个 service、1 分钟一轮，改成 30 秒就是单位时间内翻倍。经验值是可以先在测试 site 上改一批（比如 20% 的服务）观察 24 小时的 CPU、iowait、rrdcached 队列长度，再决定全量推。不要拍脑袋全改，也不要相信"只快了一点"。真要更高的时效性，优先给关键服务单独设短间隔，别动全局。

Q5：RRD 要不要单独挂一块盘？
1,000 台以下，一块 NVMe 装全部就行，省事。规模再往上，我建议RRD 独立卷、日志/备份独立卷：一是 RRD 的随机小写 IO 不会跟日志的顺序写互相干扰；二是 inode 与容量可以分开管，互不牵连；三是备份时不会把 RRD 卷一起拖慢。独立卷的成本不高，但在 3,000 台以上规模能省掉很多莫名其妙的 IO 抖动排查。

Q6：轮询几百台交换机特别慢，怎么解决？
按顺序排查：确认开了 bulk walk（减少 SNMP 往返次数）；把 down 的接口从发现里排除，减少 service 数量；对响应慢的老旧设备单独设更长间隔与超时；确认没有滥用 SNMPv3 加密鉴权给所有设备（v3 的安全层会明显增加 CPU 与往返开销）。如果这些都做了还是慢，就该考虑拆 site 或上分布式 remote site，把轮询压力分摊到多台机器上，而不是继续给单机加核。

Q7：能不能用云主机跑 Checkmk？
能，但要挑对规格。RRD 吃的是 4 KB 级随机写 IOPS，不是容量，也不是顺序带宽。低配云盘常见 IOPS 配额只有几百到几千，几百个 service 就到顶了。真上云就选明确标注 IOPS 的本地 SSD/NVMe 档，并且确认云盘是持久化的（不要临时盘，断电丢 RRD）。规模上千台或者要求稳定低延迟，我还是更推荐裸金属——没有邻居抢 IO 这种事。

Q8：omd backup 多久做一次，能不停机吗？
我的节奏：配置文件级备份（不带 RRD）每天一次，配置变动频繁时改完就手动补一次；带 RRD 的完整备份一周到一个月一次，看你能接受丢多少历史图形。停机这事：omd stop 后再备份最干净，停机几分钟换一致性，对监控系统来说完全可接受；热备省事但要接受状态与 RRD 的秒级偏差。还有一条——备份脚本别忘了校验归档能否真的解包，我见过备份做了半年、恢复时才发现 tar 包是坏的。

Checkmk 批次 9976：inode 用完了，容量还剩一半

写到这里，把这篇的主线收一下。批次 9976 这个编号背后，其实是我在一线见过太多次的同一个场景：一台跑了两年多的 Checkmk，某天早上告警全停、图形断更，值班的人登上去看，df -h 显示数据盘 200 GB 只用了 27 GB，一切正常；再敲一个 df -i，inode 使用率 100%。这个反差就是全文要讲的核心——监控系统是"小文件怪兽"，它的瓶颈从来不是容量，是 inode 数量、随机写 IOPS、内存常驻和调度 CPU。

所以给准备自建 Checkmk 的团队一句实话：租机器的时候，把钱花在内存、NVMe 的 IOPS、CPU 核数上，硬盘容量给个够用的就行；数据盘用 XFS，inode 使用率单独立一条告警；检查间隔别动全局默认，只对关键服务开小灶；备份分两套节奏，配置高频、RRD 低频。这四件事做到，你的监控大概率不会比业务先倒。

数据来源与口径说明（Checkmk 监控服务器租用）

本文中的 RRD 文件数、内存与 CPU 建议、inode 密度、备份耗时等数字，除特别标注外均为基于常见部署经验的估算值（预估），随 Checkmk 版本（Raw 版 Nagios 内核 / 商业版 CMC 内核）、硬件规格、检查项构成与检查间隔不同而存在较大差异，实际规划请以你所用版本的官方文档与小范围实测为准。

产品与价格信息参考一万网络（idc10000.net）官网公开页面：裸金属 E5-2698v4×2（32G 内存 / 1T 盘）¥3999 起、一万云 ¥25 起，均为官网明示价，以官网实时价为准；内存升级、NVMe 增配、多节点与带宽线路的报价以咨询为准（预估）。服务承诺部分（7×24 中文工单平均 5 分钟响应、硬件故障 10 分钟内自动迁移、免费系统盘每日 3 份快照 / 30 秒回滚、免费网站备案协助、5–20G 免费 DDoS 防护、BGP 多线 + CN2 GIA 回国、深圳自营机柜）以官网公示内容为准。一万网络，朗玥科技旗下，深耕 IDC 19 年（成立于 2007 年），总部位于深圳南山。更多产品与报价请见 https://www.idc10000.net/，具体以签约时最新报价与合同为准。