Ubuntu 18.04 SNMP部署四层配置解析与Zabbix纳管实战

1. 为什么在Ubuntu 18.04上亲手部署SNMP不是“多此一举”，而是运维基本功的试金石

很多人看到“安装snmpd”四个字，第一反应是：不就是apt install snmpd一行命令的事？真要这么简单，就不会有那么多人在Zabbix接入锐捷网关时卡在“无法获取sysDescr”、不会在用Paessler SNMP Tester扫不到端口时反复重启服务、更不会在MRTG图表里看到一整片空白的“no data”。我带过三届运维新人，几乎所有人都在第一次配置SNMP v3时栽过跟头——不是因为协议本身复杂，而是Ubuntu 18.04这个特定版本的snmpd默认配置像一层裹着糖衣的硬壳：表面平滑，内里全是陷阱。它默认监听的是127.0.0.1，连本机curl都通不过；它的community字符串写死在/etc/snmp/snmpd.conf里却从不提示你改；它把v3用户信息存在/var/lib/snmp/snmpd.conf这个连ls -l都看不到的隐藏路径下，而新手习惯性地只改/etc/snmp/snmpd.conf。这根本不是软件缺陷，而是设计哲学——snmpd从诞生起就假设操作者清楚自己在做什么，它拒绝“向导式”交互，只提供原始杠杆。所以当你在Zabbix里填完IP和端口却收不到trap，当snmpwalk -v2c -c public localhost返回timeout，问题从来不在Zabbix或Paessler，而在你是否真正理解了snmpd进程启动那一刻，系统到底加载了哪些配置、绑定了哪些地址、读取了哪几行权限定义。这篇文章不教你“点哪里”，而是带你拆开snmpd这个黑盒子，看透Ubuntu 18.04特有的启动链路：从/lib/systemd/system/snmpd.service的ExecStart参数，到/etc/default/snmpd里的OPTIONS变量，再到/etc/snmp/snmpd.conf里那行被注释掉的agentAddress udp:161,udp6:[::1]:161——它们不是并列选项，而是层层覆盖的优先级链条。你改错一个地方，其他地方就会默默覆盖它，而日志里只有一句冰冷的“snmpd[1234]: Error opening specified endpoint 'udp:161'”。这种“静默失败”才是最消耗时间的。所以别急着敲install，先搞懂这个daemon在Ubuntu 18.04里究竟是怎么活下来的。

2. 从零构建SNMP守护进程：Ubuntu 18.04的四层配置防火墙与突破路径

Ubuntu 18.04的snmpd不是单点配置，而是一套四层嵌套的防御体系。跳过任何一层，你的服务都会在某个环节无声熄灭。我把它比作一栋老式公寓楼：最外层是门禁（systemd服务单元），第二层是楼道电闸（/etc/default/snmpd的启动参数），第三层是每户的入户门锁（/etc/snmp/snmpd.conf的agentAddress和access控制），最里层是房间内的保险柜（/var/lib/snmp/snmpd.conf的v3用户密钥）。现在，我们一层层拆解。

2.1 第一层：Systemd服务单元的隐性开关

很多人以为systemctl start snmpd就万事大吉，但/lib/systemd/system/snmpd.service文件里藏着关键伏笔。打开它，你会看到这一行：

ExecStart=/usr/sbin/snmpd $SNMPDOPTS -f -u Debian-snmp -g Debian-snmp -I -smux,mteTrigger,mteTriggerConf -p /var/run/snmpd.pid

注意$SNMPDOPTS这个变量——它根本不是环境变量，而是由/etc/default/snmpd文件定义的。如果你没碰过这个文件，$SNMPDOPTS默认为空，意味着snmpd会以最保守模式启动：只监听127.0.0.1:161。这就是为什么你在本机snmpwalk -c public 127.0.0.1 system能通，但换成本机真实IP（比如192.168.1.100）就超时。解决方法不是改service文件（那是系统包管理器维护的），而是编辑/etc/default/snmpd，找到#SNMPDOPTS="-Lsd -Lf /dev/null -u snmp -g snmp -I -smux,mteTrigger,mteTriggerConf -p /var/run/snmpd.pid"这一行，去掉开头的#，并在末尾追加-a -x tcp:localhost:705（启用agentX支持，为后续扩展留余地），最终变成：

SNMPDOPTS="-Lsd -Lf /dev/null -u snmp -g snmp -I -smux,mteTrigger,mteTriggerConf -p /var/run/snmpd.pid -a -x tcp:localhost:705"

这里-a参数至关重要：它强制snmpd在启动时重新读取/etc/snmp/snmpd.conf中的agentAddress指令。没有它，你后面改再多配置，snmpd也只会固执地守着127.0.0.1。

2.2 第二层：/etc/default/snmpd的OPTIONS变量陷阱

/etc/default/snmpd这个文件常被忽略，但它实际是snmpd启动的总开关。除了上面提到的SNMPDOPTS，还有两个致命变量：MIBS和TRAPDRUN。MIBS=ALL看似无害，实则在Ubuntu 18.04上会导致snmpd加载所有MIB树，内存占用飙升至200MB以上，且启动时间超过45秒——很多新手以为服务挂了，其实是卡在MIB加载。正确做法是显式指定所需MIB：MIBS=+UCD-SNMP-MIB:HOST-RESOURCES-MIB。至于TRAPDRUN=yes，它控制snmptrapd子进程，但Ubuntu 18.04的snmpd包默认不安装snmptrapd，设为yes反而会让systemd报错“Failed to start SNMP trap daemon”。所以必须设为TRAPDRUN=no，后续需要trap功能时再单独安装snmptrapd包。

2.3 第三层：/etc/snmp/snmpd.conf的地址绑定生死线

这是最常被误改的文件。默认配置里有这样一行：

#agentAddress udp:127.0.0.1:161,udp6:[::1]:161

新手看到注释就以为“不用改”，直接去改下面的rocommunity。错！这行注释掉的代码恰恰是Ubuntu 18.04的默认行为。你必须取消注释，并明确指定监听地址。如果要监听所有IPv4接口，改成：

agentAddress udp:161,udp6:[::1]:161

注意：这里udp:161等价于udp:0.0.0.0:161，但绝不能写成udp:0.0.0.0:161——snmpd会解析失败并退出。这是Net-SNMP库的一个历史遗留bug，在Ubuntu 18.04的5.7.3版本中依然存在。验证方法很简单：改完后执行sudo systemctl restart snmpd && sudo ss -tuln | grep :161，你应该看到udp UNCONN 0 0 *:161 *:*，而不是udp UNCONN 0 0 127.0.0.1:161 *:*。

2.4 第四层：/var/lib/snmp/snmpd.conf的v3用户密钥黑洞

当你执行sudo net-snmp-create-v3-user -ro -A mypass123 -X mypass123 -a SHA -x AES myuser创建v3用户时，生成的密钥并不存放在/etc/snmp/snmpd.conf，而是写入/var/lib/snmp/snmpd.conf。这个文件默认权限是600，且/var/lib/snmp目录属主是Debian-snmp用户。如果你用root手动编辑过这个文件，或者用cp命令覆盖过它，snmpd启动时会因权限校验失败而静默退出。最稳妥的方法永远是使用net-snmp-create-v3-user工具，它会自动处理权限。创建后，检查该文件内容应包含类似：

createUser myuser SHA "mypass123" AES "mypass123" rwuser myuser priv

注意最后一行rwuser myuser priv——它表示该用户拥有读写权限且强制加密。如果漏掉priv，v3查询会返回usmStatsNotInTimeWindows.0 = Counter32: 1错误，这是SNMPv3时间戳校验失败的典型表现，根源就是没启用隐私协议。

提示：每次修改配置后，不要直接systemctl restart snmpd。先执行sudo snmpd -f -Lo -C -c /etc/snmp/snmpd.conf前台运行，观察输出。如果看到Error opening specified endpoint，说明agentAddress配置错误；如果看到Cannot find module (SNMPv2-MIB)，说明MIB路径未正确加载。前台模式能让你在30秒内定位90%的问题，比反复重启服务高效十倍。

3. SNMP v2c与v3的实战分水岭：从“能通”到“可信”的三道坎

很多教程止步于snmpwalk -v2c -c public localhost system返回一堆OID值，就宣告成功。但这只是“能通”，离“可信”还隔着三道技术坎：权限粒度、传输加密、身份认证。Ubuntu 18.04的snmpd默认配置在这三方面都极度宽松，必须手动收紧，否则你的Zabbix监控服务器就成了攻击者的免费资产探测器。

3.1 权限粒度：从“全库可读”到“按需授权”

默认的rocommunity public default -V systemonly配置，表面上限制了只读，但-V systemonly这个视图（view）定义在/etc/snmp/snmpd.conf里是这样的：

view systemonly included .1.3.6.1.2.1.1 view systemonly included .1.3.6.1.2.1.25.1

它只包含了系统基本信息（sysDescr、sysUpTime）和主机资源（hrSystemUptime），但Zabbix需要的网络接口流量（ifInOctets）、CPU负载（hrProcessorLoad）都不在此列。如果你强行用snmpwalk -v2c -c public localhost if，会得到Timeout: No Response from localhost。解决方案是扩展视图范围。在/etc/snmp/snmpd.conf中添加：

view zabbixview included .1.3.6.1.2.1.2.2.1.10 # ifInOctets view zabbixview included .1.3.6.1.2.1.2.2.1.16 # ifOutOctets view zabbixview included .1.3.6.1.2.1.25.3.3.1.2 # hrProcessorLoad view zabbixview included .1.3.6.1.2.1.25.2.2.0 # hrMemorySize

然后将community映射到新视图：

rocommunity zabbixpwd default -V zabbixview

这样，Zabbix用zabbixpwd作为community字符串时，只能访问指定的4个OID节点，其他全部拒绝。这比public社区安全百倍——即使密码泄露，攻击者也无法获取路由表或ARP缓存。

3.2 传输加密：v3的AES-128为何比v2c的明文强百倍

SNMP v2c的community字符串本质就是密码，走UDP明文传输。抓包工具Wireshark一眼就能看到public或private。而v3通过USM（User-based Security Model）实现真正的加密。在Ubuntu 18.04上，net-snmp-create-v3-user默认使用SHA-1做认证，AES-128做加密。但这里有个关键细节：AES密钥不是直接存储的，而是通过PBKDF2算法从密码派生。这意味着即使你拿到/var/lib/snmp/snmpd.conf文件，也无法反推原始密码。验证加密效果：用snmpget -v3 -u myuser -l authPriv -a SHA -A "mypass123" -x AES -X "mypass123" localhost sysDescr.0，Wireshark抓包会显示encryptedPDU，内容是乱码。而同样的命令换成-l authNoPriv（仅认证不加密），抓包能看到明文OID请求。这才是企业级监控该有的数据保护级别。

3.3 身份认证：时间戳同步为何是v3成功的隐形门槛

SNMP v3要求客户端和服务器时间差不超过150秒，否则返回usmStatsNotInTimeWindows错误。Ubuntu 18.04默认不启用NTP服务，很多虚拟机的时间漂移严重。我见过最离谱的案例：一台VM的系统时间比NTP服务器快8分钟，导致所有v3查询失败。解决方法不是手动date -s（重启后失效），而是启用systemd-timesyncd：

sudo timedatectl set-ntp true sudo systemctl restart systemd-timesyncd

然后检查同步状态：timedatectl status | grep "System clock synchronized"，输出yes才算达标。Zabbix服务器同样需要同步时间，否则trap接收会失败。这个细节90%的教程都忽略，但它直接决定v3能否落地。

注意：v3用户创建后，/var/lib/snmp/snmpd.conf文件权限必须是600，属主Debian-snmp。如果权限错误，snmpd启动时会报Error: Cannot open /var/lib/snmp/snmpd.conf for reading并退出。修复命令：sudo chown Debian-snmp:Debian-snmp /var/lib/snmp/snmpd.conf && sudo chmod 600 /var/lib/snmp/snmpd.conf。

4. Zabbix与锐捷网关的SNMP对接：从“找不到设备”到“精准纳管”的七步排查链

把锐捷网关加入Zabbix是高频需求，但搜索结果里充斥着“检查SNMP是否开启”这类废话。真实场景中，90%的失败源于三个具体动作：锐捷设备的SNMP配置未生效、Zabbix模板OID路径不匹配、Ubuntu防火墙拦截UDP 161端口。下面是我总结的七步黄金排查链，每一步都有可验证的命令和预期输出。

4.1 第一步：确认锐捷网关SNMP服务真实运行

锐捷Web界面的“SNMP开启”按钮只是开关，不等于服务已启动。必须登录设备CLI执行：

Ruijie#show snmp SNMP agent is running. SNMP community: public (RO), private (RW) SNMP version: v2c SNMP trap: disabled

重点看第一行SNMP agent is running.。如果显示disabled，需执行snmp-server enable。另外，锐捷默认只允许特定IP访问SNMP，必须配置ACL：

Ruijie(config)#snmp-server host 192.168.1.100 public Ruijie(config)#snmp-server community public ro

这里192.168.1.100是Zabbix服务器IP，必须精确匹配，否则锐捷会丢弃所有来自该IP的SNMP请求。

4.2 第二步：在Zabbix服务器上验证基础连通性

不要直接进Zabbix界面点“Test”，先用底层命令验证：

# 测试UDP端口是否可达（注意：telnet对UDP无效） nc -zuv 192.168.1.1 161 # 测试SNMP v2c响应（锐捷默认用public） snmpwalk -v2c -c public 192.168.1.1 system # 如果超时，检查Ubuntu防火墙 sudo ufw status verbose | grep 161 # 应输出：161/udp ALLOW IN Anywhere

如果nc显示open但snmpwalk超时，说明锐捷ACL未放行；如果nc显示failed，说明锐捷SNMP服务未启动或网络不通。

4.3 第三步：比对Zabbix模板与锐捷MIB的OID差异

Zabbix官方模板基于标准IF-MIB，但锐捷对某些OID做了私有扩展。例如标准ifInOctetsOID是.1.3.6.1.2.1.2.2.1.10，锐捷可能映射到.1.3.6.1.4.1.4881.1.1.1.1.1.1.10。解决方案是用snmptranslate查锐捷私有MIB：

# 下载锐捷MIB文件（通常在官网支持页面） wget http://support.ruijienetworks.com/mibs/RUIJIE-MIB.mib sudo cp RUIJIE-MIB.mib /usr/share/snmp/mibs/ # 刷新MIB树 sudo snmptranslate -Tp | grep -i ruijie # 查找接口流量OID snmptranslate -On RUIJIE-MIB::ruijieIfInOctets

输出类似.1.3.6.1.4.1.4881.1.1.1.1.1.1.10，这就是你要填入Zabbix item的OID。

4.4 第四步：Zabbix代理配置的隐藏坑

Zabbix Server和Zabbix Proxy都能采集SNMP，但Proxy需要额外配置。如果Zabbix Server和锐捷不在同一网段，必须用Proxy中转。此时/etc/zabbix/zabbix_proxy.conf中必须设置：

SNMPTrapperFile=/tmp/zabbix_traps.tmp StartSNMPTrapper=1

否则Proxy无法接收锐捷发来的trap。验证命令：sudo ss -tuln | grep :162，应看到udp UNCONN 0 0 *:162 *:*。

4.5 第五步：锐捷Trap配置的双地址陷阱

锐捷发送trap需要同时配置Server IP和Source IP。如果只配Server IP，trap会从设备管理口IP发出，而Zabbix可能监听在业务口。必须在CLI中指定源地址：

Ruijie(config)#snmp-server host 192.168.1.100 public source-interface Vlan1

Vlan1是锐捷管理VLAN接口名，需根据实际调整。否则Zabbix收到的trap源IP是127.0.0.1，被直接丢弃。

4.6 第六步：Zabbix前端的OID调试技巧

Zabbix界面不显示原始SNMP错误。要调试，必须查看Zabbix Server日志：

sudo tail -f /var/log/zabbix/zabbix_server.log | grep "SNMP"

当添加item时，如果看到SNMP error on [192.168.1.1]: no response，说明网络层失败；如果看到SNMP error on [192.168.1.1]: timeout，说明UDP包到达但锐捷未响应；如果看到SNMP error on [192.168.1.1]: noSuchName，说明OID不存在，需回第四步查MIB。

4.7 第七步：最终验证——用Zabbix自带工具

Zabbix安装后自带zabbix_get工具，它模拟Zabbix Server行为：

zabbix_get -s 192.168.1.1 -k "snmp.get[public,.1.3.6.1.2.1.1.1.0]"

-k参数是Zabbix key格式，snmp.get[community,oid]。如果返回Linux RuijieOS 3.0.0...，说明Zabbix Agent能正确解析SNMP响应，前端配置只需同步此key即可。

实操心得：锐捷设备的SNMP v3支持较弱，建议生产环境统一用v2c。如果必须用v3，务必在锐捷CLI中执行snmp-server user myuser groupname v3 auth sha auth-password priv aes priv-password，且groupname必须是已存在的组（如network-admin），否则配置不生效。

5. MRTG与Paessler SNMP Tester的协同诊断：让数据可视化成为排错利器

当命令行snmpwalk返回海量文本，人眼很难发现异常。这时MRTG（Multi Router Traffic Grapher）和Paessler SNMP Tester就成为透视SNMP健康状况的X光机。它们不替代命令行，而是将抽象OID转化为直观趋势图，让“数据是否在流动”一目了然。

5.1 MRTG的极简部署：三步生成流量热力图

MRTG在Ubuntu 18.04上安装极其简单，但配置容易踩坑。先安装：

sudo apt install mrtg sudo mkdir -p /var/www/html/mrtg

关键在配置生成。不要手写mrtg.cfg，用cfgmaker自动生成：

cfgmaker --global 'WorkDir: /var/www/html/mrtg' \ --global 'Options[_]: growright,bits' \ --output /etc/mrtg.cfg \ public@192.168.1.1

这里public@192.168.1.1是锐捷设备地址。cfgmaker会自动探测所有可用接口，并生成对应配置段。但默认配置有个致命问题：它用Target[192.168.1.1_1]作为索引，而锐捷接口索引（ifIndex）可能变化。解决方案是强制指定接口名：

cfgmaker --global 'WorkDir: /var/www/html/mrtg' \ --global 'Options[_]: growright,bits' \ --ifref=name \ --output /etc/mrtg.cfg \ public@192.168.1.1

--ifref=name参数让MRTG用接口名称（如GigabitEthernet0/1）而非数字索引，避免因接口增删导致图表错乱。

5.2 Paessler SNMP Tester的深度探针用法

Paessler SNMP Tester是Windows工具，但它对Ubuntu服务器的诊断价值极高。它不像snmpwalk那样只返回当前值，而是能持续轮询并绘制曲线。关键技巧在于“OID Browser”功能：输入锐捷私有OID（如.1.3.6.1.4.1.4881.1.1.1.1.1.1.10），点击“Browse”，它会自动展开该OID下的所有子节点，并显示每个节点的值类型（Counter32、Gauge32等）。这对Zabbix item类型选择至关重要——如果OID返回值是递增计数器（Counter32），Zabbix必须选Delta (speed per second)计算方式，否则图表会是垂直直线。

5.3 用MRTG日志反向定位SNMP瓶颈

MRTG每5分钟执行一次snmpget，并将结果写入/var/www/html/mrtg/*.log。当图表突然变平（no data），不是Zabbix故障，而是SNMP层面中断。查看日志：

tail -n 20 /var/www/html/mrtg/192.168.1.1_1.log

正常日志形如：1612345678 123456789 987654321（时间戳、入流量、出流量）。如果出现1612345678 NaN NaN，说明该次SNMP查询完全失败。此时立即在Ubuntu服务器执行：

sudo tcpdump -i any udp port 161 -w snmp_debug.pcap

抓包5秒后停止，用Wireshark打开snmp_debug.pcap，过滤snmp && ip.addr==192.168.1.1。如果看到Zabbix服务器发出GetRequest但无GetResponse，问题在锐捷；如果看到锐捷发出GetResponse但Zabbix未收到，问题在Ubuntu防火墙或网络设备ACL。

5.4 故障模式识别：从MRTG曲线读懂SNMP健康度

我整理了四种典型MRTG曲线及其根因：

其中最后一种情况最隐蔽。锐捷老版本固件的32位计数器（ifInOctets）在流量达4GB时会归零，MRTG误判为“瞬时巨量”，图表出现尖刺。解决方案是改用64位计数器ifHCInOctets（OID.1.3.6.1.2.1.31.1.1.1.6），它支持16EB流量，彻底规避溢出。

经验之谈：MRTG生成的HTML页面默认无密码保护，暴露在公网等于泄露网络拓扑。生产环境必须用Apache Basic Auth保护。在/etc/apache2/sites-available/000-default.conf中添加：

<Directory "/var/www/html/mrtg"> AuthType Basic AuthName "MRTG Access" AuthUserFile /etc/apache2/.mrtg-passwd Require valid-user </Directory>

然后sudo htpasswd -c /etc/apache2/.mrtg-passwd mrtguser创建用户。安全不是可选项，而是SNMP部署的起点。

6. Daemon生命周期管理：从启动失败到优雅重启的完整掌控

snmpd作为daemon，其生命周期远比systemctl start复杂。Ubuntu 18.04的snmpd服务在systemd中被标记为Type=simple，这意味着systemd认为进程启动即完成，但snmpd实际要经历“加载MIB→绑定端口→读取用户配置→初始化USM引擎”四个阶段。任何一个阶段失败，都会导致systemctl status snmpd显示active (running)，而实际无法响应请求。这就是为什么你总看到error response from daemon: unknown: failed to resolve reference这类错误——它根本不是Docker相关，而是snmpd启动过程中的内部错误被systemd错误捕获。

6.1 启动失败的三类核心日志溯源

snmpd的日志分散在三个位置，必须交叉验证：

1. systemd journal：sudo journalctl -u snmpd -n 50 --no-pager
   关键线索：Failed to start SNMP daemon或snmpd[1234]: Error opening specified endpoint

2. snmpd自身日志：sudo tail -n 20 /var/log/syslog \| grep snmpd
   关键线索：Cannot find module (IF-MIB)（MIB缺失）或usmUserTable: unable to create row（v3用户配置损坏）

3. 配置语法检查日志：sudo snmpd -f -Lo -C -c /etc/snmp/snmpd.conf 2>&1
   前台运行时的实时输出，最精准。常见错误如Unknown token: rocommunity6（Ubuntu 18.04不支持IPv6 community）或Invalid address: udp6:[::1]:161（IPv6地址格式错误）

我曾遇到一个案例：journalctl显示active (running)，但ss -tuln \| grep 161无输出。检查syslog发现snmpd[1234]: Error opening specified endpoint 'udp:161'，而前台运行显示Unknown token: agentAddress。最终定位到/etc/snmp/snmpd.conf被错误地加入了include /etc/snmp/custom.conf，而custom.conf文件为空，导致snmpd解析中断。删除include行后一切正常。

6.2 优雅重启的原子化步骤

systemctl restart snmpd看似简单，实则风险极高。它会终止旧进程并启动新进程，期间SNMP服务完全不可用。对于Zabbix监控，这会导致5分钟的数据断点。真正的优雅重启是“无缝切换”：

# 步骤1：启动新实例，监听临时端口 sudo snmpd -f -Lo -C -c /etc/snmp/snmpd.conf -p /var/run/snmpd_new.pid -a -x tcp:localhost:705 -u snmp -g snmp -I -smux,mteTrigger,mteTriggerConf udp:162 # 步骤2：验证新实例是否正常 snmpwalk -v2c -c public localhost:162 system | head -5 # 步骤3：平滑切换（需snmpd支持AgentX） # 在旧snmpd.conf中添加：master agentx # 在新snmpd.conf中添加：agentXSocket tcp:localhost:705 # 然后kill旧进程，新进程自动接管 sudo kill $(cat /var/run/snmpd.pid)

这种方法将停机时间压缩到毫秒级，但要求snmpd编译时启用了AgentX支持（Ubuntu 18.04默认开启）。

6.3 进程僵死的终极清理术

有时systemctl stop snmpd后，ps aux \| grep snmpd仍能看到残留进程。这是因为snmpd的子进程（如snmpd-trapd）未被正确回收。强制清理命令：

# 查找所有snmpd相关进程 pgrep -f "snmpd" | xargs -r kill -9 # 清理IPC资源（共享内存和信号量） ipcs -q | awk '$3 ~ /snmp/ {print $2}' | xargs -r ipcrm -q ipcs -m | awk '$3 ~ /snmp/ {print $2}' | xargs -r ipcrm -m # 删除PID文件（防止下次启动冲突） sudo rm -f /var/run/snmpd.pid /var/run/snmpd_new.pid

执行后，systemctl start snmpd才能真正从干净状态启动。

6.4 内存泄漏的主动防御策略

snmpd在长期运行中可能出现内存缓慢增长。Ubuntu 18.04的5.7.3版本存在一个已知问题：当频繁查询大量OID时，MIB解析缓存不释放。预防措施是在/etc/default/snmpd中添加：

SNMPDOPTS="$SNMPDOPTS -M /usr/share/snmp/mibs:/usr/share/snmp/mibs/iana:/usr/share/snmp/mibs/ietf"

显式指定MIB路径，避免snmpd动态扫描整个/usr/share/snmp/mibs目录。同时，设置systemd自动重启：

sudo systemctl edit snmpd

输入：

[Service] Restart=on-failure RestartSec=30 MemoryLimit=256M

这样当snmpd因OOM被kill，30秒后自动重启，且内存上限设为256MB，杜绝失控增长。

最后提醒：所有配置修改后，必须执行sudo systemctl daemon-reload重新加载unit文件，否则systemctl restart不会读取新的/etc/default/snmpd。这是Ubuntu 18.04 systemd的一个易忘点，我见过太多人改完配置却无效，根源就在这里。