在阅读完SNMP之后，我们可以将代理angular色理解为设备的SNMP服务（与SQL一样，它是存储的API）。
当您执行SQL查询时，SQL引擎将完成所有工作并返回结果 – 您不需要知道存储和存储位置。
但是MIB不是实际的存储，所以我的代理的angular色是什么？
如果代理只注册MIB，就像我在本教程中所遵循的一样，所以它不作为处理程序使用，这意味着有一个pyhiscal存储，您可以设置并在不绕过处理程序的情况下到达那里。 在教程中，你所做的是：
netsnmp_register_int_instance("my example int variable", my_registration_oid, OID_LENGTH(my_registration_oid), &example1, NULL); 没有必要在处理程序来处理调用。
假设我想要监视我的应用程序的待处理请求队列，所以我想要一个代理程序，所有对application_pending_request的SNMP请求都会被触发，它将返回队列深度。 当我需要轮询我的应用程序队列以获得结果时，为什么我需要有一个实际的MIB？
您对SNMP的工作原理有一个根本性的误解。 快速和肮脏的比较： SNMP MIB是相同的主机名 。 例如，MIB将OID映射为友好的名称
.1.3.6.1.2.1.1.1.0 => SNMPv2-MIB::sysDescr.0 => Host Description （uname输出）。
为了从SNMP服务器（代理）检索信息， 必须在特定的OID处发布信息。
为了使SNMP守护进程发布信息，需要（通常）两件事情：
为了检索信息，您必须知道OID – 它可以是SNMP 客户端上的MIB文件中的数字OID或“友好”名称。
SNMP“浏览器”通常需要一个MIB文件，因为没有一个它们可以呈现给你的是一个没有意义的数字列表。
所以你的问题的答案是“你不需要MIB文件，它只是帮助需要与SNMP交互的人”。
以您的示例（报告队列长度）为例，听起来您喜欢使用net-snmp （UCD-SNMP）的教程。
net-snmp包含内置的设备，通过手册页和示例configuration文件（特别注意用于运行外部脚本的exec指令：通常你会运行一个脚本来打印队列长度，在您的监控软件/ SNMP客户端中查询OID）