简单网络管理协议SNMP（Simple Network Management Protocol）用于网络设备的管理。网络设备种类多种多样、不同厂商提供的管理接口（如命令行接口）又不相同，这使得网络管理变得愈发复杂。为解决这一问题，SNMP应运而生。SNMP作为广泛应用于TCP/IP网络的标准网络管理协议，提供了统一的接口，从而实现了不同种类和厂商的网络设备之间的统一管理。通过SNMP数据的监测数据，用户可以及时关注到网络设备的状态和异常变化。
SNMP 简介
随着网络技术飞速发展，网络设备数量成几何级数增加，使得网络管理员对设备的管理变得越来越困难；同时，网络作为复杂的分布式系统，其覆盖地域不断扩大，也使得对这些设备进行实时监控和故障排查变得极为困难。网络设备种类多种多样，不同设备厂商提供的管理接口（如命令行接口）各不相同，这使得网络管理变得愈发复杂。
为了应对这一场景，SNMP应用而生。作为广泛应用于TCP/IP网络的网络管理标准协议，SNMP支持网络管理系统，以监测连接到网络上的设备是否有需要运维关注的情况。同时，SNMP采用轮询机制，提供最基本的功能集，适合小型、快速、低价格的环境使用，而且SNMP以用户数据报协议（UDP）报文为承载，因而受到绝大多数设备的支持，同时保证管理信息在任意两点传送，便于管理员在网络上的任何节点检索信息，进行故障排查。
随着技术演进，SNMP协议相继衍生出三个版本：SNMPv1、SNMPv2c和SNMPv3。
- SNMPv1
作为SNMP协议的最初版本，提供最小限度的网络管理功能。SNMPv1基于团体名认证，安全性较差，且返回报文的错误码也较少。
- SNMPv2c
采用团体名（community）认证，在SNMPv1版本的基础上引入了GetBulk和Inform操作，支持更多的标准错误码信息，支持更多的数据类型（Counter64、Counter32）。
- SNMPv3
在安全性方面进行增强，提供了基于USM（User Security Module）的认证加密和基于VACM（View-based Access Control Model）的访问控制。SNMPv3版本支持的操作和SNMPv2c版本支持的操作一样。
目前，v1版本使用较少，一般使用v2c版本，如果对安全认证有需求，可以使用v3版本。
SNMP系统组成
SNMP基本组件包括网络管理系统NMS（Network Management System）、代理进程（Agent）、被管对象（Managed Object）和管理信息库MIB（Management Information Base）。如图所示他们共同构成SNMP的管理模型，在SNMP的体系结构中都起着至关重要的作用。
- NMS
Network Management System，网络管理系统，一般是各种网管软件，可以向agent查询/修改各种信息，也可以接受agent的主动推送，在我们的场景中，就是snmp exporter，仅对agent做信息查询。
- Agent
被管理设备上的一个代理进程，收集被管理设备的信息并汇报给NMS。
- MIB
Management Information Base，是一个数据库，列出了被管理设备可以提供的各项数据，每项数据都对应一个唯一的OID。
- Device
设备，实际的网络设备，包括交换机、路由器、防火墙、UPS、AP、软路由等等，只要支持SNMP，都可以视为一个网络设备。
- Managed Object
被管理对象，一个设备包含至少一个被管理对象，可能是设备本身，也可能是某个硬件（一个网口），也可能是一些参数合集。
- OID
Object ID，对象标识符，用于定位一个数据项。OID是一串数字，比如1.3.6.1.2.1.1表示system，数字是树形结构，左侧为根，右侧为叶，前面一截是由IANA分配的厂商标识符，后面就是各个厂商自定的，所以不同厂商设备的OID树差别很大。OID树结构参见下图。
- MODULE
因为SNMP可以监控的设备和厂商多种多样，所以SNMP exporter中划分了很多module，比如网络设备的if_mib，软路由的ddwrt，paloalto_fw防火墙等等，一共有十几种，最常用的就是if_mib。
SNMP Exporter
SNMP协议中用不同的OID区分不同的状态数据，所以OID非常类似于Prometheus中的指标的概念，SNMP Exporter通过从Agent查询指定的OID数据，同时将数据映射到可读的指标上，实现SNMP数据到Prometheus指标的转换。SNMP Exporter就默认提供了非常丰富的转换配置，大部分场景下用户无需额外配置即可将OID转换为可读的指标数据。
SNMP Metric 监控参考模型
SNMP Metrics采集
SNMP 可以帮助运维人员以极为简单而有效的方式管理网络。首先，SNMP 帮助运维人员收集网络上不同设备带宽使用量的信息。在进行故障排除的同时，更加快速找出网络性能趋势或问题。SNMP采集到的数据都是来自设备提供，不同厂商的设备可以提供的数据不尽一致，SNMP Exporter尽可能多的提供兼容，默认配置中已经包含了常见的各个厂商的OID映射，涵盖了市面上主要的厂家及其网络产品，能够满足绝大多数场景需求，详见Prometheus开源社区的相关文档。在当前版本中，我们支持if_mibmodule的指标数据采集，更多module支持将根据需求情况陆续开放。
文档链接：
https://github.com/prometheus/snmp_exporter/blob/main/snmp.ym
这里我们常见的以思科16口交换机为例，主要指标包括：
SNMP监控大盘
我们默认提供了SNMP Status和SNMP Interface Detail两个大盘，主要针对if_mib场景，监控网络流量等信息。
SNMP Status
主要展示设备的总体状态，包括设备运行时长，当前的流入/流出流量、出入流量总计、各个端口的的实时流量信息、流量变化趋势等。
SNMP Interface Detail
展示各个端口工作详情。包括端口状态、端口是否连接、端口速率、MTU配置等，以及各种流量（单播/组播/多播等）的速率/包数量变化情况。
需要注意的是，SNMP Interface Detail大盘使用前，需要在Variable 中配置需要查看的DataSource。
SNMP告警规则
参考前面对各项主要指标的介绍，针对SNMP可以配置一下告警项：
- Interface Throughput 达到 speed 的 80%
- 出/入方向的丢包/Error数大于阈值
- 出方向的Queue长度大于阈值
- interface 数量变化
使用阿里云 Prometheus 监控 SNMP
安装SNMP监控在Prometheus for 容器服务实例中，SNMP已经默认在集成中心中展示，用户可以在arms控制台 -- 实例详情页 -- 集成中心中找到入口。
点击SNMP图标，可以看到常见的指标列表和大盘缩略图，需要说明的是，由于OID/MIB的复杂性，列出的只是一部分常见的指标信息。
点击+安装可以接入SNMP监控，您只需要填写exporter 名称和设备IP地址，即可快速拉起一个SNMP exporter。其中的采集路径和采集间隔，一般无需修改，保持默认值即可。配置如下图：
点击确定后，会在您的ack集群中，arms-prom namespace下，新增一个名为snmp-exporter-snmp-test-1的deployment，并自动完成采集job的配置。此时您可以在arms控制台 -- 实例详情页 -- 服务发现 -- Target中看到新配置的采集job。同时也可以点击集成中心 -- SNMP图标 快速浏览相关的Target/指标/大盘/告警/服务发现/Exporter等信息。
查看大盘
如果您需要查看SNMP相关大盘，可以从arms控制台 -- 实例详情页 -- 大盘列表中点选snmp_exporter快速列出相关大盘，或者从集成中心中，点击SNMP图标，点击大盘标签页，也可以找到对应的dashboard。
配置告警
当您在集成中心安装SNMP监控时，已经默认增加了snmp_exporter告警分组的相关规则，但未启用，您只需要简单修改参数并确认启用即可。
可以从arms控制台 -- 实例详情页 -- 告警规则 -- 创建告警规则中进入规则新增页面，在其中告警分组选择snmp_exporter告警值班并选择您需要启用的告警规则，确认参数阈值并保存，即可完成告警规则的创建。
SNMP指标未采集的排查方法
SNMP Exporter本身的主要工作是指标映射，一般都能稳定运行，但SNMP指标一般都会涉及到网络设备，出现网络问题的概率较高。如果出现指标采集不到的问题，可以参考如下的排查思路。
- 检查Prometheus Target状态，如果Target显示为Unhealthy状态，请排查snmp-exporterpod运行状态；如果Target状态正常，继续下一步。
- 查看snmp-exporterPOD 日志，确认日志中是否有报错信息，如果是网络问题都会在日志中有明确体现，可以根据报错指导排查。
- 如果日志中没有异常，同时只是某个SNMP指标缺失，其他SNMP指标能正常收集到，较大概率是因为设备确实没有这个指标，我们可以使用snmpwalk工具协助排查确认。
- SNMP Exporter能采集到的数据，都可以通过snmpwalk获取到，很多Linux发行版默认不包含snmpwalk，需要先安装net-snmp-utils这个包。
- 在能连接到SNMP设备的机器上，使用snmpwalk获取设备原始数据。
- 如果snmpwalk依然未能获取到数据，需要向设备厂商确认是否提供此数据。
自建 Prometheus 与阿里云 Prometheus 监控的优劣对比
Prometheus作为目前最主流的可观测开源项目之一，已经被众多企业所广泛应用。但在实际生产过程中，还是遇到各种各样问题，其中包括：
- 由于安全、组织管理等因素，用户业务通常部署在多个相互隔离的 VPC，需要在多个 VPC 内都重复、独立部署 Prometheus，导致部署和运维成本高。
- 每套完整的自建观测系统都需要安装并配置 Prometheus、Grafana、AlertManager 等组件，部署过程复杂、实施周期长，并且每次升级都需要对每个组件进行维护。
- 随着监控规模不断扩大，资源消耗呈非线性快速增加，系统可用性无法得到保障。
- 对于相关组件，自建 Prometheus 无法实现一站式、全局视角的监控建设。
- 开源分享的相关大盘不够专业，却少开箱即用的丰富指标，不能帮助用户更迅速的的了解网关的整体运行状况。
针对以上问题，阿里云Proemtheus监控进行了以下几个方面的优化：
一、性能强化&降低资源消耗，压降IT运维成本
为了进一步进行性能优化，阿里云Prometheus监控将Agent 部署在用户侧，保留原生采集能力同时， 尽量使用最少资源；通过采集存储分离架构，提高整体性能；采集组件优化，提升单副本采集能力，降低资源消耗；通过多副本横向扩展均衡分解采集任务，实现动态扩缩，解决开源水平扩展问题。采集/数据处理/存储组件支持多副版本，保证核心数据链路高可用；基于集群规模可直接进行弹性扩容；支持数据重传，彻底解决丢弃逻辑弊病，确保数据完整性与准确性。
同时，为了应对大规模数据、长时间区间的查询场景，通过DAG执行优化、算子下推，提升大规模数据查询性能并支持长时间区间秒级查询；通过Global DataSource和Global View实现对多集群统一监控与跨集群聚合查询。在提供企业级能力强化同时，全方位降低企业使用Prometheus的IT运维成本。通过包年包月、按量付费等多种计费方式让费用支出与规划更加清晰与灵活，相较于开源版本节省37%以上。
二、与阿里云主流云服务深度集成
云产品在各自控制台都提供自身产品的可观测性，但这些云产品的指标及看板散落在各控制台，且无法进行精细化的指标数据应用。Prometheus服务提供云产品监控功能，将这些数据进行统一展现、查询、告警，为运维团队提供更加便捷的日常运维监控界面。
三、Grafana看板增强，让云服务监控更简单
想要更好、更快速的呈现相关指标图表，阿里云Prometheus监控预置Grafana组件，预置常见云服务、应用等看板模板，如应用实时监控服务ARMS、云监控CMS、日志服务SLS、阿里云Elasticsearch等云服务，提供各种云服务的数据源配置及预置大盘，实现各种可观测数据的统一展示。如容器、消息队列Kafka等，进一步提供GrafanaPro大盘，帮助运维进行更加精细化的指标观测。在预置看板之外，可以通过Grafana官方自由增加新插件，添加新的可视化模板以及数据源，进一步满足个性化运维监控需求。
结语
阿里云Prometheus与阿里云容器服务无缝集成，提供了SNMP设备的指标采集、用户大盘、告警规则等项目的一键集成，用户免运维，开箱即用，目前SNMP指标采集功能仍在不断演进中，欢迎大家试用和提出改进意见。
