# Chapter 4

| # Introduction to Modules

> This chapter covers the following topics:

- Modules Definition--page 27
- How to Load Modules--page 28
- Basic Module Building Concepts--page 28
- Types of Modules--page 28
- Module Naming--page 29

> As discussed before the Sun Management Center agents use SNMP to communicate with the server program. The agent provides a managed set of data for the user to view in the console. The data in the agent is maintained in terms of data sets called modules. The following sections define and explain how you can load and unload modules in Sun Management Center.

## Modules Definition

> A module is an encapsulated set of monitoring functions that focus on a particular aspect of system or application health and performance. Typical examples include database modules as Oracle® or Sybase, operating system modules as Solaris or SunOS environments, or device modules as Hewlett-Packard printer.

> Sun Management Center agents can dynamically load and unload modules. The monitoring functions of a loaded module can also be disabled when not required. These functions are performed by an end user through the Sun Management Center console.

> Implementation of modules are discussed in the chapters that follow this one.

## How to Load Modules

> When the Sun Management Center agent is installed on a system, it is configured to load some default modules. Using the Sun Management Center console application, the user can load additional modules into the agent or unload existing modules from the agent. The agent is shipped with various modules that manage data that is diverse in nature. For the list of the modules shipped with agent, see the Sun Management Center User's Guide.

> Once the agent is installed, it is configured to load a default set of modules, for example, MIB-II, standard host system monitoring, and so forth. Additional modules can be loaded from the Sun Management Center console once the agent is running. By convention, modules loaded from the console are made persistent so that the modules are automatically reloaded should the agent be restarted. Modules can also be unloaded and disabled from the console.

## Basic Module Building Concepts

> Since Sun Management Center agents are based on TOE technology, many of the module definition files are in module configuration file format. Module configuration files can be thought of as ASCII configuration files. TOE and module configuration file concepts are discussed in depth in the "Agent Development" and "TOE Objects" sections in the Appendix A.

## Types of Modules

> Modules are classified into the following types:

- Hardware modules manage hardware for the host on which the agent is running, for example, boards, SIMMs.
- Operating system modules manage operating system entities for the host on which the agent is running, for example, swap, CPU usage.
- Local application modules manage entities associated with the host on which the agent is running, but which do not fall into the Hardware or Operating System module categories, for example, file scanning, process monitoring.
- Remote modules are capable of managing entities on remote hosts, for example, Sybase, Oracle, Topology, remote devices.

## Module Naming

> Module naming is the process of selecting a unique name for the module. This name distinguishes the module from other modules and is used in naming the module definition files.

### Module Names and Subspecs

> Each module must be assigned a module name and can have an optional subspec. The module name and subspec, if specified, must uniquely identify the module.

> The subspec qualifier is optional. When specified, its purpose is to group together related modules.

> For example, consider the Solaris operating environment management module. Solaris monitoring can be implemented as a single module. In that case, the module can be named simply solaris (with no subspec). Alternatively, Solaris monitoring might be implemented as a group of separate modules (one for network monitoring, one for resource loading, one for filesystems, and so forth). Such modules can be named with subspecs. For example:

>     solaris-network
>     solaris-filesystems
>     solaris-loading

> The simplified version of the Solaris module, which is used as an example in this document, is assigned the name solaris-example. The subspec example differentiates this module from the standard Solaris module.

> There are no performance or processing considerations when deciding whether to use a subspec as part of the module name. The subspec is largely a convenience tool to assist in keeping module files organized.

> Agents that contain the modules communicate to the server using SNMP.

> SNMP, MIB, OID are discussed in "Parameters Specification" in Chapter 5.

### SNMP & Modules

> SNMP (Simple Network Management Protocol) is the defacto standard for network based management. SNMP is simple, low bandwidth and elegant way of managing across networked entities. SNMP uses UDP (User Datagram Protocol) for communication. SNMP uses the MIB (management information base) for data modeling. The MIB defines the data organization. The data items are addressed by OID (Object IDentifier) within the MIB.

> Since the Sun Management Center agent uses SNMP to communicate with the external entities like Sun Management Center server, the data items in the modules have corresponding OIDs. However, you can ignore this relation of data items and OIDS, if SNMP is not of primary interest to you. If you are a module developer and are interested in SNMP modeling of your module data, refer to the section, "Using the mib2x Tool", in Chapter 10, and section, "To Generate SNMP MIB From a Module", in Chapter 11.

Copyright © 2000 Sun Microsystems, Inc. All Rights Reserved.