The Service Control Manager, or Agent Technology Services Manager, shows the status of each DSM component. It starts and stops all Agent Technology components and agents on a node in the correct order. Once this component is running, all other DSM components can be installed, started, stopped, or uninstalled.
Note: This executable is the only Agent Technology process that is installed as a Windows service.
You can access Service Control Manager using one of the following methods:
The Service Control Manager dialog appears.
For more information about how to start and stop awservices from the command line, see awservices--Service Control Manager in the online CA Reference.
The SNMP Administrator checks the community string and Internet Protocol (IP) address of get, get-next, and set requests to ensure that these requests come from authenticated management applications. This component forwards trap messages to the appropriate destinations. The SNMP Administrator also stores configuration sets and MIB definitions for each agent on the node in memory.
While the DSM is discovering the monitored systems in its domain, the DSM registers its own IP address with each system's SNMP Administrator. At that point, each monitored system knows which DSM to send traps to. Consequently, those remote monitored systems do not require individual configuration for trap destinations.
Note: For fail-over purposes, a monitored system should have more than one trap destination.
Access the SNMP Administrator by right-clicking the AWsadmin object in Node View and selecting View Agent from the pop-up menu.
The SNMP Administrator View - Summary dialog appears.
This section describes the benefits of configuration sets, how to create and load a configuration set, and methods of distributing the configuration sets.
If you change the configuration of an agent during runtime through an application such as Agent View, those changes take effect immediately and remain in force until the attribute values are reset. If you stop and restart the agent with no configuration set in use, your runtime changes persist. However, if you start the agent with a configuration set read from the SNMP Administrator Store, changes made online during the agent's last execution are not restored. Therefore, using a configuration set for similar managed nodes ensures that the managed nodes are being monitored according to your defined policy.
When you implement a custom agent policy, you need to do so in a documented, controlled, consistent, repeatable, and efficient manner. The agent configuration set (configset) provides this capability. It allows you to export an agent policy to a text file. You can then distribute the policy in a manner that ensures the policy is uniform across the enterprise.
Configuration sets let you set the initial values for the agent's MIB attributes (including threshold values), call-back references, community definitions, and trap destinations, and load these values into the SNMP Administrator store. When a configuration set is specified during the startup of the agent, information about the resources being monitored is taken from the SNMP Administrator store.
When an agent configset is initially created, it is saved to a file referred to as an agent configuration file. The recommended location to maintain agent configuration files is in the folder located at \ccs\at\agents\config. There is no fixed naming standard for these files; your organization can establish its own naming standard.
Note: Though not required, it is a good business practice to keep agent configuration files in the \ccs\at\agents\config directory or a similar central location.
You write a configset using a prescribed syntax, typically taking advantage of the mkconfig utility. Therefore, detailed knowledge of the syntax is not necessary. If you do need to create or significantly modify a configset, information about configset syntax can be found in the guide Inside Systems Management.
You can create agent configuration files using the mkconfig (mkconfig.exe) utility. Mkconfig retrieves an agent's current configuration information from its MIB and delivers its output in configset format to a specified configuration file or STDOUT. All configuration files created with the mkconfig utility have a single configset, which is assigned an internal name bootstrap.
An example of the mkconfig command follows:
mkconfig caiW2kOs@NSMSrvr5 > caiW2kOs.cfg
Some important challenges with agents are the initial configuration and the ongoing configuration adjustment. The Adaptive Configuration service for the UNIX Operating System Agent, the Windows System Agent, and the Active Directory Services Agent supports these areas with the following services:
After startup the Adaptive Configuration service provides a predefined configuration. If the predefined configuration does not match your specific applications you can customize the service to meet your needs. You can influence the Adaptive Configuration service, for example, by specifying threshold policies or including or excluding specific resources.
By default the Adaptive Configuration service is installed along with the Active Directory Services Agent, the UNIX System Agent, and the Windows System Agent. The Log Agent partially supports the Adaptive Configuration service. The Adaptive Configuration service moves through the following modes:
Rapid and automatic configuration of an agent when it is first deployed to its target environment with no other form of a predefined configuration. Duration: about 3 minutes
Ongoing refinement and adjustment of an agent's existing configuration. In this mode of operation, the Adaptive Configuration process provides an ongoing learning and training exercise conducted over a number of weeks or months.
You can access Adaptive Configuration through the Unicenter Configuration Manager, which is described in a subsequent section.
See the guide Inside Systems Monitoring for more information about running the Adaptive Configuration service on a specific host.
Agent configuration files are loaded into the sadmin store using the ldconfig (ldconfig.exe) utility. Ldconfig can load a configset into a local or remote sadmin store. It can also remove a configset from a local or remote sadmin store.
The -h <host> parameter is used to specify the remote node if the ldconfig remote load capability is used. Ldconfig connects to the remote DSM and loads the configset into sadmin store using the SNMP Administrator. The agentctrl command can be used to verify that the configset exists in the sadmin store.
An example of the ldconfig command is as follows:
ldconfig -h NSMSrvr5 caiW2kOs.cfg
You can use the ldconfig -h <host> parameter to distribute agent configsets, either individually or in batch mode. A better approach to applying a configset to many similar servers is to use a software delivery based solution. Configuration files are usually distributed to the folder \ccs\at\agents\config of specified managed nodes.
Central configuration is provided by the Unicenter Configuration Manager. From Unicenter Configuration Manager you can create, modify, and distribute agent configurations in your enterprise. Within Unicenter Configuration Manager, agent configsets and Adaptive Configuration profiles become agent profiles and are deployed to remote hosts within configuration bundles. You should also use Unicenter Configuration Manager to centrally distribute other files that configure your environment, such as atservices.ini, atmanager.ini, aws_sadmin.cfg, or aws_sadminV3.cfg.
For more information about Unicenter Configuration Manager, see the section Understanding Configuration Manager.
DSM Configuration is a tool that lets you visually configure your DSMs to manage their domain environment (their scope).
You want to be able to configure what each DSM is monitoring and how often the DSM communicates with your devices in order to proactively keep all your systems running smoothly with the least number of problems or downtime.
DSM settings that in previous versions could be modified only within files on each remote DSM are now accessible from the following two interfaces:
You can decrease the work required of your DSMs, and therefore make them work more efficiently, if you specify only the classes and IP addresses you know reside within your enterprise and if you fine tune the pollset values and the managed objects that appear in WorldView. By customizing the DSM settings, you can decrease the time it takes for a DSM to discover all the resources it should monitor and to reload policy when restarted.
Use the five DSM Configuration utilities to set the scope of your DSMs at install time and to modify, delete, or add new entries while managing your environment.
DSM Agent Class Scoping displays the names of all the agent classes that the DSM manages. This list tells the DSM which agent classes to look for and which policy to load. You can define which Agent Classes your DSMs manage by checking the associated Managed Status field.
Based on information in the DSM Agent Class Scoping list, you can configure the DSM to use different community strings and ports to communicate with specific node classes and agent classes.
Why is it beneficial to modify this list of community strings? Because community strings provide the authentication notification with which the devices and DSM communicate, you may want to modify them at intervals, depending on your security requirements.
The DSM Discovery Pollset Values pane displays the poll intervals, the timeouts, and the number of retries that a DSM is using to discover agents and devices. Once discovered, the devices are assigned these poll values for use in future communications.
From this list you can quickly see what intervals, timeouts, and retries a DSM uses, or whether certain DSMs use different intervals, timeouts, and retries to communicate with certain node classes or agent classes. For example, maybe your printers are pinged less frequently than your nodes, which are pinged less frequently than the routers.
Why is it beneficial to modify this list of poll intervals? Because you can customize the intervals that the DSM uses to check all the devices, based on the type of resource or type of server being monitored. If DSM queries all devices too often, the DSM and network are busier than necessary; if a DSM doesn't query the devices often enough, you may not be notified promptly of a problematic situation.
Each DSM has a list of nodes that it manages; this is referred to as the DSM Domain. In the past CA NSM controlled the DSM Domain at the DSM layer using a file called gwipflt.dat, then later at the repository layer using the gwipfltii.dat file.
You want to modify the list of IP addresses reporting to a DSM when the historical data of the DSM Monitor suggests that the DSM server is having reoccurring problems.
By assigning your DSMs to manage specific IP addresses, you can distribute the load of monitoring your enterprise among the number of DSMs you deploy. You can also ensure that each DSM manages only those nodes which are relatively close to it within the network, to reduce the amount of network traffic.
The IP Address Scoping tool lets you change the range of subnets or hosts that report to a particular DSM, as shown in the following subnet examples:
|
Task |
Subnet Example |
|---|---|
|
Set up an entire subnet by using wildcards |
172.28.*.* |
|
Exclude specific IP address ranges from being monitored |
-172.28.192.* |
|
Specify a range of addresses within a subnet |
+172.28.192.2-8 |
|
Add another subnet range for monitoring |
172.30.4.* |
The above entries define the scope for a DSM to manage all discovered nodes in the 172.28 subnets, except for the 172.28.192 subnet, but also manage all hosts with IP address in the 172.28.192.2 to 172.28.192.8 range, as well as all nodes in the subnet 172.30.4.
The DSM IPScope table, in conjunction with the setdsmname service, notifies each DSM which nodes to manage without having to restart the DSM process.
The Managed Object Scoping pane contains a list of managed object instances that will be created and visible as icons in WorldView or in Management Command Center topology.
When a managed object in the DSM has a matching class definition in WorldView, an object is usually created in the database and is visible from WorldView. You can limit what gets displayed to objects of interest by defining which classes on which nodes should be made visible. Customize this list so that only those resources you are most interested in are displayed in WorldView and Management Command Center.
Example: You can create a Business Process View that contains a group of related resources that are managed objects (such as processes, or drives, directories, or CPU usage). You can then determine the impact that any warning or critical state will have on the rest of those resources in that Business Process View.
The DSM Wizard provides a simple and centralized method to manage DSM Scope objects. It is another tool to manage and set the scope of a DSM at install time and to modify, delete, or add new entries while maintaining your environment. You can perform the same scoping of the DSM within the pages of the DSM Wizard as is possible within DSM Configuration Tools in Management Command Center.
Note: Although the DSM Wizard can be executed from any host where a DSM is installed, we recommend that you designate one DSM machine from which to execute the DSM Wizard. This policy helps avoid confusion and duplicate work by reducing the risk that someone will incorrectly modify the managed object scope or the IP address scope and consequently change what resources are being monitored.
When working within any DSM Wizard page, select from a list of known DSM servers to apply the entries to. The word "ANY" displayed in the Select DSM field means that the entries should apply to all DSMs you may deploy. To insert the name of a new DSM that is not on your list, click New DSM and provide the name of the DSM server.
Before you exit the DSM Wizard, answer whether you want to Enable New Configuration. After you check this box and click Finish, the assigned DSMs immediately manage agent classes and update their managed hosts.
Access the DSM Wizard by using one of the following methods:
The purpose of a DSM (Distributed State Machine) is to monitor your enterprise in a thorough and efficient manner so that you or your staff is promptly made aware of any possible problems or inconsistencies. Because the DSM is an important element in your enterprise, ensure that each DSM is always connected to an MDB and that the DSM is running at peak performance.
To ensure that each DSM is running efficiently, the DSM can now manage itself and report its own status. The DSM Monitor provides real-time monitoring of the following resources:
For information about configuring each of your DSMs from a central location, see the section Configure DSM Environments.
The DSM Monitor accesses the same kind of data, even if your DSMs are installed on different operating systems. You can view the data gathered by DSM Monitor from the following interfaces:
The DSM Monitor requests information from the system agent about certain resources that the DSM uses. Then it presents the data in a graphical user interface called DSM Monitor View, which allows information technology managers to respond to trends or events that influence the performance of their DSMs.
DSM Monitor View looks very similar to other Unicenter Agent View browsers. But instead of displaying the metrics and the state of monitored resources for a remote node, DSM Monitor View displays data for only those resources that are important to the efficient running of the DSM itself.
The DSM Monitor View is a subset of the DSM Configuration, which was described in Configure a DSM Environment. After a DSM has been configured (for classes, community strings, pollsets, IP addresses and managed objects) at the Management Command Center, you can view those resources in the windows of DSM Monitor View and determine the overall health of a DSM. If DSM Monitor View consistently indicates that a DSM server is impacted negatively when polling its assigned nodes and classes, you can make adjustments with DSM Configuration tools.
To access the Summary window and view the overall status of the DSM, access Node View, right-click DSM Monitor, and select Agent View from the list.
If you are connecting to a DSM server running SNMPv3, click File, Connect, which allows you to provide the SNMP Connection Parameters.
The DSM Monitor tracks and displays the following groups of metrics for the DSM Server:
Node View displays a horizontal tree structure that lays out the hierarchy of these three monitored groups, with all of their states being propagated to the dsmMonitor, then to the host. The most severe state overrides any less severe state.
DSM Monitor dashboard looks very similar to other dashboards. But the DSM Monitor dashboard displays data for only those resources that are important to the efficient running of the DSM. The DSM Monitor dashboard presents its summary data in multiple tiles. The tiles that appear in the dashboard depend on what tile collection you select when creating the dashboard.
The DSM Monitor dashboard, like DSM Monitor View, monitors the resources thresholds, based on the settings defined in the Management Command Center with the DSM Configuration tools that was described in Configure a DSM Environment. After a DSM has been configured using the tools in the Management Command Center, you can view those resources in the tiles of DSM Monitor dashboard and determine the overall health of a DSM. If DSM Monitor dashboard consistently indicates that a DSM server is being impacted negatively when polling its assigned nodes and classes, you can make adjustments by changing the scope of that DSM using DSM Configuration tools in the Management Command Center.
|
Copyright © 2010 CA.
All rights reserved.
|
|