1. Install Job Managers on Mission Critical boxes
2. Install Job Agents on others
3. Designate an Enterprise Job Manager for top-level processing
4. Don't forget the Mainframe
5. As with other "Management points," don't implement workload if you won't need it.

Agents 

There are two methods for monitoring your network resources - through Agent Technology and through remote monitoring (RM). 

In determining which agents to deploy and where, you should ensure that agent selection is based on business requirement rather than agent availability. Refer to the NSM Implementation Guide for more information.

NSM employs many different types of Agents (including the Job Management and Event Agents discussed in the previous sections) but for the purposes of this discussion, we will be focusing on the SNMP Agents which are included under the umbrella of Agent Technology. Agent Technology requires the cooperation of multiple components.   Consider the following diagram:

All components must work together for Agent Technology to perform its function.  Roughly speaking:

• Agents monitor the managed objects (e.g., OS, Log files, MS-Exchange Server, etc.) and, based on policy, forward trap information to the ...
• DSM which converts the trap information to object state information and forwards it to the
• MDB which updates the object's display in
• WorldView, MCC or other UIs

Although all of these components can, technically, be installed on the same machine, you will most likely install on two or more different machines. 

The first question we need to ask is whether we actually need to implement an Agent. Implementing Windows agents on every desktop may be overkill! Implementing Performance Agents on a stand-alone Server or a Workstation may not be required. Only implement those components which serve a stated Business requirement.   Remember, start with the Business Requirement, NOT the technology. Just because we have an Agent doesn't necessarily mean we should implement it.

Agents have policies. These policies let the Agent know what resources or metrics should be examined, and at what level we want to consider a problem to have arisen (commonly known as a "threshold"). When a threshold is met, the Agent will communicate with its manager(s).

Note: An SNMP Agent can have multiple trap destinations (useful for failover).

Hopefully, traps don't occur very frequently. An Agent also generates network traffic when responding to polls from a Manager and this poll traffic is normally much higher than trap traffic. We minimize poll traffic by reducing poll frequency.

Proxies and Remote Monitoring

NSM supports Agents on a wide range of platforms. However, there are platforms where Agents do not exist. These platforms may be critical to the enterprise.  In this case one of the monitoring options is to use a proxy.   Proxies bring the information from the platform into the NSM "domain". For example, Console logs from an HP 3000 machine piped to a managed SOLARIS, or a serial port feed into a Windows machine. Just because we don't have a specific agent doesn't mean we can't manage that object for the client. It has been done many times, and is a fairly easy thing to accomplish.

Another option is to use Resource Monitoring (RM) which utilizes an Admin Interface, a Remote Monitoring Agent and a Data Store.  The Admin Interface is used to configure the monitored resource, to view its state and to present a centralized view of the enterprise through WorldView.  The RM Agents, which are deployed throughout the enterprise and run as a Windows Service, process the data and copy it to the Data Store.  More information on Remote Monitoring is provided in the Implementation Guide. 

Rule of Thumb for Agents

1. Check whether you need an Agent
2. PING may be all you need
3. Make sure you have enough resources to run the Agent
4. Consider dual trap destinations for failover
5. Realize that Policy will change based on time, system load, etc.
6. Do not run the default policies in a Production environment
7. OS Agents can function as high-level application agent
8. Choose the right agent for the task. Keep it simple and light.
9. Ensure you have configsets managed centrally and automatically.

A Word About Policy

Policy is a general term meaning "the rules under which a product operates." Event message actions, Spectrum polling configuration, and Job Management jobs and jobsets are examples of Enterprise management policies. ForwardFSMEvent, Asset Management inventory update scripts and Agent configsets are examples of Manager and Agent policies. If you understand that the long-term maintenance of these policies is a cost and each change has a risk, you will look for ways to make this procedure more efficient and safer/easier. Here we look at methods to most effectively define/maintain/use policy.

For products such as NSM, CMS, Spectrum, "policy" refers to the overall strategy regarding how a resource is monitored in context.  It entails

• what objects will be monitored
• how often objects will be checked
• what events regarding those objects will constitutes a specific state/status
• what to do in response to a specific state/status or change in state/status

Policy can occur at many levels throughout the organization but it is best to :

• define policy as far up the hierarchy as is compatible with your individual administrative model/view
• make decisions as far down the hierarchy as is compatible with your operational view/model (deploy as far down as is practical)
• move as little data as possible across the shortest distance in order to minimize bandwidth usage
• make decisions as close to the data source as possible

DSM Policy

DSM Policy is an extremely powerful tool. It is a programming language that enables a DSM to function completely autonomously even if the connection to the Enterprise Level is lost. Care must be taken when creating or modifying DSM Policy, and all changes should be tested thoroughly in a lab environment. If additional scripts/programs are invoked by the DSM, the resource requirements for the DSM may increase. The ability to invoke external scripts/applications means that the DSM can become a self-contained solution for Regional management.

The ability of the DSM to "remember" history, state, other information, and then relate it to an incoming notification provides many possibilities. Reformatting state-change messages to include additional information for later Event processing is also simple and effective.

As with all policies, DSM policies should be created and maintained centrally, for easier maintenance.

Agent Policy

Installing Agents is quick and easy. Creating Agent policy should NOT be rushed; the creation of a centralized policy should be done carefully, and after much discussion and consultation.

A product implementation normally goes through the following stages:

1. Information collection and consolidation (Agents gcollecting inventory, or trapping and polling)
2. Data transmission/Alert Notification (send inventory delta, Page someone that the Server is down)
3. Active Resolution (Reset the Router, Cut a Trouble Ticket)

False alerts should not be tolerated. This undermines the second and third stages. Getting paged at 2:00am for a false alarm or something trivial is not going to go down too well !

To make sure that this doesn't happen, we must make sure that our policy definitions reflect your business requirements. If the C-drive becomes 80% full is that a critical state or just worthy of a warning, etc. Should we really care about physical memory on a Windows Server being at 95%, or should we look at committed memory. These are policy decisions, and they must be set wisely. Simply installing the agent, and using the default policy is not acceptable!

Multiple sets of Policy are almost always required. For example, during the day a server is providing real-time information, and needs enough spare capacity to handle ad-hoc requests. Overnight, it is running backups, and we want it to process as fast as possible. One policy will not be good enough to alert us. So, time of day policy changes should be considered normal. In fact, it is abnormal not to change policy based on the time, or the workload currently running.

One Policy/Many Policies

For long term maintenance of policies it makes a lot of sense to have central management of the policies. This can be easily accomplished. CA solutions make centralized management possible, both for management of client applications and devices, and also for enterprise management itself. Whether a general policy for an agent is created and distributed, the appropriate configuration loaded locally; or multiple policies/configsets are created, it should be done centrally wherever possible.

Standardization

In order to allow for easy growth, you should consider using a phased, tiered approach to architecture and standardize policy definitions wherever possible. It cannot be stressed enough that the majority of effort expended in an implementation is the creation of policy. Anything you can do to ease this requirement will pay big dividends, not only in the implementation phase of the project, but also in future maintenance.

Standardization applies not only to product policies, but also to naming conventions, etc.

Guidelines for Policy

1. Maintain Policy Centrally
2. Standardize wherever you can
3. Document the reasons for the Policy
4. Use generic policies where possible
5. Secure the policies against unauthorized change
6. Always backup policy prior to changes
7. Generic policy is extremely powerful. Test in Lab.

Now that you understand the current environment, the business needs behind the implementation and have a clearer understanding of the basic product architecture, it is time to begin designing your architecture.