很多团队决定自建 Zabbix 的起因都特别朴素：云监控的自定义项不够用，交换机端口流量想自己画图，告警想按自己的升级规则发到群里。真开始装的时候，网上教程清一色教你装包、改 zabbix_server.conf、配个 MySQL，跑起来也确实挺顺。问题通常出在三个月后——history_uint 表涨到两三百 G，housekeeper 一启动数据库就卡，前端点开"最近一年"的图转圈半分钟，周末夜里告警风暴把整个值班群炸穿。这些事跟 Zabbix 版本关系不大，本质是高频时间序列写入和关系型区间查询这俩完全不同的负载，被压在了同一块普通 SATA SSD 上。
这篇不写安装步骤，那玩意儿官方文档写得比我好。我把这几年给客户搭监控体系时反复验算、反复返工的东西整理出来：采集量怎么换算成 NVPS、NVPS 怎么落到磁盘 IOPS 和容量、内存到底该优先给数据库还是给 Zabbix Server、主动式和被动式对公网带宽的消耗差多少、什么规模该把 Server 和数据库拆开。所有数字我都写明估算口径，你可以照着自己实际的监控项数重算一遍，而不是照抄。
先给结论，后面逐条展开：
先算 NVPS 再谈配置。NVPS（每秒新值数）＝ 监控项总数 ÷ 平均采集间隔（秒）。这个数算不出来，后面所有硬件选型都是拍脑袋，包括买多快的盘。
历史库必须放 NVMe，而且最好是独立的一块。Zabbix 的写入是持续不断的小随机写，机械盘在这个场景下不是慢，是根本扛不住。
保留期才是最贵的配置项。同样 400 NVPS，留 30 天和留 1 年，磁盘容量差了一个数量级，IOPS 压力却差不多——贵的是空间不是性能，所以先把保留期想清楚。
跨公网一律主动式 Agent，异地机房一律上 Proxy。被 Server 挨个轮询的被动式，在跨公网场景里既费带宽又费连接数，还容易因为一个节点抖动导致队列堆积。
内存要分成两半想。数据库那边的 buffer pool 管的是"查得快不快"，Zabbix Server 自己的 HistoryCache、ValueCache 管的是"写得进写不进"，两边任何一个不够，表象都是"前端卡"。
问一个运维"你有多少台机器"，他大概率答"大概两三百台"。这个数字对选型几乎没用。同样 300 台，只采 CPU、内存、磁盘、网卡这四项基础指标，和把 MySQL 的 60 多个状态变量、Redis 的命中率与键空间、Nginx 各 upstream 的连接数全部纳进来，采集压力能差五六倍。Zabbix 的官方模板里，Linux 主机基础模板大约 30–40 个监控项，MySQL 模板展开后轻松到 80–120 项，带自动发现（LLD）的文件系统、网卡、磁盘发现规则还会随机器配置动态增加。
很多人把 Zabbix 当"服务器监控"用，实际上它最不可替代的部分是 SNMP。一台 48 口交换机，如果按端口采集入出流量、错包、丢弃、端口状态，一个端口 4 个 OID 就是近 200 个监控项；一个机房十几台交换机，光网络设备的指标数就能顶得上几百台服务器。SNMP 的麻烦在于它按 OID 逐个轮询，一次 GetBulk 能凑一批，但接口表大的设备单次轮询包并不小，而且设备本身的 SNMP 处理是单线程排队，轮询太密会直接把交换机 CPU 打高——我见过把核心交换机轮询间隔设成 10 秒，结果交换机的 SNMP 进程占了 30% CPU，业务没出问题，网管自己先成了故障源。网络设备的采集间隔给 60 秒甚至 120 秒就够了，端口流量这种指标，精度到分钟已经足够定位问题。
按经验，NVPS 在 100 以下，随便一台 4 核 8G、带 SSD 的机器都能跑得很舒服；NVPS 到 300–500，数据库开始出现明显的写入抖动，前端查一周以上的图开始变慢；NVPS 过 1000，如果历史数据保留超过 90 天且没做分区，housekeeping 的删除操作会让数据库在维护窗口内基本不可用。拐点不在 Zabbix Server 上——Server 进程本身是轻的，它把值收进来塞进缓存就返回了，真正的瓶颈始终是后面那个数据库。
公式本身一句话：NVPS ＝ 监控项总数 ÷ 平均采集间隔（秒）。比如 300 台服务器、平均每台 80 个监控项，总共 24000 项；其中六成是 60 秒间隔、四成是 300 秒间隔，加权平均间隔大约 156 秒，那么 NVPS ≈ 154。这个数才是你选盘的依据。
三个容易算错的地方。第一，自动发现项要算进去。磁盘分区、网卡、Docker 容器、K8s Pod，这些 LLD 规则生成的监控项数量会随业务增长，你今天算 24000，半年后可能是 35000，规划时留 30–50% 余量。第二，触发器不算写入量。触发器只做计算不产生历史值，但它吃 ValueCache 和 CPU。第三，日志类监控项是个异类。日志、文本这类监控项不进 history_uint，而是进 history_log / history_text，单行体积是数值项的几十倍，如果你开了日志采集，容量估算要单独算，别混在一起。
数值型监控项按类型分表：整数进 history_uint，浮点进 history，字符串进 history_str，日志进 history_log/text。绝大多数系统指标是整数，所以 history_uint 是增长主力。单行记录的裸数据很小，但 InnoDB 里还要算上主键、索引、行头开销和页填充率，加上 redo log 和 binlog 的写放大，落到磁盘上的实际占用通常按每值 80–120 字节估算比较稳妥（这是经验估算值，具体取决于表结构、索引数量和 MySQL 版本，你要精确数字就得拿自己环境跑一周再反推）。
按每值 100 字节这个保守口径算一笔账：400 NVPS 意味着每秒 400 个值，一天就是 400 × 86400 ≈ 3456 万个值，约 3.46 GB/天。保留 30 天约 104 GB，90 天约 311 GB，365 天约 1.26 TB。如果大部分值是 history_uint 且开了表压缩、索引精简，实际可能下探到 50–60 字节/值，容量打对折；反过来如果日志项多、字符串项多，往上翻几倍也正常。所以我的建议是：先按 100 字节算，跑满一个月后用 information_schema.TABLES 里的真实 data_length 除一下累计值数，拿到你自己环境的真实字节数，再回头调保留期。
Zabbix 会把历史值按小时聚合进 trends 表（trends / trends_uint），存的是每小时的最小值、平均值、最大值和计数。这意味着看"最近一年"的图时，Server 读的是 trends 而不是 history，数据量缩小到几百分之一。所以真正合理的配置是：历史明细保留 30–90 天，趋势数据保留 1 年甚至更久——趋势表的增长量级只有历史表的一个零头，一年下来通常也就几十 GB。很多人为了"查得细"把 history 留一年，白白多买一两个 T 的 NVMe，其实 90 天以上的问题复盘，看小时级趋势足够了。
Zabbix 的写入模式是持续、均匀、小块、随机（按 itemid + clock 分布）的插入。InnoDB 接到一个逻辑写，实际落到盘上的量远不止数据本身：要写 doublewrite buffer，要写 redo log，如果开了 binlog 还要再写一份，后台线程再把脏页刷回表空间。实际落盘量通常是逻辑写入量的 2–4 倍——也就是说，你算出来 3.46 GB/天的数据，磁盘实际承受的是 7–14 GB/天的写入。普通企业级 SATA SSD 的持续写入和 DWPD（每日整盘写入次数）本来就是按读多写少设计的，天天这么灌，一年多就到寿命；机械盘更不用想，随机小写的 IOPS 就那么几十，队列一堆积，插入延迟从毫秒级跳到秒级，Zabbix Server 的写入队列跟着满，最后表现为"监控数据出现断档"。
Zabbix 清理历史数据有两种模式。老式的 housekeeping 是 Server 按配置定期发 DELETE 语句，一次删一批；删 history_uint 这种大表时，DELETE 会产生大量 undo、长时间持锁、并且删完之后表空间不释放（需要 OPTIMIZE TABLE 才能回收，而 OPTIMIZE 是重建整表，几小时起）。新版本支持按时间分区（MySQL 分区表或 PostgreSQL + TimescaleDB），清理时不再是 DELETE，而是直接 DROP 整个过期分区——这是元数据操作，秒级完成，几乎不产生 IO。
取舍很清楚：如果你的历史数据量在 100 GB 以内、保留期不长，housekeeping 够用，配好 HousekeepingFrequency 和 MaxHousekeeperDelete（单次删除条数上限）就行；一旦超过这个量级，或者业务要求保留 1 年以上，就必须上分区。MySQL 原生分区需要自己做维护脚本（或用外部工具），TimescaleDB 的 hypertable + 自动 retention policy 是更省心的方案，代价是运维多一个组件、多一套备份策略。
按上面的算法，400 NVPS 折算成数据库事务大约是每秒几百次插入（Server 会批量提交，实际 TPS 低于 NVPS），峰值时可能上千。单看数字，一块入门 NVMe 的随机写 IOPS 都有几万，似乎绰绰有余。真正吃 IOPS 的不是插入，是三件事：housekeeping 的删除、大区间查询的回表、以及备份。删除和备份是突发的大块 IO，会和在线插入抢队列。所以我的经验值是按"NVPS × 10"来预留 IOPS 余量，并且把历史库单独放一块盘，跟系统盘、MySQL binlog 分开——混在一块盘上，备份一跑，监控就断。
下面这张表是我给客户做选型时用的底稿，三档对应三种典型规模。价格列写的是官网明示的起步价，配置是实测跑得动的组合，不是厂商推荐的最小配置。
| 规模档位 | 典型 NVPS（估算） | 推荐硬件规格 | 参考月租 | 关键提醒 |
|---|---|---|---|---|
| 小规模（≤50 台） | 50–100 | 4 核 8G、240–480G SSD、5–10M 带宽，Server 与数据库同机部署 | 华南 ¥799 起 / 一万云 ¥25 起（官网明示价，以官网实时价为准） | 历史留 30 天足够，别一上来留一年 |
| 中等规模（约 300 台） | 300–600 | 8–12 核 32–64G、1–2T NVMe、内网互联 1G，历史库独立盘 | 裸金属 E5-2620 32G/1T ¥999 起（官网明示价，以官网实时价为准） | 到这个量级就该把 housekeeping 换成分区维护 |
| 大规模（≥1000 台） | 1000–2000+ | 双路 E5-2698v4×2、128–256G 内存、2–4T NVMe、Server 与数据库分离部署 | 裸金属 E5-2698v4×2 ¥3999 起（官网明示价，以官网实时价为准） | 上 Proxy 分摊采集，趋势与历史分档保留 |
| 异地 Proxy 节点（每台） | 100–300 | 4 核 8G、200G SSD，就近接入本地内网，批量回传 | 华东 ¥699 起 / 华北 ¥899 起 / 华西 ¥599 起 / 中国香港 E3 ¥1500 起（官网明示价，以官网实时价为准） | Proxy 只做采集回传，本地库可选 SQLite 或 MySQL |
表格里的价格是月付起步价。如果监控体系是长周期投入（基本都是），年付通常比月付划算——行业通用做法是年付较月付省 1–2 个月，折算约 83–92 折（预估价格，非官方报价，实际以咨询/下单时核算为准）。另外提醒一句：起步价对应的是基础配置，加内存、加 NVMe 数据盘、升带宽都是按项加钱的，下单前让服务商把每一项单价列清楚，别只看那个"起"字。
InnoDB 的 buffer pool 缓存数据页和索引页。Zabbix 的查询有明显的热数据特征——绝大多数查询落在最近几小时的 history 和 trends 上，更早的数据只在做复盘时才碰。所以 buffer pool 的原则是能装下"最近 24–72 小时的 history + 全部 trends + 索引"。按前面的估算，400 NVPS 下一天历史约 3.5 GB，加上索引实际热区大概 8–12 GB，那数据库给 16 GB 内存、buffer pool 设 10–12 GB 就很宽裕；如果历史留 90 天且 NVPS 上千，热区会到 30 GB 以上，这时该考虑 64 GB 内存而不是死磕参数。
一个常见的错误是一上来就把 buffer pool 设成物理内存的 80%，结果系统其他进程和 OS page cache 被挤没了，MySQL 反而因为 swap 抖动。数据库专用机器给 60–70% 是稳妥值，如果 Server 和数据库在一台机器上（小规模常见），buffer pool 别超过物理内存的一半。
Server 的缓存参数在 zabbix_server.conf 里，混着看容易乱，按职责拆开就清楚了：HistoryCacheSize 是收进来的值在写入数据库前的暂存区，写库卡住时它顶在前面，给太小会导致采集侧的队列积压；HistoryIndexCacheSize 配合 HistoryCache 做 itemid 索引，在带分区的数据库上必须开，否则 history 写入性能会明显下降；TrendCacheSize 暂存小时聚合的中间结果；ValueCacheSize 缓存所有数值型监控项的当前值，触发器计算全靠它，这个参数不够会直接报错或者让触发器计算退化成查库。
默认值（HistoryCacheSize 16M 那一档）在几百 NVPS 的场景下是够的，但到了千级 NVPS，我一般把 HistoryCacheSize 提到 256M–1G，TrendCacheSize 提到 128M–256M。ValueCacheSize 要按监控项数算：每个数值项大约占用 100–200 字节（经验估算），24000 个数值项就是 3–5 MB，给它 64M–128M 基本覆盖到十万级监控项，留足余量。判断标准很简单：看 Server 日志里有没有 "value cache is full" 之类的告警，看前端"队列"面板里 5 分钟以上的延迟项占比，有就往上加。
Zabbix Server 是单进程多线程模型，poller 线程数（StartPollers）决定并发采集能力，预处理（StartPreprocessors）、LLD、trigger 计算各有线程。CPU 通常在 NVPS 上千时才需要考虑 8 核以上。真正吃 CPU 的是两件事：一是大量使用 JavaScript 或正则的预处理规则，二是一次性打开几千个监控项的大屏。前者能改就改成简单的乘法或正则简化，后者干脆别做，改用预先聚合的图表。
被动式（Server 主动连 Agent）下，每一个监控项、每一轮采集都是一次独立的请求加响应。粗略按单次交互 150–250 字节算（Zabbix 协议头 + JSON 载荷，实际取决于 item key 长度和返回值），1000 台机器、每台 80 项、60 秒间隔，就是每秒约 1300 次交互，流量在 200–350 KB/s，也就是 2–3 Mbps 上下（这是按字节估算的量级，实际抓包会更高一些，TCP 头和握手开销没算进去）。看着不大，但这些流量是持续稳定且连接数极高的——Server 要维持上千个并发连接，跨公网时 NAT 会话表、防火墙连接跟踪都是负担，碰到网络抖动，未完成的采集会堆进队列，恢复后集中爆发。
主动式（Agent 主动找 Server）的流程是：Agent 每隔一段时间向 Server 拉一次自己该采哪些项，然后本地采集完，攒成一批一次性推给 Server。同样 1000 台、80 项，假设每 120 秒推一次、单批载荷约 10 KB，平均下来是 1000 × 10KB / 120s ≈ 83 KB/s，不到 1 Mbps，而且连接数从"每秒上千次短连接"变成"每两分钟一次长连接复用"。省的不是带宽那几兆，是连接数和抖动时的恢复能力。所以在跨公网、跨机房的场景里，我一律默认主动式；只有在同一个内网、机器数量不多、且需要 Server 端灵活控制采集节奏的场景，被动式才更方便。
SNMP 的流量跟 OID 数量成正比，单次 GetBulk 能打包几十个 OID，一个 PDU 通常几百字节到几 KB。真正的问题是轮询频率：一台 48 口交换机按 4 个 OID/端口、60 秒间隔，单台每秒不到 10 个请求，十几台加起来也就每秒一两百个请求，流量可以忽略。但如果你把间隔开到 10 秒，请求量翻 6 倍，交换机 SNMP 进程先扛不住——这是典型的"流量不大但把对方打死了"。
异地 Proxy 的价值恰恰在这里：它在本地机房用内网采集所有被监控对象，然后把数据批量、压缩、单连接回传给中心 Server。假设华南是主节点、华东有一批机器要监控，如果让华南的 Server 直接跨公网轮询华东的每一台，那是一千个跨公网的短连接；放一台 Proxy 在华东，就变成一个持续的长连接。Proxy 本地还要一块盘存来不及回传的数据（断网时能撑一段时间，恢复后补传），所以 Proxy 的磁盘不用大但要稳。
三条判断标准，命中任意一条就该拆：NVPS 稳定超过 500；历史保留期超过 90 天且数据量过 200 GB；前端要做跨月、跨年的容量报表。原因是这两种负载对资源的需求方向相反——Server 要的是 CPU 线程和少量缓存，数据库要的是内存和磁盘 IO，挤在一台机器上必然互相抢。我见过最惨的一台，Server 的预处理线程把 CPU 打满，数据库的插入跟着排队，最后两边一起超时。
拆开的前提是两台机器之间的内网互联要快且稳。同机房内网互联（1G 或 10G）延迟在亚毫秒级，完全够用；跨机房拆是另一回事，数据库和 Server 之间每一条 SQL 都要走公网，延迟从 0.2ms 变成 20ms，批量插入被拆成多次往返，性能会断崖式下降。原则：Server 和数据库必须同机房同内网，异地只放 Proxy，不异地拆数据库。
多一台机器就多一套东西要管：操作系统补丁、数据库备份、监控自身的监控（是的，Zabbix 也得被别的东西盯着，不然它挂了你不知道）。另外拆开之后，备份策略要重新设计——只备份数据库不够，Server 的配置文件、前端的自定义脚本、告警媒介配置也得一起备份。这也是为什么小规模场景我反而建议不拆：一台 8 核 32G 带 NVMe 的机器，跑 300 台的采集量绰绰有余，省下来的运维精力比省下来的那点性能值钱。
关键词维度：E5-2620 / 32G / 1T / 华南节点 / ¥999 起 / BGP 多线 / 自营机柜 1 分钟上架
推荐配置：裸金属 E5-2620、32G 内存、1T 存储起步，华南机房 BGP 多线接入。这个档次跑 300 台以内、NVPS 300–500 的量级是合适的：CPU 线程够开几十个 poller，32G 内存能切出 8–12G 给 buffer pool、再留足 Server 缓存，1T 空间在这个 NVPS 下够存 90 天历史加一年趋势，如果保留期要拉到一年，加一块 NVMe 数据盘即可。
价格参考：裸金属 E5-2620 32G/1T ¥999 起（官网明示价，以官网实时价为准）；同节点华南起步价 ¥799 起，华东 ¥699 起、华北 ¥899 起、华西 ¥599 起，可按被监控机器的分布就近选节点。加内存、加数据盘、升带宽按项计费，下单前建议让客服把增项单价列全。
为什么选这台：监控系统的核心诉求是"一直在"。一万网络深耕 IDC 19 年（成立于 2007 年），深圳南山总部，自营机柜最快 1 分钟上架，硬件故障 10 分钟自动迁移——这一条对监控系统尤其关键，宿主机出问题的时候你不希望同时失去监控能力。配套还有系统盘每日 3 份快照、30 秒回滚（数据库误操作后的救命稻草）、5–20G DDoS 防护、7×24 中文工单平均 5 分钟响应、免费网站备案协助。真出事了，5 分钟有人回工单，比什么都实在。
关键词维度：E5-2698v4×2 / 双路高核 / 大内存 / 2–4T NVMe / Server 与库分离 / ¥3999 起
推荐配置：两台同机房裸金属，一台跑 Zabbix Server + 前端，一台跑数据库。数据库这台用双路 E5-2698v4×2（核心数拉满，preprocessor 和查询都吃线程），内存按需上到 128–256G，存储配 2–4T NVMe，历史库独立盘、binlog 再单独一块。Server 这台配置可以低一档，把预算压在数据库上。
价格参考：裸金属 E5-2698v4×2 32G/1T ¥3999 起（官网明示价，以官网实时价为准）。内存升级、NVMe 数据盘、10G 内网互联属增项，需要按实际配置核算——超大内存与多盘 NVMe 的组合报价通常属于定制核算范围（预估价格，实际以咨询/下单时核算为准），别按起步价做预算。
适用场景：1000 台以上服务器、NVPS 上千、历史明细保留 90 天以上、需要在多个异地机房部署 Proxy 回传、监控数据要作为容量规划和复盘依据长期留存的团队。网络侧走 BGP 多线加 CN2 优化回国，异地 Proxy 回传的延迟和稳定性有保障。
Proxy 本身很轻：4 核 8G、200G SSD，它只负责采集和回传，本地库在小规模下用 SQLite 都能跑。异地 Proxy 节点用一万云弹性实例（¥25 起，官网明示价，以官网实时价为准）性价比很高，业务量涨了直接升配，不用为了一个 Proxy 去租整机。海外或中国香港有机器要纳入监控的，可以在中国香港节点放一台 E3 档（¥1500 起，官网明示价，以官网实时价为准）当 Proxy，本地采集后回传内地中心节点，比从内地跨网轮询稳定得多。节点覆盖华南、华东、华北、华西、中国香港及海外，基本能覆盖常见的多机房布局。
为什么坑：Zabbix 装好后默认什么都往一个库里写，系统盘通常是 SATA SSD 甚至机械盘，几百 NVPS 的持续小写会把它压死，表现是数据库插入延迟升高、Server 队列积压、最后监控图上出现断断续续的空洞。更麻烦的是系统盘写满了会导致整个系统卡死，连 SSH 都进不去。
怎么避：历史库必须独立一块 NVMe，系统盘和数据盘物理分开；如果预算实在紧，至少保证是 SSD 且把 innodb_flush_neighbors 关掉、把 binlog 挪到别的盘。上线前用 fio 做一次 4K 随机写测试，把真实 IOPS 记下来，别信标称值。
为什么坑：保留期每翻一倍，磁盘容量翻一倍、备份时间翻一倍、housekeeping 的删除量也翻一倍。设成 365 天又不分区的结果就是：每天凌晨 housekeeping 跑 DELETE，几十万行地删，产生巨量 undo，删到一半把 IO 吃光，正好和你的备份窗口撞上，两边一起超时。删完表空间还不释放，磁盘照样是满的。
怎么避：历史明细 30–90 天、趋势数据 1 年起，这是绝大多数团队的最优解。数据量过 100 GB 就上分区（MySQL 分区表或 TimescaleDB），用 DROP PARTITION 代替 DELETE。如果暂时不想动分区，至少把 MaxHousekeeperDelete 调小、把维护窗口挪到业务低峰，并且定期 OPTIMIZE 回收空间。
为什么坑：默认参数面向的是"几百个监控项"的小环境。到了几千上万项，HistoryCache 太小会在数据库抖动时立刻溢出，ValueCache 不够会让触发器计算退化成逐条查库，TrendCache 不够会让小时聚合反复重算。这些问题的表象都是"Zabbix 好卡"，但根源完全不同，不看日志根本定位不到。
怎么避：上线前按监控项数把 ValueCacheSize、HistoryCacheSize、HistoryIndexCacheSize、TrendCacheSize 四个参数一次性调到位（前面给过估算方法），之后每周看一次 Server 日志和前端的队列面板，把"5 分钟以上延迟项"当作核心健康指标盯着。
为什么坑：跨公网被动式的问题不是带宽，是连接数和故障放大。一次网络抖动，几百个采集请求全部超时，恢复后集中重试，把队列挤爆；防火墙的会话表被短连接塞满，可能影响同链路上的其他业务；Agent 端口还要逐台开放，安全策略上也不好看。
怎么避：跨公网、跨机房一律主动式（Agent active），异地机房部署 Proxy 做汇聚回传。只在内网、机器数量可控的场景保留被动式。混合使用是完全可以的——同一台 Server 上，A 机房走主动式、B 机房走 Proxy、本机走被动式，按实际拓扑配就是了。
为什么坑：一台核心交换机抖动，下面几百台机器的"网络不可达"触发器全部触发，一个故障变成几百条告警，值班的人直接麻木，真正的根因反而被淹了。更糟的是没有升级机制——告警发了没人响应，也没有维护期，计划内的割接照样刷屏。
怎么避：三件事必须做：配置主机与触发器的依赖关系（dependency），父节点故障时抑制子节点的告警；配置告警升级（action 里按未确认时长逐级上报）；配置维护期（maintenance），计划内变更期间抑制告警。再加一条：告警内容里带上最近一次值和触发阈值，别让人看到告警还得去翻图。
说句实在话，Zabbix 不是所有团队的最优解。三种情况下我一般劝退：第一，被监控对象在 20 台以内。这个量级自建一套 Zabbix，光是维护数据库、升级版本、调保留期的时间成本就超过收益，云监控自带的 Agent 加几个自定义指标足够。第二，团队里没有能持续投入的人。监控系统最怕的是"搭起来就没人管"——版本不升、磁盘满了没人知道、告警规则从上线那天起再没改过。一套没人维护的 Zabbix 比没有监控更危险，因为它给你一种"我有监控"的错觉。第三，只需要可用性探测和粗粒度指标。HTTP 探活、Ping 丢包、带宽总量这些，云监控按量付费几十块一个月就全解决了，没必要自己扛一个数据库。
反过来，有几种情况自建几乎无替代：内网设备和无法安装公有云 Agent 的环境（生产线设备、隔离网段、老系统）；需要高度自定义的业务指标（队列积压数、订单成功率、自研中间件的内部状态）；监控数据必须留在自己手里（合规或客户要求，数据不出内网）；需要跨多个机房、多个云统一视图。这几种场景下，Zabbix 的灵活性和可掌控性值回票价。
中间地带也有一条路：用租用的裸金属自建，把运维复杂度压到最低。选有 7×24 中文工单、硬件故障能自动迁移的服务商，你只管应用层，硬件和网络的脏活累活交给对方。对绝大多数中小团队，这比"自己买机器托管"和"全上公有云"都划算。
看你想要什么。如果只要 CPU、内存、磁盘、端口存活这几项，坦白说没必要，云监控加 Agent 半小时搞定，一个月几十块钱。但如果你要监控内网交换机、要自定义业务指标、要自己定义告警升级规则，那 50 台反而是自建的最佳起点——规模小、压力小，正好把整套体系跑顺，等涨到 300 台时你已经把坑踩完了。硬件上一台 4 核 8G 带 SSD 的机器就够，华南节点裸金属 ¥799 起（官网明示价，以官网实时价为准），成本并不高。
用前端的"监控项"列表按主机群组分类型统计出总数，然后看每个模板的采集间隔——基础 Linux 模板大多 1m，网络设备模板常见 5m，业务自定义项可能是 10m。加权算平均间隔，总数除以它。别忘了三件事：自动发现（LLD）生成的项会随业务增加，规划时留 30–50% 余量；日志和文本类监控项不进 history_uint，容量要单独算；触发器不产生写入量但吃 CPU 和 ValueCache。算出 NVPS 之后，磁盘按"NVPS × 86400 × 100 字节 × 保留天数"估容量，IOPS 按 NVPS × 10 留余量。
能删，但别用 DELETE 一口气删。几百 G 的大表做 DELETE 会产生巨量 undo、长时间持锁、把 IO 吃光，而且删完表空间不释放，磁盘占用不会降。正确做法分三步走：一是先在前端把对应监控项的历史保留期调小（比如从 365 天改到 90 天），让 housekeeping 分批慢慢清；二是如果已经分区了，直接 DROP 过期分区，秒级完成；三是想回收空间，要么用 pt-online-schema-change 在线重建表，要么干脆新建一张分区表、把需要保留的数据导过去、再重命名。做之前务必先备份。
MySQL 原生分区的好处是组件少、DBA 熟悉、备份方案成熟，坏处是维护脚本得自己写（定期加新分区、删旧分区），而且 Zabbix 的分区管理在 MySQL 上不如 PostgreSQL 那边顺滑。TimescaleDB 的 hypertable 加自动 retention policy 几乎不用管，压缩（compression）能把历史数据压到原来的一小部分，长周期留存成本明显更低，代价是你得多维护一个 PostgreSQL 实例和一套对应的备份策略。我的倾向：数据量在 100 GB 以内、DBA 熟悉 MySQL，就用 MySQL 分区；历史要留一年以上、数据量几百 GB，直接上 TimescaleDB，省下来的磁盘钱比多一套组件的运维成本高。
能混着用，而且大多数环境都在混。判断标准很简单：同一个内网、机器数量不多、需要 Server 端随时调整采集节奏，用被动式；跨公网、跨机房、机器数量多、网络不稳定，用主动式。主动式对带宽和连接数的节省是数量级的——同样 1000 台 80 项，被动式每秒上千次短连接、2–3 Mbps，主动式每两分钟一批、不到 1 Mbps。实操上我一般这么配：核心内网机器用主动式（省资源），需要 Server 端立即探测的少数关键项单独保留被动式，异地机房统一走 Proxy。
要看 Proxy 承担多少采集量。小规模（几十台、NVPS 一两百）用 SQLite 完全没问题，SQLite 的写入在这种量级下很轻，而且不用额外维护一个数据库实例。但 SQLite 有两个硬伤：不支持并发写入（Proxy 多线程写会锁），以及数据量大之后查询和清理都慢。所以只要 Proxy 下面挂的东西超过一两百台，就该给它配 MySQL 或 PostgreSQL，最好和中心库同类型，方便统一备份和排查。另外 Proxy 本地库的意义是"断网时缓存数据"，所以它只需要存一小段时间的数据，盘不用大，几十 G 足够，但一定要稳。
没有外部要求的话，我的默认建议是历史明细 90 天、趋势数据 1 年。90 天足够覆盖绝大多数故障复盘和容量分析，1 年的小时级趋势足够看季节性的容量变化。再长就属于"存了但基本不看"，白白多买 NVMe。真有合规或客户要求需要留存更久，正确做法不是把 history 留三年，而是把趋势数据和关键指标单独归档导出（比如按月导出成压缩文件转冷存储），在线库保持精简。合规相关的具体要求（比如留存年限、审计要求），建议签约前与服务商沟通可提供的协助范围，一万网络这边可以就架构层面给建议，具体条款以合同为准。
强烈不建议。Server 和数据库之间是高频小查询，批量插入一次可能要往返好几个来回，内网的亚毫秒延迟换成跨机房的 20ms，插入吞吐会掉一个数量级，前端打开一个大区间图也会卡得没法用。正确的架构是：Server 和数据库放同一个机房的内网里，异地只部署 Proxy——Proxy 在本地机房采集，通过单个长连接批量回传中心，即使中间链路断一阵子，Proxy 本地缓存也能兜住，恢复后补传。一万网络在华南、华东、华北、华西、中国香港及海外都有节点，Proxy 就近放在被监控机器所在的机房就行。
第一句：自建 Zabbix 的成败从不在 Zabbix 本身，在你给它配的那块盘和那个数据库。把 NVPS 算清楚，把历史库放到独立的 NVMe 上，把保留期设成"明细 90 天 + 趋势 1 年"，这三件事做完，80% 的性能问题都不会发生。剩下的 20%，靠看 Server 日志和队列面板调缓存参数解决，别指望有什么银弹。
第二句：规模决定架构，别超前也别滞后。50 台以内一台 4 核 8G 的机器足够，300 台上裸金属 E5-2620 档（¥999 起，官网明示价，以官网实时价为准），1000 台以上老老实实把 Server 和数据库拆成两台、数据库上双路 E5-2698v4×2（¥3999 起，官网明示价，以官网实时价为准）配大内存和大 NVMe。异地一律上 Proxy，跨公网一律主动式。这套判断逻辑不会因为版本升级而过时。
第三句：长期跑的监控系统，选服务商要看"出事之后多久有人管"。一万网络深耕 IDC 19 年（成立于 2007 年），深圳南山总部，自营机柜最快 1 分钟上架、硬件故障 10 分钟自动迁移、7×24 中文工单平均 5 分钟响应、系统盘每日 3 份快照 30 秒回滚、5–20G DDoS 防护、免费网站备案协助、BGP 多线加 CN2 优化回国、华南华东华北华西中国香港及海外多节点可选——对一套 7×24 不能断的监控体系来说，这些比单机性能参数重要得多。至于年付折扣，行业通用做法是年付较月付省 1–2 个月（预估约 83–92 折，非官方报价，实际以咨询/下单时核算为准），长周期项目值得问一句。
本文涉及的产品形态、节点分布、服务项与价格，参考自一万网络官网公开页面（裸金属服务器、一万云弹性云、华南/华东/华北/华西及中国香港节点页、服务保障说明页），可访问 https://www.idc10000.net/ 查看对应栏目；文中所有容量、IOPS、带宽与 NVPS 数值均为基于通用口径的估算值，实际以自身环境实测为准，具体以签约时最新报价与合同为准。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
