Introduction
Over the past several weeks, I’ve been hard at work on some new SNMP management packs for Operations Manager 2007 R2, to replace the Cisco SNMP MP and extend similar functionality to a wide range of SNMP-enabled devices. In the next few posts, I hope to describe some of the design and development considerations related to these Management Packs, which I am calling the xSNMP Management Pack Suite. For this post, I hope to give a basic overview of the development effort and resulting management packs.
As I was working on some feature enhancements to the Cisco SNMP Management Pack, and following some really great discussions with others on potential improvements, I concluded that a more efficient and effective design could be realized by aligning the management pack structure along the lines of the SNMP standard itself. To expound on this point, much of the monitoring in the Cisco MP is not specific to Cisco devices, but rather, mostly common to all SNMP devices. The SNMP standard defines a hierarchical set of standard MIBs, and a hierarchical implementation of vendor-specific MIBS, with consideration to the elimination of redundancy. I tried to loosely adapt this model in the xSNMP MP architecture. The first of the MP’s, and the one that all of the others depend on, is the root xSNMP Management Pack. This management pack has a few functions:
- It performs the base discovery of SNMP devices (the discovery is targeted to the SNMP Network Device class)
- It implements monitoring of the SNMP v1/v2 objects for discovered devices and interfaces
- It provides a set of standardized and reusable data sources for use in dependent management packs
From there, the remaining management packs implement vendor-specific monitoring. Devices and/or interfaces are discovered for the vendor-specific management packs as derived objects from the xSNMP MP, and most of the discoveries, monitors, and rules utilize the common data sources from the xSNMP MP, which makes the initial and ongoing development for vendor-specific MP’s much more efficient.
Controlling Interface Monitoring
One of the topics frequently commented on with the Cisco SNMP Management Pack, and a subject of much deliberation, was that of selecting network interfaces for monitoring. Even determining the optimal default interface monitoring behavior (disabled vs. enabled) isn’t a terribly easy decision. For example, a core network switch in a datacenter may require that nearly all interfaces are monitored, while a user distribution switch may just require some uplink ports to be monitored. In the end, I decided on an approach that seems to work quite well. In the xSNMP Management Pack, all interface monitoring is disabled by default. A second, unsealed management pack, is also provided and includes groups to control interface monitoring (e.g. Fully Monitored, Not Monitored, Status Only Monitored). Overrides are pre-configured in this MP to enable/disable the appropriate interface rules and monitors for these groups. So, to enable interface monitoring for all Ethernet interfaces, a dynamic group membership rule can be configured to include objects based with interface type 6, or if critical interfaces are consistently labeled on switches with an Alias, the Interface Alias can be used in rules for group population.
Organizing Hosted Objects
For each of the management packs, I tried to take a standardized approach for hierarchical organization of hosted objects and their relationships. This organization was facilitated primarily through the use of arbitrary classes to contain child objects. So, rather than discover all interfaces of a device with a single hosting relationship to the parent, an intermediary logical class (named “Interfaces”) is discovered with parent and child hosting relationships. This approach has three primary benefits: 1) the graphical Diagram View is easier to navigate, 2) the object hierarchy is more neatly organized for devices that may be monitored by multiple MP’s (e.g. a server monitored by three MP’s for SNMP hardware monitoring, O/S monitoring, and application monitoring), and 3) the organization of hosted objects is consistent, even for devices with multiple entities exposed through a single SNMP agent.
Scalability
With loads of invaluable help from some volunteer beta testers, a great deal of time has been spent testing and investigating performance and scalability for these management packs. While I will save many of these details for a later post, I can offer a few comments on the topic. In all but the smallest SNMP-monitoring environments, it’s highly advisable to configure SNMP devices to be monitored by a node other than the RMS. For larger environments, one or more dedicated Management Servers or Agent Proxies (Operations Manager agents configured to proxy requests for SNMP devices) are preferred for optimal performance. From our testing with these Management Packs, a dedicated agent proxy can be expected to effectively monitor between 1500-3500 objects, depending on the number of monitors/rules, the intervals configured, and the processing power of the agent proxy. By object, I am referring to any discovered object that is monitored by SNMP modules, such as devices, interfaces, fans, file systems, power supplies, etc. So, monitoring a switch infrastructure with 4000-6000 monitored network interfaces should be doable with two dedicated agent proxy systems.
I intend to write in greater detail about these topics in the coming weeks, and hope to post the first public beta version of these management packs soon.
Operating-Quadrant 