到目前为止，我们探讨了什么是网络管理，以及有哪些管理标准或协议等。不过还没有清晰地界定网络管理中的对象，也就是网络管理所作用的对象、实体及组成。在这里不准备将涉及的人包括在内，而仅介绍网络管理中直接作用的对象。
在网络管理的术语里其组成包括以下几个对象：网络管理者、管理系统、管理进程、管理者（Manager）、被管理者/代理（Agent）、管理信息库（MIB，Management Information Base）、网络管理协议。下面介绍其中几个重点对象。
1.网络管理者
我们知道网络管理者理应是一个庞大的计算机系统。不过在实际的开发或维护过程中，往往会使用简化的工具来完成设备的测试和调试。比如会使用工具软件、命令行等方式作为控制台，这在本书的后续章节中会涉及，读者可以把它们理解成简化的、模拟的网络管理者。
2.被管理者/代理
把被管理设备称为网络设备，或称为网元（Element Management），比如一台联网的嵌入式设备（如路由器），这只是一种概念性的描述，可以从不同的上下文或层次去理解以上的含义；代理常常表示一个网络实体，在一些环境下直接对应一台被管理的物理设备，在其他的上下文语境中可以理解为一个运行的进程（程序实体），比如snmpd的后台进程。
换一种角度分析，我们也可以把网元中实际运行的代理进程称为网元接口。该接口允许管理者发送请求到该网元，如获取代理的某些状态量；网元也可以发送信息给管理者，如在发生预定义事件时（如电压超过阈值），向管理者通告该事件的发生以反映某种状态的变化。
虽然两者可以互相发送信息，但是两者的角色还是有很大差别的，它们是一种不对称的关系。也就是说，如果从网络链接模式来区分管理者和代理的话，两者可对应为C/S（Client/Server，客户端/服务器）结构。代理，在常规思维的理解上反而成了“服务器”，管理者沦为“客户端”。因为代理也确实可以响应多个管理者（尽管不一定支持并发——代理多线程）另外需要注意的是，一般情况下管理者和代理之间的角色不会互换，不过它们之间是一种相对的关系，而不是绝对的关系。
一个代理在某些情况下，对应一个网元，它作为某个管理者代理的同时也作为另外一个网元的管理者。
一个管理者在某个管理层中除了作为一个“真正”的管理者外，还可以作为更高管理层的代理，诸如收集、处理、转发信息到上层管理者。这与人类的社会管理结构是相似的。这种角色或者功能，在SNMP协议及后续章节要介绍的Net-SNMP中都已经实现了。
下面介绍在代理中到底如何实现Proxy（代理角色）的功能的。首先，了解在代理中是如何表示现实世界中要管理的内容的。
3.管理对象
从直观的物理层面上来理解，管理内容又可称为被管理对象。举个简单的例子，假设有一台联网设备是基站供电系统，该系统的核心是一块ARM嵌入式芯片，该芯片上运行着很多的进程（程序），其中包括一个网络管理的代理进程。假设需要管理的内容有以下几项：
该系统的用电状态包括：市电、电池、太阳能发电、风能发电、油机发电等；
该系统中相关的传感器用于检测当前系统的电压、电流、温度、湿度等；
被定义为告警事件的情形：例如在系统运行过程中出现的市电停电、电池被过度使用等。
当然该系统还有大量的其他信息，如系统参数等，这里就不一一列出了。
在真正的管理之前，需要确定如何描述以上三种被管理对象的物理特性。在实际的代理进程中，用电状态可以使用C语言中的枚举类型表示；电压、电流、温度、湿度等都可以使用double型的变量表示（或者使用整型变量和精度共同表示浮点型变量）；如果有多组电池，则使用相应的数组表示即可；告警事件可以使用一个短整型变量表示（比如，1表示有告警）。
假设我们已经实现了上述的代理进程，那么又该如何告知管理者有这些被管理对象，以便管理者对其进行管理呢？
解决的方法是和管理者约定好，以某种格式和语言定义以上的被管理对象，并将定义好的内容，以某种方式存于告知管理者。管理者在系统启动时或需要时，读取管理对象，在必要时对以上的被管理对象进行管理。
在网络管理系统中，以上的约定常由管理信息库MIB来实现（还存在XML格式或指令格式CLI）。管理者通过MIB对代理进行获取或设置会对应到真实的物理对象上，因此也可以把MIB看成是管理设备的一种“接口”。
既然有库的概念，那么可以将MIB类比为虚拟的静态数据库。不过有两点需要注意：首先它不是真正的数据库，只是一个纯文本文件（ASCII文件），包含了该设备可被管理的对象，与该设备相关联；其次，该MIB文件不会变动，它是一种标准，一旦发布到现实的网络世界里，除非设备的管理信息有升级、更新，否则一旦发布，跟随设备的MIB就固定下来了。
通过以上对被管理信息的规定，实现了被管理对象从现实世界到虚拟世界的抽象。一个被管理对象在MIB中为一个条目，多个被管理对象映射的集合组成了一个MIB（第4章还会进一步介绍MIB——SNMP中的MIB概念）。这里需要提醒读者的是，MIB并不是SNMP中特有的概念，虽然提到MIB就会想到SNMP，那只不过是因为SNMP使用广泛罢了。MIB作为物理设备管理信息的一般概念性的描述，是通过Agent实现的，不同协议的Agent所支持或实现的MIB在定义格式上不一定一致，这种不一致表现为约定上的不一致或表达方式的不一致。
以上对管理者、代理、管理信息库（MIB）的描述可以用图释之，如图1-3所示，网络设备由传感器采样电压、电流，分别以volt，current表示，并通过MIB告知管理者。
具体的MIB定义，请参考后续章节的内容。
4.网络管理协议
当代理已经明确可支持的管理对象，同时管理者已经知道待监控的对象后，下一步当然就是两者如何“联络”以完成对对象的管理。在网络管理中，网络是互相通信的前提，管理者和代理的通信过程通过网络来承载，如何理解对方通过网络传过来的“语言”，是最为关键的一步。网络中传输二进制流，二进制数字10可以理解成十进制数字的2，可以理解成具体的数值电压2伏，还可以理解成某个数据类型的标志，以及某个命令控制字等。
相应的解决方案就是针对具体的网络管理协议，定义“语法”“语义”“时序”，即数据和控制信息结构、格式的语法、如何响应或控制的语义、对语义响应顺序的时序。
在运行多种网络协议（不仅仅是SNMP）的计算机系统中，每个通过网络传入的协议数据流又是如何被管理的上层应用所识别的呢？答案就是端口，一个端口号和一个IP地址的组合即是网络编程中常说的网络套接字，往往某种具体的协议都被绑定在指定的网络端口上。对于网络通用协议，一般使用的是知名端口，并且在实现时一般不允许更改，否则会导致通信失败。比如，常见的有FTP使用的20和21端口、SSH使用的22号端口、HTTP使用的80端口。在SNMP中使用161作为监听端口，162作为Trap端口，虽然这两个端口我们可以进行配置，但不建议更改。如果以上端口被防火墙关闭，绑定在以上端口的协议（程序）是无法正常运行的，很明显网络管理是典型的分布式应用。
