Nightingale 与 Categraf SNMP 插件网络设备监控采集、仪表盘与告警实战指南【免费下载链接】nightingaleNightingale is to monitoring and alerting what Grafana is to visualization.项目地址: https://gitcode.com/GitHub_Trending/ni/nightingale网络设备的监控主要依赖 SNMP简单网络管理协议协议完成Categraf、Telegraf、Datadog-Agent、snmp_exporter 等采集器都提供了这一能力。本文以 Nightingale 仓库中 SNMP 集成 的说明为主体结合仓库内真实的采集配置、仪表盘与告警规则系统讲解如何用 Categraf 的 SNMP 插件采集网络设备指标、如何在 Nightingale 中落地流量仪表盘与告警。读完本文你将掌握配置 OID 即采集指标的插件核心用法、SNMPv3 认证配置、通用 OID 与厂商私有 OID 的取舍以及从连通性测试到告警排错的全链路方法。一、为什么用 Categraf 的 SNMP 插件Categraf 从 v0.2.13 版本开始把 Telegraf 的 snmp 插件集成进来官方推荐使用该插件监控网络设备。这个插件的核心逻辑非常简洁要采集什么指标直接配置对应的 OID 即可而且可以把部分 OID 采集到的数据当作时序数据的标签tag使用灵活度极高。例如把RFC1213-MIB::sysName.0采集到的设备名称作为标签那么后续所有来自该设备的时间序列都会自动带上设备名在仪表盘中即可按设备维度进行筛选和聚合。这种指标 标签由 OID 配置直接驱动的方式让网络设备监控的扩展成本降到最低——新增一个指标通常只需要新增一行 OID 配置。当然SNMP 世界也有明显的弊端体系内存在大量厂商私有 OIDprivate OID。例如不同品牌、不同型号的设备获取 CPU、内存利用率的 OID 往往都不一样这就意味着不同型号的设备需要不同的采集配置维护成本较高需要长期的经验积累。仓库内的 collect/snmp 目录就展示了通用配置snmp.toml与厂商专用配置Cisco.toml两种形态的差异。二、快速上手通用 OID 采集配置详解虽然私有 OID 繁多但对于网络设备而言大部分监控数据用标准 MIB如 RFC1213-MIB、IF-MIB、UCD-SNMP-MIB中的通用 OID 即可采集。仓库 README 给出了一个完整的通用配置示例interval 120 [[instances]] agents [udp://172.30.15.189:161] interval_times 1 timeout 5s version 2 community public agent_host_tag agent_host retries 1 [[instances.field]] oid RFC1213-MIB::sysUpTime.0 name uptime [[instances.field]] oid RFC1213-MIB::sysName.0 name source is_tag true [[instances.table]] oid IF-MIB::ifTable name interface inherit_tags [source] [[instances.table.field]] oid IF-MIB::ifDescr name ifDescr is_tag true [[instances.table.field]] oid IF-MIB::ifSpeed name ifSpeed [[instances.table.field]] oid IF-MIB::ifOperStatus name ifOperStatus [[instances.table.field]] oid IF-MIB::ifInOctets name ifInOctets [[instances.table.field]] oid IF-MIB::ifOutOctets name ifOutOctets2.1 实例级参数参数示例值含义interval120采集周期秒作用于整个插件agents[udp://172.30.15.189:161]被采集设备的地址列表支持多台设备interval_times1采集周期倍数与interval相乘得到实际周期timeout5s单次请求超时时间version2SNMP 版本可取 1、2、3communitypublicSNMPv1/v2 的团体字community stringagent_host_tagagent_host给时间序列打上的设备标识标签名retries1请求失败后的重试次数其中agents的完整格式为scheme://hostname:portscheme 可选udp、udp4、udp6、tcp、tcp4、tcp6默认为udp端口可省略默认 161。详见仓库中的 snmp.toml.example。2.2 field 与 table两种采集形态[[instances.field]]采集单个标量 OID。上面的示例中sysUpTime.0被命名为uptime指标sysName.0被命名为source并且由于设置了is_tag true它不再作为指标值而是作为标签附加到同实例的所有时间序列上。[[instances.table]]采集一张 SNMP 表如IF-MIB::ifTable接口表表格会被展开成多行时序数据。name interface定义了表名采集出的指标将以snmp_interface_*为前缀命名inherit_tags [source]表示把顶层 field 中定义的标签如source继承到表格的每一行序列上这样每条接口流量序列都能知道它来自哪台设备。[[instances.table.field]]定义表中要采集的列。ifDescr同样被标记为is_tag true作为区分不同接口的标签ifSpeed、ifOperStatus、ifInOctets、ifOutOctets则作为普通指标值上报。从仓库 dashboards.json 中可以看到仪表盘实际查询的指标名即为snmp_interface_ifInOctets、snmp_interface_ifOutOctets、snmp_interface_ifDescr、snmp_interface_ifOperStatus、snmp_uptime等与上述命名规则完全对应这也验证了snmp_ 表名 _ 字段名的指标命名规律。2.3 安全提醒与仪表盘依赖示例中的public团体字仅用于示例和测试环境。生产环境的设备应使用独立且受控的 community或优先采用 SNMPv3见下文。另外需要特别注意本目录附带的通用流量仪表盘依赖以下标签/指标agent_host、ifDescr、ifSpeed、ifOperStatus、ifInOctets、ifOutOctets。如果修改了agent_host_tag的名字必须同步修改仪表盘变量否则仪表盘将无法正确过滤和展示数据。同时为了兼容历史模板可以把同一个标准 OID 以不同字段名重复采集例如将IF-MIB::ifDescr同时命名为ifDescr与ifname将流量计数同时命名为ifInOctets/incoming、ifOutOctets/outgoing这样新老两套仪表盘都能命中数据详见仓库中的 中文版 README。三、参数参考snmp.toml.example 全参数解析仓库中的 snmp.toml.example 是插件参数的权威参考除上文已介绍的参数外还包含以下常用项参数说明unconnected_udp_socket是否使用非连接 UDP 套接字。置为true时SNMP 响应可来自任意地址而非仅限请求地址适用于冗余/故障切换系统场景pathMIB 文件路径供 gosmi 翻译器使用若使用 net-snmp 翻译可通过MIBDIRS环境变量添加路径例如[/usr/share/snmp/mibs]max_repetitionsGETBULK 请求的 max-repetitions 参数影响批量抓取表数据的效率默认 10filters/filters_expressionfield/table 级过滤。字段级过滤器格式形如A:ifIndex:^2$、B:ifOperStatus:1、C:ifDescr:^eno*再通过filters_expression如(A B) || C组合多个过滤条件3.1 SNMPv3 认证与加密参数SNMPv3 相比 v2 增加了用户认证authentication与数据加密privacy能力示例配置中的参数含义如下参数可选值说明sec_name任意用户名SNMPv3 安全用户名Security Nameauth_protocolMD5、SHA、SHA224、SHA256、SHA384、SHA512或空认证协议auth_password任意字符串认证密码sec_levelnoAuthNoPriv、authNoPriv、authPriv安全级别不认证不加密 / 只认证 / 认证并加密priv_protocolDES、AES、AES192、AES192C、AES256、AES256C或空加密协议priv_password任意字符串加密密码context_name字符串Context 名称多租户场景下使用注意AES192、AES192C、AES256、AES256C等协议要求底层的 net-snmp 工具在编译时启用--enable-blumenthal-aes。四、SNMPv3 认证配置示例上面的样例是 v2 版本的配置如果设备只开放 SNMPv3认证配置示例如下同样来自 READMEversion 3 sec_name managev3user auth_protocol SHA auth_password auth-password sec_level authPriv priv_protocol AES priv_password privacy-password该配置启用了认证 加密的最高安全级别authPriv用 SHA 算法做身份认证用 AES 算法对报文加密。生产环境中建议优先使用这种方式替代 v1/v2 的明文团体字。五、深入实战仓库中的两份参考采集配置5.1 通用配置 snmp.toml标准 OID 采集 CPU、内存、负载与接口仓库 collect/snmp/snmp.toml 是一份可直接落地的通用配置其中大量使用数字 OID来采集主机资源指标避免了 MIB 名称解析的依赖agents [ # udp://10.206.0.16:161, ] timeout 5s version 2 community public agent_host_tag agent_hostname retries 3 [[instances.field]] oid .1.3.6.1.2.1.1.3.0 name uptime [[instances.field]] oid .1.3.6.1.4.1.2021.11.9.0 # % name cpu_user [[instances.field]] oid .1.3.6.1.4.1.2021.11.10.0 # % name cpu_sys [[instances.field]] oid 1.3.6.1.4.1.2021.11.11.0 # % name cpu_idle [[instances.field]] oid .1.3.6.1.2.1.25.2.2.0 name mem_total [[instances.field]] oid .1.3.6.1.4.1.2021.4.11.0 name mem_free # network [[instances.table]] oid IF-MIB::ifTable name interface inherit_tags [source] index_as_tag true include_filter [ifIndex:2,ifIndex:4] [[instances.table.field]] oid IF-MIB::ifDescr name ifDescr is_tag true这份配置里有两个值得注意的细节数字 OID 与符号名混用既可以用.1.3.6.1.2.1.1.3.0也可以用IF-MIB::ifTable这类符号名插件都能解析。index_as_tag true与include_filter前者将表的索引列如ifIndex作为标签输出便于区分同一设备上的不同接口后者用于只采集满足条件的行例如只采集ifIndex为 2 和 4 的接口减少无用数据量。该配置采集的cpu_idle、mem_total、mem_free等指标与仪表盘中的100 - snmp_cpu_idle、(snmp_mem_max - snmp_mem_free) / snmp_mem_max * 100表达式一一对应可直接驱动 SNMP Stats 仪表盘 中的 CPU/内存面板。5.2 厂商专用配置 Cisco.toml私有 OID 与值转换仓库 collect/snmp/Cisco.toml 展示了面向具体厂商设备的私有 OID 采集方式其中几个要点agents [udp://127.0.0.1] timeout 5s version 2 community public agent_host_tag DCN retries 3 max_repetitions 100 [[instances.field]] oid 1.3.6.1.2.1.1.3.0 name sys_uptime conversion float(2) [[instances.field]] oid 1.3.6.1.4.1.6339.100.1.11.10.0 # 厂商私有CPU 使用率 name cpu_usage [[instances.field]] oid 1.3.6.1.4.1.6339.100.1.11.6.0 # 厂商私有内存最大值 name mem_max [[instances.field]] oid 1.3.6.1.4.1.6339.100.1.11.7.0 # 厂商私有内存使用量 name mem_use [[instances.field]] oid 1.3.6.1.2.1.1.5.0 name sys_name is_tag true这里可以看到私有 OID 的典型特征1.3.6.1.4.1.6339...中的6339就是厂商在 IANA 申请的企业号enterprise number不同厂商完全不同这正是不同型号设备需要不同配置的根源。此外conversion float(2)是插件提供的数据转换能力把采集到的原始值按指定规则转换为浮点数如把千分位/特殊编码的计数器换算成可读数值ifSpeed列还使用了conversion float(6)将接口速率转换为以 bit/s 为单位的值。这类转换在厂商私有指标中非常常见。六、与 Nightingale 联动仪表盘与告警规则该集成目录integrations/SNMP不仅包含采集配置还自带了一套与 Nightingale 平台配套的仪表盘、告警规则和指标字典导入即可使用6.1 仪表盘dashboards 目录SNMP Statsdashboards.json通用状态面板包含 Uptime、CPU 使用率、内存使用率、每秒新建连接数、进出流量、丢包数、接口状态表等。其接口状态表对ifOperStatus的取值做了颜色映射up(1)显示为绿色 UP、down(2)显示为红色 DOWN、testing(3)为 TESTING一目了然。网络设备详情通用仪表盘网络设备详情通用仪表盘.json网络设备端口流量视图网络设备端口流量视图.jsonSNMP 网络设备状态汇总SNMP 网络设备状态汇总.json华为网络设备详情华为网络设备详情.json、Juniper 网络设备详情Juniper网络设备详情.json等厂商专用大盘6.2 告警规则alerts 目录告警规则以 JSON 形式提供可以直接导入 Nightingale。以 SNMP Network.json 为例内置了三条典型告警带宽使用率过高Bandwidth Usage Too High核心表达式为min_over_time(delta(snmp_network_status_incoming[3m]) * 8 / 180 / 1024 / 1024 [3m]) snmp_network_status_speed / 1000 * 0.7 * 1024 * 1024 * 1024即按物理端口容量的70% / 90%设置两档告警severity 3 / 2。表达式先把流量计数换算成 bit/s再与ifSpeed表示的端口容量比较。CRC 错误CRC Errordelta(snmp_network_status_incoming_errors[1m]) 100 and delta(snmp_network_status_incoming_errors[1m]) / delta(snmp_network_status_incoming_ucastpkts[1m]) 0.001要求 1 分钟内错误包增量大于 100 且错误率超过 0.1%严重档 1%用于捕捉物理链路质量问题。接口 DOWNInterface Downsnmp_network_status_admin_status 1 and snmp_network_status_ostatus offset 4m 1 and min_over_time(snmp_network_status_ostatus[3m]) 2即管理状态为 up 但最近 3 分钟运行状态持续为 down 时告警并带 4 分钟 offset 避免刚 down 又 up的抖动误报。Network Device Health.json 则提供了设备可用性告警SNMP 探测失败设备在线max_over_time(snmp_icmp_up{}[3m]) 1 and max_over_time(snmp_up{}[3m]) 0—— 设备 ICMP 可达但 SNMP 探测持续失败说明问题出在 SNMP 服务、ACL、UDP 161 或凭据而非设备宕机。SNMP 采集中断曾有数据max_over_time(snmp_up{}[1h]) 1 unless max_over_time(snmp_up{}[10m])—— 过去 1 小时有成功采集但最近 10 分钟无任何snmp_up样本代表采集链路整体中断Agent 离线、配置被移除、网络中断等。6.3 指标字典metrics 目录metrics/categraf-base.json 提供了指标的中英文释义帮助理解各指标语义与取值snmp_interface_admin_statusgauge接口管理状态up(1)启用、down(2)关闭、testing(3)测试模式snmp_interface_ostatus接口运行状态up(1)正常收发、down(2)无法工作、testing(3)测试模式snmp_interface_outgoing_errorscounter接口发送方向的错误累计数snmp_interface_outgoing_ucastpkts接口发送方向的单播包累计数与错误数相除可得到错包率snmp_interface_speed接口最大传输速率单位 bit/s。七、采集频率与部署建议针对 SNMP 采集官方建议部署一个独立的 Categraf来承担网络设备采集任务原因是不同的监控对象往往需要不同的采集频率。例如边缘交换机 5 分钟采集一次即可核心交换机可以配置得更频繁例如 60s 或 120s。注意如果采集过于频繁一些老款交换机可能会被打挂或被限流被限流的结果就是在监控图上看到数据断点gap。因此在配置interval时要结合设备性能和厂商建议做权衡而不是一味追求高频率。八、排错指南要成功通过 Categraf 采集到 SNMP 数据首先要保证Categraf 所在机器能够连通网络设备。可以用snmpget命令先做连通性与凭据验证README 中的方法snmpget -v2c -c public 172.30.15.189 RFC1213-MIB::sysUpTime.0其中-v2c指定 SNMP 版本、-c public指定团体字、RFC1213-MIB::sysUpTime.0指定要读取的 OID。如果这条命令都执行不通需要按顺序排查以下常见原因snmpd 服务未启动在目标设备上确认 SNMP 服务已启用防火墙拦截检查设备 ACL 与中间防火墙是否放行了采集机到设备的 UDP 161 端口命令未安装采集机上缺少 net-snmp 工具包安装后即可凭据错误团体字 / SNMPv3 用户名密码配置不正确可再用snmpwalk做进一步验证。排通连通性后如果数据仍然异常可以对照上文的告警语义定位ICMP 可达但 SNMP 探测失败多为凭据或 ACL 问题曾经有数据但突然中断则优先检查采集 Agent 与采集配置。恢复后要注意历史数据缺口盲区期间不会有告警产生。另外本次实测数据来自真实的 net-snmp agent验证了标准的 CPU、内存、TCP 和接口 OID。需要强调的是Juniper、华为等厂商专用模板虽然可以展示标准 OID 数据但厂商私有的 CPU、内存、风扇、电源、板卡等指标仍必须使用对应型号的 MIB 与真实硬件进行验证这也是第 5 节中厂商私有 OID 配置必须逐型号维护的根本原因。结语从配置 OID 即采集的插件哲学到通用 OID 与厂商私有 OID 的取舍再到 Nightingale 中仪表盘、告警与指标字典的落地Categraf 的 SNMP 插件为网络设备监控提供了一条低门槛、高灵活的路径。实践中建议遵循三条主线生产环境使用 SNMPv3 或受控团体字保障安全按设备层级差异化配置采集频率厂商私有指标务必以真实 MIB 和实机验证为准。围绕这些要点仓库 integrations/SNMP 下的采集配置、仪表盘与告警规则都可以作为起点直接复用再结合自身设备型号逐步积累配置资产。【免费下载链接】nightingaleNightingale is to monitoring and alerting what Grafana is to visualization.项目地址: https://gitcode.com/GitHub_Trending/ni/nightingale创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
