上周接了个监控项目客户机房里二十来台Anolis OS服务器需要全部纳入统一监控平台。这批机器跑着线上业务不能随便动所以第一件事就是把SNMP服务拉起来让监控端能直接采集CPU、内存、磁盘这些基础指标。Anolis OS平时聊的人不算多但它和CentOS/RHEL的兼容性相当好装net-snmp这整套工具链的路径很顺几乎没有水土不服的问题。这篇文章就把完整流程展开讲一遍从原理铺垫、安装方式、配置文件玩法、验证联调到安全加固全是一条龙实操记录适合正在做服务器监控选型或者刚接手龙蜥服务器要纳入监控体系的运维朋友参考。1. 装SNMP之前先搞清楚这套体系是怎么运作的1.1 被监控端与监控端的分工关系SNMPSimple Network Management Protocol不是像sshd那样的交互式服务而是一套“代理-管理者”架构。Anolis OS上装的net-snmp担任agent角色持续监听UDP 161端口监控中心比如Zabbix、Prometheus生态里的snmp_exporter或者最简单的MRTG担任manager角色按周期向agent发起GET请求。agent接到请求后从系统内核里把CPU负载、内存占用、磁盘分区这些数据提取出来按MIB库里定义的OID结构返回给监控端。整个过程走UDP所以天然轻量不会像SSH那样反复建立连接消耗资源一台agent同时给多个manager提供服务也没压力。这个架构带来一个最直接的好处监控端不需要在被监控机上装任何专用软件只要设备支持SNMP协议就能纳入同一套监控体系。这也是为什么做服务器、网络设备、存储混编监控时优先用SNMP——Brocade光纤交换机、Windows服务器、Linux服务器虽然系统完全不同但SNMP协议语言是统一的。你在一台Anolis OS上把配置摸透了这套思路平移给同机房的交换机和Windows机器照样成立。动手之前有三个信息先确认好这台机器的IP地址、监控端所在的网段范围、以及准备用哪个SNMP版本。如果环境里已经有监控平台这些一般都有明确约定如果是从零开始搞后面配置部分我会给出推荐默认值。1.2 不同SNMP版本的选择逻辑SNMP版本的选择直接影响配置写法和安全模型这块值得先说清楚。版本认证方式加密适用场景v1社区字符串明文无老设备兼容基本不建议新部署v2c社区字符串明文无内网可信环境最常用v3用户名 认证密码 加密密码AES/DES跨网段或公网环境安全性高v1和v2c本质上没有太大区别v2c增强了数据类型新增Counter64这些是目前绝大多数监控系统默认支持的版本。它的社区字符串相当于一个密码但走的是明文传输抓包能看到所以只能在可信内网用。v3引入了用户模型和加密机制认证、加密都能独立控制安全性好很多但配置复杂一些需要监控端也支持v3协议。我个人的倾向是如果设备在内网隔离环境且监控端网段可控用v2c加随机社区字符串就够了这也是Zabbix这类平台最顺手的方案如果服务器有公网IP或者要跨机房、跨地域纳管直接上v3别犹豫。Anolis OS的net-snmp对v3支持很完整不用担心功能缺失。1.3 Anolis OS软件源与CentOS生态的兼容性Anolis OS是RHEL/CentOS的兼容发行版Anolis OS 8对应RHEL 8Anolis OS 7对应RHEL 7Anolis OS 23是更新的大版本。无论哪个版本安装net-snmp都走yum/dnf这条路包名和作用和CentOS完全一致。这意味着从CentOS迁移过来的运维脚本、systemd服务管理方式、配置目录结构基本都不用改不会有生态断层的感觉。一个比较实用的点是Anolis OS的默认yum源在国内访问速度很好不像某些海外发行版需要先换源折腾半天。软件包版本也不是特别老net-snmp 5.7以上的版本在CentOS 7时期就已经很成熟该有的功能一个不少。2. 在线安装与离线安装两种方式都跑通2.1 通过yum在线安装的完整命令与验证在线安装是最省事的路径。在Anolis OS上直接执行yum install -y net-snmp net-snmp-utilsnet-snmp是服务端守护进程组件net-snmp-utils是管理工具族里面有snmpwalk、snmpget、snmpgetnext、snmpstatus、snmpd等命令联调阶段全靠它。我见过有人只装net-snmp不装utils结果配置完服务起没起、数据对不对都没法验证还得另找一台装了工具包的机器来探测非常被动。所以两个包一次装齐是最稳的搭配。装完验证一下包是否齐全、服务是否能被systemd识别rpm -qa | grep net-snmp systemctl status snmpd如果rpm -qa能看到net-snmp、net-snmp-libs、net-snmp-utils这几个包说明安装已完成。此时snmpd服务默认可能还没启动不要急先继续配置配置完再统一启动。2.2 内网离线环境下用RPM包安装生产环境的大多数服务器都跑在内网访问不了外网yum源这时候要先准备好离线的RPM包。我的做法是找一台同架构且能临时访问外网的机器用yum的--downloadonly参数把安装包连同依赖一起拉下来然后拷到目标机器。能上网的机器上执行yum install --downloadonly --downloaddir/root/snmp_rpm net-snmp net-snmp-utils执行完检查/root/snmp_rpm目录里面应该有net-snmp、net-snmp-libs、net-snmp-utils以及它们依赖的libsensors、perl等包。把这些rpm文件用scp或U盘拷到内网目标机器上执行rpm -ivh /root/snmp_rpm/*.rpm或者更稳妥一点用yum localinstall让它自动处理本地rpm之间的依赖顺序yum localinstall -y /root/snmp_rpm/*.rpm这条命令会先扫描本地目录里的rpm包解析内部依赖比rpm -ivh省心得多。需要注意两点第一下载rpm的机器和目标机器的操作系统版本要尽量一致比如都是Anolis OS 8避免潜在的库版本不兼容第二如果公司内网本身有软件仓库镜像直接把yum源切到内网仓库再正常yum install是更规范的方案离线rpm只适合量少或者临时环境。2.3 安装后必须检查的三个状态装完不能下结论说“装好了”要确认三件事服务进程存活、开机自启生效、UDP 161端口在监听。systemctl enable --now snmpd systemctl status snmpd ss -lnu | grep 161ss的输出里应看到类似udp 0 0 0.0.0.0:161 0.0.0.0:*的记录。如果看不到161大概率是服务没起来或者agentAddress被配置成监听特定IP了。这个坑后面排查部分会详细讲。开机自启用的是--now参数一步到位免得服务器重启之后snmpd没有自动拉起监控数据断掉没人发现。3. snmpd.conf配置把该暴露的暴露出去不该暴露的锁死3.1 配置文件核心指令速览net-snmp的配置文件是/etc/snmp/snmpd.conf这是整个安装过程的核心。指令不多常用的就这几个指令作用agentAddress定义agent监听地址和端口rocommunity定义只读社区字符串并限制来源网段rwcommunity定义读写社区字符串一般别用view定义MIB视图限制暴露的OID范围syslocation / syscontact设置系统位置和联系人信息disk / load / proc开启磁盘、负载、进程监控项配置文件对指令顺序没有严格要求但每行的语法必须正确写错一个指令名snmpd会直接拒绝启动。我习惯在文件头先写agentAddress接着写rocommunity和view最后写disk这些监控项逻辑清晰排查问题也方便。3.2 社区字符串、ACL与监听地址的组合写法先给一个最基础、可用于本地自测的配置agentAddress udp:127.0.0.1:161 rocommunity public 127.0.0.1 syslocation Local Test syscontact adminexample.com这个配置只监听本机只有本机能读取适合刚装完做自测但不适合生产。生产环境我一般这么写agentAddress udp:192.168.10.10:161 rocommunity An0lisM0n 192.168.10.0/24 syslocation IDC-A, 3F, Rack 12, Server 34 syscontact opscompany.comrocommunity后面先写社区字符串再写允许访问的网段。这种写法有两个作用一是社区字符串不再是public这种默认值暴力猜解难度大幅提高二是即使有人拿到了字符串只要不是从192.168.10.0/24这个网段发起请求agent同样会拒绝。字符串本身尽量用字母大小写加数字组合长度不低于12位比单纯设个复杂密码还省心。如果需要更细粒度的权限控制可以配合view实现。比如给另一个网段只开放系统信息不允许查看进程列表和磁盘路径view systemview included .1.3.6.1.2.1.1 view systemview included .1.3.6.1.2.1.25.1 rocommunity limited 192.168.20.0/24 -V systemview这条配置的含义是192.168.20.0/24网段的监控端只能读取systemview视图里包含的OID其余一概返回“无此节点”。视图的范围越小暴露面越小这在多部门共用监控平台时特别实用。3.3 监控系统最常用的OID对照表监控采集最重要的事情是知道数据在哪个OID下。我把日常监控最常用的OID整理出来可以直接存着当速查表用监控内容OID所在MIB系统描述.1.3.6.1.2.1.1.1SNMPv2-MIB系统运行时间.1.3.6.1.2.1.1.3SNMPv2-MIB主机存储设备表.1.3.6.1.2.1.25.2.3.1.3HOST-RESOURCES-MIB存储设备已用空间.1.3.6.1.2.1.25.2.3.1.6HOST-RESOURCES-MIBCPU负载1分钟.1.3.6.1.4.1.2021.10.1.3.1UCD-SNMP-MIB内存总量.1.3.6.1.4.1.2021.4.5.0UCD-SNMP-MIB内存已用量.1.3.6.1.4.1.2021.4.6.0UCD-SNMP-MIB网卡入流量.1.3.6.1.2.1.2.2.1.10IF-MIB网卡出流量.1.3.6.1.2.1.2.2.1.16IF-MIB磁盘IO.1.3.6.1.4.1.2021.13.15UCD-DISKIO-MIB这里要特别说明一下HOST-RESOURCES-MIB和UCD-SNMP-MIB的区别。HOST-RESOURCES-MIB是标准的跨平台主机资源MIBWindows和Linux通用适合做平台统一的监控UCD-SNMP-MIB是net-snmp自己扩展的专属MIB数据更细比如每个核的负载、具体内存构成但换到Windows设备上就没有这些数据了。跨平台监控建议优先依赖标准MIB扩展MIB作为补充。3.4 启用磁盘、负载和进程监控项如果只是用默认配置snmpd已经能返回基础系统信息了但磁盘空间、CPU负载、关键进程状态这几个监控项默认不开启需要显式声明。在snmpd.conf里加这几行disk / 100000 disk /data 10% includeAllDisks 10% load 10 9 8 proc snmpd 0解释一下含义disk / 100000表示监控根分区的剩余空间低于100000 KB约100MB就触发阈值告警disk /data 10%表示监控/data分区剩余空间不低于总容量的10%includeAllDisks 10%相当于兜底策略所有未被单独列出的分区统一按剩余空间10%的规则监控。load 10 9 8对应的是一分钟、五分钟、十五分钟负载的阈值分别为10、9、8这个数值要根据服务器核心数来定一般取核心数的70%左右比如16核的机器可以设load 11 10 9。proc snmpd 0表示监控snmpd进程是否存在最后的0表示只要有1个snmpd进程就算正常。配置好这些后监控端就能通过UCD-SNMP-MIB的对应节点拿到磁盘和负载数据Zabbix这些平台的默认模板也是按这套逻辑去取的。3.5 配置语法检查与服务重启改完配置文件不要直接restart了事先做个语法验证。最直接的方式是前台启动snmpd看看它报不报错snmpd -f -Lo-f表示前台运行-Lo把日志输出到标准输出。如果配置无误命令会一直挂着不退出等看到类似“NET-SNMP version 5.9.3”的启动日志后按CtrlC退出。如果配置文件有语法错误snmpd会立刻报错退出日志里会明确告诉你哪一行有问题。确认无误后再正式重启systemctl restart snmpd重启之后再看一眼状态systemctl status snmpd journalctl -u snmpd -n 20 --no-pagerjournalctl输出的最后几行如果出现Started Simple Network Management Protocol (SNMP) Daemon.说明服务正常起来了。4. 验证与联调从本机自测到监控平台接入4.1 本机自测的正确姿势配置完snmpd第一件事是在本机验证数据能不能取出来而不是直接让监控端去采集否则出了问题还要区分是agent的故障还是网络策略的故障。本机自测命令snmpget -v2c -c An0lisM0n 127.0.0.1 .1.3.6.1.2.1.1.1.0 snmpwalk -v2c -c An0lisM0n 127.0.0.1 system snmpwalk -v2c -c An0lisM0n 127.0.0.1 .1.3.6.1.2.1.25.2.3.1.3 snmpwalk -v2c -c An0lisM0n 127.0.0.1 .1.3.6.1.4.1.2021.10.1.3.1第一条snmpget是精确取一个OID的值如果返回了sysDescr的描述文本说明agent正常响应第二、三、四条是遍历一整棵OID树依次验证系统信息、存储设备列表、CPU负载。这些命令能正常出数据agent侧就没问题了。这里有个细节snmpwalk遍历的是agent视角下可见的所有节点如果某个区域一直没响应可能是view视图把它过滤掉了或者对应的MIB模块没加载。net-snmp默认会加载常见MIB模块一般不会出现缺模块的问题。4.2 监控端远程探测的排错顺序本机自测通过后远程探测连不上不要着急怀疑SNMP配置按这个顺序捋一遍网络是否可达先在监控端ping服务器IP通不过去就是路由或安全组问题。UDP 161是否放行在服务器上执行firewall-cmd --list-all看有没有snmp服务或161/udp端口规则。agentAddress是否绑在可达IP上执行ss -lnu | grep 161如果监听地址是127.0.0.1那远程自然连不上。社区字符串和ACL是否匹配远程用snmpget手动指定正确的社区字符串试一次排除字符串不匹配。监控端IP是否在允许网段内重看rocommunity里的网段范围。排这个顺序的依据是网络层问题最容易被忽略端口问题和绑定问题是配置层最常见的原因字符串和ACL属于最后一层检查。实际运维中前三步解决掉九成以上的问题。4.3 对接Zabbix和Prometheus的配置要点Zabbix接入非常直接主机配置里新增一个SNMP接口填IP和端口161SNMP版本选2ccommunity填snmpd.conf里的字符串然后关联模板“Template OS Linux by SNMP”。Zabbix自带的模板会去请求系统信息、CPU负载、内存、磁盘分区、网卡流量这些OID只要agent端没做严格的视图限制基本开箱即用。Prometheus生态需要用snmp_exporter。配置文件的generator里auth块要定义communitymodules指定需要采集的MIB模块。基础配置示例auth: community: An0lisM0n modules: default: walk: - 1.3.6.1.2.1.25.2.3 - 1.3.6.1.4.1.2021.10 - 1.3.6.1.2.1.2.2用snmp_exporter的generator生成snmp.yml后在配置文件里引用即可。这里踩过一个小坑generator依赖MIB文件如果你的机器上没有装net-snmp的MIB库生成时会提示找不到节点解决办法是安装yum包net-snmp-libs或者把MIB文件拷贝到/usr/share/snmp/mibs目录下。5. 踩坑实录防火墙、SELinux、服务异常退出5.1 UDP 161端口被防火墙拦掉的完整排查链路这个坑我印象最深。有次给一台Anolis OS 8配好snmpd本机snmpwalk跑得飞快但监控端一直报超时。第一反应是agent配置错了来回改了三次rocommunity问题依旧。后来冷静下来按链路排查监控端执行nc探测nc -uvz 192.168.10.10 161输出显示UDP port 161 unreachable说明报文根本没到服务器端口。登录服务器检查firewalldfirewall-cmd --list-all结果里既没有snmp服务也没有161/udp端口规则。这就破案了Anolis OS默认firewalld是开启的只是yum装net-snmp时不会自动放行端口。执行firewall-cmd --permanent --add-servicesnmp firewall-cmd --reload--add-servicesnmp会自动放行udp 161比--add-port161/udp更规范因为服务名到端口的映射由系统维护。重载后再从监控端nc一次通了。这个坑的教训就是配好agent之后先确认端口在监听、防火墙有放行再上监控平台两个检查点能省掉大量来回沟通的时间。5.2 SELinux拦截导致监控数据缺失的表现与修复Anolis OS默认SELinux是Enforcing模式这个特性对snmpd的影响很隐蔽。表现是snmpwalk取系统信息正常、取CPU负载也正常但取磁盘存储表HOST-RESOURCES-MIB的hrStorageTable时返回空或部分缺失。光看snmpd.conf看不出任何问题因为配置完全正确问题出在SELinux策略上。排查方法是去audit日志里找线索grep -i denied.*snmp /var/log/audit/audit.log | tail -20如果看到类似avc: denied { getattr } for pidxxxx commsnmpd的记录说明SELinux确实拦了。修复方式restorecon -Rv /etc/snmp setsebool -P snmpd_read_all_files on第一条是恢复/etc/snmp目录的标准SELinux上下文防止目录上下文错乱第二条是允许snmpd读取系统文件用于采集文件系统数据。这里务必带上-P参数否则重启后配置丢失。修复完重启snmpd再测磁盘表数据就正常了。5.3 修改配置后服务异常退出的常见原因snmpd配置错误导致起不来是新手最容易遇到的问题journalctl是最直接的诊断工具journalctl -u snmpd -n 30 --no-pager常见的几类原因我归纳一下错误类型典型表现处理方法指令拼写错误日志提示“Error parsing config file”对照官方指令名逐行检查配置文件权限不当日志提示“bad line”或拒绝读取属主设为root权限600即可社区字符串含特殊字符字符串被错误截断字符串尽量只用字母数字agentAddress地址冲突提示地址已在别处指定检查是否重复配置了agentAddress配置文件权限这一点不少老手也会栽跟头。如果把snmpd.conf权限改成了777net-snmp出于安全考虑会拒绝读取或者部分加载。标准做法是chown root:root /etc/snmp/snmpd.confchmod 600这样既能保证agent正常读配置也能避免普通用户看到社区字符串。还有一个经验改完配置不要急着restart先用snmpd -f -Lo前台跑一下确认没报错再走systemctl restart。前台验证的成本比反复看journalctl低得多等于给配置加了一道保险。6. 安全加固与日常维护社区字符串是最容易被忽略的口子6.1 为什么不能一直用public学习阶段大家都用public因为教材里默认值就是它但public这个词在SNMP圈子里等同于“没上锁的门”。只要服务器暴露在可达的网络上任何扫描器都能用public拉走系统信息包括主机名、运行时长、网卡速率、磁盘分区结构这些看似零散的信息在攻击者手里能组合成立体画像为后续渗透提供很大便利。更要命的是如果配置里写了rwcommunity而不是rocommunity别人不仅能读还能通过SNMP Set指令修改设备参数这在网络设备上属于直接控制级别的风险。所以无论如何生产环境下不要保留public字符串也不要设置rwcommunity哪怕内网也要按最小权限原则来。6.2 限制源地址与启用SNMP v3的实操最容易做的加固是把rocommunity后面的来源网段写具体不要图省事写成0.0.0.0/0rocommunity MyStr0ngC0mmunity 192.168.10.0/24这等于给社区字符串加了一道IP白名单即使字符串被泄露攻击者还得从白名单网段内发请求才能命中。跨网段或对安全性要求更高时直接上SNMP v3。创建用户用net-snmp自带的工具net-snmp-config --create-snmpv3-user -ro -a SHA-256 -A AuthPass123 -x AES -X PrivPass123 monitor这条命令创建了一个名为monitor的只读用户认证协议SHA-256、认证密码AuthPass123加密协议AES、加密密码PrivPass123。创建完成后用户信息会写入net-snmp的本地配置库重启snmpd生效。验证方式snmpwalk -v3 -u monitor -a SHA-256 -A AuthPass123 -x AES -X PrivPass123 -l authPriv 127.0.0.1 system注意参数里-l authPriv表示同时启用认证和加密这是推荐级别如果去掉加密等于认证后的流量还在裸奔v3的优势就丢了一半。Zabbix里配置v3时SNMP版本选择v3填对应的用户名、认证密码、加密密码算法选SHA和AES就能和这个配置对上。从v2c迁移v3不需要停机可以先在snmpd.conf里同时保留rocommunity和新v3用户验证v3链路通了之后再下线v2c平滑过渡。6.3 日常巡检与维护建议SNMP服务一旦配好往往就变成“隐形服务”直到监控平台告警才发现它挂了。我建议把这几件事纳入日常巡检清单进程存活检查定期执行systemctl is-active snmpd也可以直接让监控平台加一个agent进程的监控项agent挂掉立即告警。端口监听确认ss -lnu | grep 161防止agentAddress被改错或服务重启后绑定异常。日志关注journalctl -u snmpd -f实时看平时抽查journalctl -u snmpd -n 50如果出现大量连接超时或验证失败记录说明有人或某台设备在尝试连接要及时排查来源。网段变更同步如果服务器IP或监控端网段调整记得同步改agentAddress和rocommunity里的ACL范围否则会出现监控数据静默中断。安全审计定期检查snmpd.conf里是否还有public字符串是否有未授权的rwcommunity行发现立即整改。实际运维里我还会每月跑一次snmpwalk做数据抽检然后和监控平台上的历史曲线对比能及时发现采集延迟、数据缺失这类不触发告警但影响数据质量的隐性问题。按我个人经验SNMP在未来很长一段时间内仍然是服务器和网络设备监控的主流协议原因很简单它足够老、足够稳定、覆盖足够广。一次在Anolis OS上把SNMP配置梳理清楚同类Linux服务器改改社区字符串和IP就能批量复制。对刚上手龙蜥的朋友建议是不要一上来就想着把所有OID都暴露出来先定义一个只读、受限、来源可控的访问模型把基础监控跑通再逐步扩大到磁盘IO、接口流量这些更细的指标。配置这件事从简到繁不难难的是从一开始就管住安全边界。