CactiEZ 10.1 国产交换机监控模板：SNMP OID采集与图形配置

简介：CactiEZ 10.1 平台上面向华为、中兴、H3C 等网络设备的监控主机模板合集，适合用 Cacti 对机房、园区网设备做流量与性能监控的运维人员使用。压缩包共 16 个文件，以 15 个 xml 主机模板为主体，另附 1 个 txt 说明文件，整体约 314KB，导入后即可在 CactiEZ 10.1 中直接套用。模板覆盖范围较广：既有华为 S2300/S2700/S3700 盒式交换机（可采集 CPU、内存、光功率与接口流量）、S7703 与 S9000 高端交换机、S5700，也有中兴 ZXR2609、H3C AR2811 路由器与 S2000 系列交换机，还包含 APC 智能 UPS、惠普网络打印机墨量、海康威视硬盘录像机、三元达 WPB5000、Windows 主机及非 SNMP 主机等对象。借助这些现成模板，可省去逐项编写 OID 与数据查询方法的工作量，较快建立主机监控视图与图形。目前已有 2059 人学习下载。

1. 资源定位：CactiEZ 10.1 上的国产交换机主机监控模板解决哪几个重复动作

CactiEZ 10.1 上这套交换机主机监控模板，解决的是把三类国产主流交换机的 CPU、内存、温度、端口流量、光功率等指标接进 Cacti 的重复劳动。CactiE 相关资源里模板不少，但能同时覆盖主机模板、图形模板、数据查询和 SNMP OID 映射的成套包，仍然要花时间筛。它适合机房运维、网络监控二次开发，以及手里已经有一批国产交换机、又不想从零写 OID 的人。

这套资源的价值不在“装完就有图”，而在把设备侧 OID、Cacti 数据查询索引、图形模板绑定三件事提前对齐。导入后仍要按设备型号做一轮单机验证，否则容易出现模板套上了、图形却是空白的玄学问题。先把它当成一套可复用的采集骨架，再按现场设备改参数，落地会稳得多。

2. 模板拆包：四类对象、导入顺序与 CactiEZ 环境核对

拿到一个 Cacti 模板包，先别急着点导入。Cacti 的模板不是单个文件，而是主机模板、图形模板、数据模板、数据查询几类对象互相引用，导入顺序错了，常见结果就是“模板列表里能看到名字，但加设备时选不到”或者“图形模板有，数据源建不出来”。CactiEZ 10.1 的 Web 控制台把这几类对象分在不同的菜单里，模板包里的 XML 也会按 hash 做去重，所以导入前先把对象关系捋清楚，比导入后到处找报错省时间。

2.1 模板包里的四类对象怎么互相咬合

主机模板决定“一台设备默认挂哪些图形”，图形模板决定“一张图长什么样”，数据模板决定“数据源按什么类型存”，数据查询决定“从设备表里取哪些索引和字段”。四者的关系可以理解成一条链：数据查询先按 OID 找到端口或传感器索引，数据模板按索引建数据源，图形模板把数据源画成图，主机模板再把一组图形模板打包绑定到设备上。任何一环的名字或 hash 对不上，后面就会断链。

我一般会先在测试 Cacti 实例里只导入模板，不急着加设备。导入完成后打开“图形模板”列表，逐个点开看它引用的数据源名称；再打开“数据查询”看它定义的 OID 表根节点。这个动作花十分钟，能提前发现大部分命名不一致的问题。模板包里的甲厂、乙厂、丙厂三类设备，常见做法是分别建主机模板，不要用一个模板硬套所有型号，因为温度、电源、光模块的 OID 分支经常不一样。

2.2 导入前核对 CactiEZ 10.1 的版本、路径和权限

CactiEZ 10.1 的 Web 目录常见路径是/var/www/html/cacti，CLI 脚本在cli子目录，RRD 文件在rra目录。不同安装方式可能略有差异，先用find或ls确认，不要直接照抄路径。导入模板前至少做两件事：备份数据库和模板目录，确认 Web 用户对templates、rra、log目录有写权限。模板导入会写数据库，图形生成会写 RRD 文件，权限不对时日志里通常只给一句模糊报错，排查起来很费时间。

#!/bin/bash # 导入前备份 Cacti 数据库和模板目录，留一份后悔药 DATE=$(date +%F-%H%M) mysqldump -u root -p cacti > /root/cacti-db-${DATE}.sql tar -czf /root/cacti-templates-${DATE}.tar.gz /var/www/html/cacti/templates ls -lh /root/cacti-db-${DATE}.sql /root/cacti-templates-${DATE}.tar.gz

这段脚本里DATE用来给备份文件加时间戳，mysqldump导出cacti库，tar打包模板目录，最后ls -lh确认文件确实生成。-p会交互式提示输入数据库密码，不要把密码写进脚本历史。备份目录按现场规范改，示例放在/root只是图省事。导入前还要确认 PHP 和 RRDtool 能正常跑，CactiEZ 自带环境一般没问题，但如果你换过 PHP 版本，模板里的某些函数可能不兼容。

注意：模板导入不是幂等操作。同名模板重复导入可能生成新 hash，也可能跳过，取决于导入页面的勾选项。生产环境先备份，再在测试实例验证。

2.3 导入顺序与 hash 冲突处理

Cacti 的模板导入页面通常能一次选多个 XML 文件，但底层仍按对象类型处理。稳妥顺序是：先导入数据模板和数据查询，再导入图形模板，最后导入主机模板。原因是图形模板引用数据模板，主机模板引用图形模板，反过来导入时容易找不到依赖。导入页面如果有“替换已有模板”或“保留现有模板”选项，第一次导入选保留，确认没有冲突后再决定是否覆盖。

hash 冲突是常见坑。Cacti 用 hash 判断模板是否重复，模板作者改过名字但没改 hash，或者你之前导入过同源模板，都会触发冲突。处理方式不是硬删生产模板，而是先在测试实例里导入，打开数据库看host_template、graph_template表里的hash和name，确认重复的是哪一类。需要清理时只删测试实例里的记录，生产环境按“先导出、再改名、后导入”的顺序走。常见做法是把模板名加上现场前缀，比如“某机房-甲厂接入交换机”，避免和已有模板撞名。

-- 导入后核对模板是否真正落库，name 和 hash 一起看 SELECT id, name, hash FROM host_template WHERE name LIKE '%交换机%'; SELECT id, name, hash FROM graph_template WHERE name LIKE '%交换机%'; SELECT id, name FROM data_template WHERE name LIKE '%交换机%';

这几条 SQL 只读，用来确认模板落库情况。host_template和graph_template都有hash字段，名字相似但 hash 不同，说明是两份独立模板；名字相同 hash 也相同，说明重复导入被合并或跳过。data_template表主要看名字和采集类型。查完不要随手删记录，Cacti 里模板被设备引用后直接删表会留下孤立数据源，后面图形会报错。

3. SNMP 采集落地：先把 OID 跑通，再谈模板绑定

模板导入成功只代表 Cacti 认识这些对象，不代表设备能返回数据。交换机监控的成败在 SNMP 这一层：版本、团体名、ACL、OID 分支、索引类型，任何一项不对，图形就是空白。我的习惯是先用命令行把单台设备的 OID 跑通，再把同样的参数填进 Cacti。命令行能看到原始返回，比在 Web 页面里猜“为什么没图”直接得多。甲厂、乙厂、丙厂的私有 MIB 分支不同，模板里的 OID 只是起点，现场要按设备型号做替换和验证。

3.1 SNMP 版本、只读团体名与设备侧 ACL

Cacti 采集交换机一般用 SNMP v2c，够用且配置简单。团体名用只读权限，不要图省事给读写。设备侧如果有 ACL，要把 Cacti 服务器的管理地址加进允许列表，否则snmpwalk会超时，Cacti 日志里只会写“SNMP error”。团体名里如果包含特殊字符，命令行用单引号包住，Cacti 的 Web 表单里也要保持一致，前后空格都算不同字符串。常见翻车点是复制粘贴时多了一个空格，排查半天以为是 OID 问题。

设备侧 ACL 没放行时，现象是命令行snmpwalk超时，但ping通。这时不要先怀疑 Cacti，先在本机用snmpget取sysDescr。能取到系统组，说明 SNMP 通；取不到，查团体名、ACL、SNMP 服务是否开启。Cacti 服务器如果有多个网卡，确认出站源地址是设备 ACL 里放行的那个，多网卡环境经常在这里踩坑。

3.2 用 snmpwalk 做单机 OID 验尸

先取系统组，再取私有 MIB 根。系统组 OID 是1.3.6.1.2.1.1，能返回设备描述、运行时间、联系人等信息，用来确认 SNMP 基本可达。私有 MIB 根用模板里写的企业分支，示例里用1.3.6.1.4.1.99999占位，实际替换成模板中对应厂商的分支。不要直接 walk 整个1.3.6.1.4.1，设备上可能挂了很多子代理，输出太大还慢。

# 先取系统组，确认 SNMP 可达 snmpwalk -v 2c -c 'RO_COMMUNITY' -t 3 -r 1 192.0.2.10 1.3.6.1.2.1.1 # 再取模板里的私有 MIB 根，确认 CPU、内存、温度分支有返回 snmpwalk -v 2c -c 'RO_COMMUNITY' -t 3 -r 1 192.0.2.10 1.3.6.1.4.1.99999

-v 2c指定版本，-c后面是只读团体名，-t 3是超时 3 秒，-r 1是重试 1 次。第一条返回sysDescr、sysUpTime等，第二条返回私有分支。如果第二条为空但第一条正常，说明模板里的 OID 分支和当前设备型号不匹配，需要查设备 MIB 文档或换模板里的对应分支。不要拿一个型号的 OID 硬套整个系列，端口数量和传感器编号经常变。

批量验证时我一般用一个小脚本先扫一遍，不直接往 Cacti 里加设备。下面这段 Python 只取sysDescr和sysUpTime，用来判断设备是否可达，输出成功或失败，方便先筛掉网络不通、团体名错误的地址。脚本里的团体名和地址都是示例，实际用时从环境变量或权限 600 的配置文件读取，不要硬编码到仓库里。

import subprocess devices = [ ("SW-ACC-01", "192.0.2.10"), ("SW-ACC-02", "192.0.2.11"), ] for name, ip in devices: # 只取 sysDescr 和 sysUpTime，判断 SNMP 是否可达 cmd = [ "snmpget", "-v", "2c", "-c", "RO_COMMUNITY", "-t", "2", "-r", "1", ip, "1.3.6.1.2.1.1.1.0", "1.3.6.1.2.1.1.3.0", ] result = subprocess.run(cmd, capture_output=True, text=True) if result.returncode == 0: lines = result.stdout.splitlines() print(f"{name} OK: {lines[0] if lines else 'no output'}") else: print(f"{name} FAIL: {result.stderr.strip()}")

subprocess.run调系统里的snmpget，capture_output=True收标准输出和错误，text=True让输出按字符串处理。returncode为 0 表示命令成功，非 0 时打印错误。这个脚本只做可达性筛查，不判断具体 OID 是否正确，所以跑通后还要回到snmpwalk看模板里的业务 OID。批量设备多时，加一个超时和并发上限，不要一次开几百个进程把管理口打满。

3.3 把 OID 映射到数据查询和图形模板

模板里的数据查询通常按表 OID 取索引，比如端口表用ifDescr或ifName做索引，传感器表用传感器编号做索引。CPU、内存这类标量指标一般用snmpget单点取，端口流量用snmpwalk取表。数据模板里的数据类型要匹配：端口字节计数是 COUNTER，温度是 GAUGE，CPU 百分比是 GAUGE。类型填错时图形会变成一条直线或者出现负值，看起来像“设备坏了”，其实是模板参数问题。

表里的 OID 是占位示例，私有分支要按模板里的实际值替换。端口流量优先用 64 位计数器ifHCInOctets、ifHCOutOctets，千兆以上链路用 32 位计数器会很快回绕，图形出现周期性尖峰。数据查询里如果同时抓到物理口和 VLAN 接口，图形会多出一堆无用图例，常见做法是按ifType过滤，只保留以太网口，或者在索引过滤里排除Vlan、Loop之类描述。这一步不做，后面主机模板一绑就是几百张图，轮询压力立马上来。

4. 模板配置：主机模板、图形模板与数据查询的接线方式

模板导入后，真正决定“图好不好看、轮询扛不扛得住”的是绑定方式。主机模板不是绑得越多越好，图形模板也不是每个指标都要单独一张图。Cacti 的轮询是按数据源走的，一台交换机绑几十张图，几百台设备就是几万个数据源，轮询器压力会很明显。我的做法是先定一个最小可用集：CPU、内存、温度、电源、上联端口流量、端口状态，先跑一周看数据完整性，再按需要加光功率、丢包、广播风暴。甲厂、乙厂、丙厂的模板分开绑定，避免 OID 不匹配。

4.1 主机模板绑定哪些图形才不臃肿

主机模板里常见会挂这些图形模板：设备 CPU、内存、温度、电源状态、风扇状态、端口流量、端口状态、光模块收发光。端口流量和端口状态通常是“按端口自动生成”，不是固定几张图，所以主机模板绑定的是图形模板规则，具体生成多少张取决于数据查询返回的索引数量。接入层交换机端口多，绑定前先做索引过滤，把未使用的端口和逻辑接口排掉，否则一台 48 口交换机可能生成上百张图，其中一半是空的。

绑定主机模板时，先在测试设备上应用，看“图形”列表里生成了多少张图，再决定是否批量。常见误用是把所有图形模板全勾上，结果一台设备几百张图，真正有人看的没几张。我一般会让主机模板保持精简，特殊指标用单独的图形模板按设备手动加，或者在主机模板里用“图形模板分组”控制。Cacti 的图形树也要规划，按机房、角色、厂商分树，后面找图会快很多。

4.2 数据查询的索引、过滤和调试模式

数据查询的核心是索引。端口表用ifIndex做索引，但显示名要用ifDescr或ifName；传感器表用传感器编号做索引，显示名用传感器描述。索引字段选错时，图形标题会变成一串数字，或者同一个端口生成多张图。数据查询的 XML 里通常有“索引类型”和“过滤规则”，自动索引适合端口会变动的设备，手动索引适合固定传感器。导入模板后先打开数据查询的调试模式，Cacti 会列出它从设备取到的索引和值，确认索引数量与设备实际端口数对得上。

-- 查数据查询和图形模板的关联，确认模板不是“空壳” SELECT dq.id, dq.name, dq.xml_path FROM data_query dq WHERE dq.name LIKE '%交换机%'; SELECT gt.id, gt.name, gt.hash FROM graph_template gt WHERE gt.name LIKE '%端口流量%';

data_query表里xml_path指向数据查询 XML 文件，导入后确认文件确实在模板目录下。graph_template表看图形模板是否落库。查完回到 Web 页面，打开“数据查询”里的调试模式，选一台测试设备运行，观察返回的索引列表。如果索引列表为空，先查 SNMP 是否可达；如果索引太多，回到过滤规则里加条件。过滤规则不要写得太死，设备扩容后新增端口会被漏掉，常见做法是按接口类型过滤，不按端口号硬编码。

4.3 用 CLI 批量加设备并套模板

设备少时 Web 页面一台台加可以，设备多时用 Cacti 自带的 CLI 脚本更稳。Cacti 1.x 的add_device.php在cli目录下，参数包括设备名、IP、主机模板、团体名、SNMP 版本等。路径按实际安装改，示例用/var/www/html/cacti/cli。先跑--help看当前版本支持的参数，不要直接照抄旧版本文档。批量添加前先用一台设备验证模板名完全一致，主机模板名多一个空格都会找不到。

cd /var/www/html/cacti/cli php add_device.php \ --description="SW-ACC-01" \ --ip="192.0.2.10" \ --template="国产交换机主机模板-甲厂" \ --community="RO_COMMUNITY" \ --snmp_version=2 \ --snmp_port=161 \ --notes="接入层，模板导入后先单机验证"

--description是 Cacti 里显示的设备名，--ip是管理地址，--template必须和主机模板列表里的名字完全一致，--community是只读团体名，--snmp_version=2对应 v2c，--snmp_port默认 161，--notes写现场备注。批量时把设备清单做成 CSV，用 shell 循环读，每加一台就检查返回码。不要一次性加几百台然后立刻开轮询，先加十台，等一轮轮询周期结束，看图形和数据源都正常，再扩量。Cacti 的轮询周期常见是 5 分钟，扩量前把poller.php的并发和 PHP 内存限制一起看，别只加设备不调轮询。

5. 避坑与排查：导入报错、图形空白、OID 错位和设备掉线

模板类资源最容易出现“导入成功但用不了”的落差。Cacti 的日志分散在 Web 日志、轮询器日志、数据库和 RRD 文件里，排查时不能只盯一个页面。下面几条是血泪经验里出现频率最高的，按“现象、原因、解决”拆开写。每条都先在测试设备上复现，确认不是网络问题再改模板。生产环境改模板前先备份，改完只对单台设备重新应用，不要批量重建数据源。

5.1 导入阶段的三个硬坑

现象：导入页面提示模板 hash 已存在，或者导入后模板列表里出现两个同名模板。原因：之前导入过同源模板，或者模板作者改过名字没改 hash，Cacti 按 hash 判断重复。解决：先在测试实例查host_template、graph_template的hash，确认重复对象；生产环境不要直接删模板，先导出当前模板，再把新模板改名加前缀后导入。如果只是测试，可以清空测试库重来，生产环境按“停用旧模板、绑定新模板、观察一轮、再清理”的顺序走。

现象：导入成功，但给设备套主机模板时下拉框里找不到。原因：主机模板导入失败但页面没明显报错，或者模板类型不匹配，比如把图形模板当主机模板导入。解决：打开“模板导入”页面看历史记录，再到host_template表确认记录存在；检查 XML 根节点类型，主机模板和图形模板的 XML 结构不同。常见做法是先把模板包解压，看每个 XML 的name和type，按类型分批导入，不要一次全选。

现象：导入后图形模板点开报“数据源不存在”。原因：图形模板引用的数据模板没有先导入，或者数据模板名字被改过。解决：按数据模板、数据查询、图形模板、主机模板的顺序重新导入；如果名字被改过，在图形模板里重新选择数据源。Cacti 的模板引用靠名字和 hash，改名后不会自动修复引用关系，所以改模板名要同步改引用。

5.2 采集与绘图阶段的四个软坑

现象：设备加上了，图形也生成了，但图是空白或者只有一条零线。原因：SNMP 不可达、团体名错、OID 分支不匹配，或者数据查询索引没取到。解决：先在命令行snmpwalk模板里的 OID，确认有返回；再看cacti.log和poller.log有没有 SNMP error；最后打开数据查询调试模式看索引列表。如果命令行有返回、Cacti 没数据，检查 Cacti 设备的 SNMP 版本、端口、团体名是否和命令行一致。

现象：端口流量图有图，但数值明显偏小或者周期性归零。原因：千兆以上链路用了 32 位计数器，或者数据模板类型填成了 GAUGE。解决：改用ifHCInOctets、ifHCOutOctets64 位计数器，数据源类型设为 COUNTER；已经建好的数据源需要重建，改模板不会自动改历史数据源。重建前备份 RRD，避免历史数据丢失。

现象：端口图例错位，A 端口的流量画到了 B 端口上。原因：设备重启或板卡插拔后ifIndex变化，数据查询还按旧索引取数。解决：检查数据查询的索引类型，端口变动频繁的环境用ifName或ifDescr做稳定索引，必要时重新跑一次数据查询；Cacti 里有“重新索引”功能，重建前先确认设备侧端口描述没有重复。

现象：温度、电源图偶尔断点，其他图正常。原因：传感器 OID 是表结构，某些型号只返回部分索引，或者设备忙时 SNMP 超时。解决：单独对传感器分支做snmpwalk，确认索引数量；把该数据查询的超时和重试调大一点；如果设备本身返回不稳定，减少一次性 walk 的范围，拆成多个数据查询。不要把所有传感器塞进一个查询里，一个超时会影响整组数据。

5.3 轮询性能与权限的收尾检查

设备量上来后，轮询变慢、CPU 升高是常见问题。先看poller.log里一轮轮询耗时，再看 Cacti 的轮询器并发设置。数据源太多时，减少无用图形比换服务器更有效。端口状态图如果没人看，可以从主机模板里去掉；光模块图只给有光口上联的设备绑。Cacti 的轮询是按数据源逐个执行，模板绑得越臃肿，压力越大。我的习惯是每加一批设备就跑一次手动轮询，观察耗时和错误数，再决定下一批加多少。

# 排查时先看日志、RRD 文件和手动轮询结果 tail -n 100 /var/www/html/cacti/log/cacti.log tail -n 100 /var/www/html/cacti/log/poller.log find /var/www/html/cacti/rra -name '*sw-acc-01*' -ls php /var/www/html/cacti/poller.php --force

cacti.log记录 Web 侧和采集侧的错误，poller.log记录轮询过程，find确认 RRD 文件是否生成，poller.php --force手动跑一轮看实时输出。路径按实际安装改，CactiEZ 10.1 常见路径是/var/www/html/cacti。如果 RRD 文件不存在，查权限和轮询器用户；如果文件存在但图形不更新，查 RRDtool 版本和时区。权限问题常见于手动用 root 跑过轮询，导致 RRD 文件属主变成 root，Web 用户写不进去。

注意：不要用 root 长期跑 Cacti 轮询。RRD 文件属主错乱后，图形会停止更新，日志里可能只报“Permission denied”。改回正确属主后，等一轮轮询再观察。

6. 批量验证：从单台交换机到一组设备的检查清单

单台验证通过后，批量铺开前我一般会做一张验收表，不靠记忆。先确认 SNMP 可达、模板绑定、数据源生成、RRD 文件、图形刷新这五项，再扩到十台，最后按机房分批。每批加完等一个轮询周期，看poller.log里的错误数和耗时。下面这段命令用来做单机验收，取sysUpTime确认设备活着，再看 RRD 目录里有没有对应文件。192.0.2.10和团体名按现场替换。

# 单机验收：SNMP 可达 + RRD 文件存在 + 轮询无报错 snmpget -v 2c -c 'RO_COMMUNITY' -t 2 -r 1 192.0.2.10 1.3.6.1.2.1.1.3.0 find /var/www/html/cacti/rra -name '*sw-acc-01*' -ls tail -n 50 /var/www/html/cacti/log/poller.log

snmpget取sysUpTime，有返回说明设备侧采集通；find看 RRD 文件是否按设备名生成；poller.log看最近一轮有没有 SNMP timeout 或数据源错误。三项都正常，再把设备加进监控大屏或告警平台。批量时用 CSV 维护设备名、IP、模板名、机房、备注，CLI 循环读取，每加一台写一条日志。加完十台先别急着扩，等一轮轮询结束，抽查三台的 CPU、内存、上联端口流量图，确认图和设备对得上。

从那以后我每次导入模板前都强制走一遍备份、单机snmpwalk、批量加设备三步，少一步后面就要花更多时间补。这份 CactiEZ 10.1 交换机主机监控模板适合先在小范围验证，再按机房铺开；把 OID 和索引对齐，图形稳定之后，后面加设备就是重复动作。希望帮到你。

本文还有配套的精品资源，点击获取