1.3 Monitoring in Different Environments

Computers on which you install AppManager agents become agent computers you can monitor. You run Knowledge Scripts to monitor agent computers. Knowledge Scripts help you collect data, monitor for events, and respond to events.

A job is an instance of a Knowledge Script running on an agent computer. Each time you run a Knowledge Script, you create a job. At a minimum, to create a job you must discover your agent computers and run Knowledge Scripts on those computers.

When you start a job, AppManager inserts a new record into the QDB and notifies the management server of the job request.

The agent communicates back to the management server any relevant output from the Knowledge Script. For network efficiency, the AppManager agent only communicates back to the management server when an event occurs or data needs to be inserted into the repository database.

AppManager agents handle the scheduling and housekeeping of Knowledge Scripts, and initiate corrective actions and communication with the management server. The collection of performance and event data is facilitated through the use of software modules called managed objects that “plug into” the AppManager agent.

Knowledge Scripts use managed objects to access counters, event logs, queries, application programming interfaces (APIs), and other sources to gather statistics, metrics, and other properties of specific application elements. On Windows computers, managed objects are COM/OLE objects in the form of dynamic link libraries (.dll files). On UNIX and Linux computers, managed objects are Perl modules, in the form of dynamic shared libraries.

Using these native sources of information, managed objects collect raw statistics and information, such as current CPU utilization or database lock activity, and pass that information to the Knowledge Script jobs. Knowledge Scripts then provide the rules for what to do with this raw information. The Knowledge Scripts run under the control of the AppManager agent. On Windows agent computers, the Knowledge Scripts invoke the managed objects through the standard COM/OLE interface. On UNIX and Linux agent computers, the Knowledge Scripts invoke the managed objects through the standard Perl module interface.

1.3.1 Monitoring in a Windows Environment

When you start a job on a Windows computer, the Control Center console notifies the CCDB that you requested a Knowledge Script to run (the Operator Console contacts the QDB directly). The command queue service updates the appropriate QDB with information about the job properties and the QDB, with updated job information, communicates with the management server (NetIQms). The management server then sends the Knowledge Script to the appropriate agent computers you want to monitor by contacting the AppManager agent (NetIQmc). The following diagram illustrates this process.

As the agent runs a job, it uses the associated Knowledge Script to gather information. Knowledge Scripts gather information a variety of ways. For example, a Knowledge Script might check the value of performance counters, read log files, execute queries, or access system tables.

In Windows environments, modules allow Knowledge Script jobs to run and gather information. A module is AppManager software that resides on the agent computer to enable management of a particular third-party product. During setup, you select modules to install based on the servers and applications you want to monitor. For more information about modules, see the Installation Guide for AppManager, available on the AppManager Documentation page.

Each time a Knowledge Script runs, it evaluates information the module returns to determine whether the management server needs to insert events or data into the QDB. If so, the NetIQmc service notifies the NetIQccm service, which then notifies the management server to upload the information to the QDB. This triggers the CCDB to update with the latest information as well.

If the NetIQccm service cannot communicate with the management server, it writes the data to the local repository. Upon reconnection, the NetIQccm service uploads data from the local repository to the management server.

1.3.2 Monitoring in a UNIX or Linux Environment

If you are monitoring UNIX or Linux servers, the AppManager agents you install are called NetIQ UNIX agents (UNIX agents). You can use the UNIX agent with several NetIQ products, and you install the UNIX agent using NetIQ UNIX Agent Manager.

Every 30 seconds, UNIX agents send a heartbeat message to the management server to indicate they are working properly. Each heartbeat message also requests new or updated job information.

When the UNIX agent contacts the management server, the management server determines whether any of the Knowledge Script jobs for the agent computer have been added or updated. If you changed job properties or added new jobs since the last heartbeat interval, the management server delivers the revised job information to the UNIX agent. If there is no change to the Knowledge Script job the agent computer is running, the management server simply acknowledges the heartbeat and waits for the next heartbeat. The following diagram illustrates this communication flow.

After it receives a job from the management server, the UNIX agent runs the job to access log files, system tables, or other data providers and retrieves the information requested.

Each time the Knowledge Script job runs, it determines whether events or data need to be inserted into the QDB. If an event condition is detected or a data point collected, the UNIX agent communicates with the management server to upload the information to the QDB.

If the UNIX agent service cannot communicate with the management server, the agent writes the data to the db directory on the UNIX or Linux computer. When connectivity is reestablished, the UNIX agent uploads any data stored locally to the management server.

The management server inserts events and data from the UNIX agent into the standard AppManager workflow. You can use the Control Center console or the Operator Console to see events stored in the QDB. The following diagram illustrates this communication flow.

1.3.3 Working with Both Windows and UNIX Computers

Although slight differences in communication exist for Windows agents and UNIX agents, the AppManager workflow is the same in a heterogeneous monitoring environment. The following figure illustrates the basic relationship between AppManager components and the UNIX and Linux environment.

In an environment with both Windows computers and UNIX or Linux computers, a single management server can communicate with:

  • Multiple Windows agents

  • Multiple UNIX agents

  • A combination of Windows and UNIX agents

You can also install multiple management servers in your environment to distribute processing and to provide failover support for Windows, UNIX, and Linux computers.

For information about:

  • Configuring a management site to use multiple management servers, see the Administrator Guide for AppManager, available on the AppManager Documentation page.

  • Installing and configuring a UNIX agent and monitoring in a UNIX or Linux environment, see the AppManager for UNIX Management Guide, available on the AppManager Modules Documentation page.