A monitoring policy uses a set of pre-configured Knowledge Scripts to automatically monitor resources as they appear in a management group. A monitoring policy enables you to efficiently and consistently monitor all of the resources in your environment.
For example, you can create a monitoring policy to monitor physical disk resources for a particular group of computers. The monitoring policy monitors the discovered physical disk resources on each computer in the group using the same monitoring values. If the disk configuration for a managed computer changes (for example, adding a G: drive), the next time AppManager discovers physical disk resources, the monitoring policy automatically monitors the G: drive. If you add a computer to the group, the monitoring policy automatically monitors the discovered physical disk configuration. If you remove a physical disk from the managed computer and rediscover resources, the monitoring policy automatically stops monitoring the resource.
A monitoring policy is implemented through one or more Knowledge Script Groups. A Knowledge Script Group is a set of pre-configured Knowledge Scripts which you can run as part of a monitoring policy for a group, list of ad hoc computers, or view, or as a set of monitoring jobs on a physical computer or logical server.
The advantage of using a Knowledge Script Group to monitor by policy is that AppManager automatically monitors matching resources—a monitoring job that an individual Knowledge Script starts only monitors particular resources.
A monitoring policy also enforces the same monitoring values on all monitored resources. However, Control Center allows you to change the monitoring values for a particular policy-based job. This is useful when a resource experiences a temporary or acceptable event condition that is outside the threshold levels the monitoring policy permits.
If you have a resource that is consistently outside of the policy you created, you can override the monitoring values on that resource. For more information, see Setting Override Values.
Alternatively, you can stop and restart a policy-based job. For more information, see Stopping and Restarting Policy-based Jobs.
You can monitor resources from the Master and AM Logical Servers management groups, but NetIQ Corporation recommends that you do not implement a monitoring policy on the Master and AM Logical Servers management groups.
To remove a resource from a policy, either change the policy, reconfigure the management group to not include the resource, or delete the resource from the database.
To better understand how a monitoring policy works, keep in mind:
A monitoring policy is implemented at the management group level through one or more Knowledge Script Groups. A Knowledge Script Group is a pre-configured set of Knowledge Scripts collected together into Knowledge Script Group members.
A Knowledge Script Group member is an instance of a Knowledge Script. For example, the NT_CPULoaded Knowledge Script can be a member of several Knowledge Script Groups, with the member in each Knowledge Script Group configured to use different monitoring values.
A monitoring policy automatically creates policy-based jobs to monitor matching resources in the management group. A policy-based job is an instance of a Knowledge Script Group member in the primary QDB that has been replicated to the QDB running the job on agent computers.
When you apply a monitoring policy to a management group that includes logical servers, the policy-based job runs on the agent computers for the logical servers but only monitors the logical servers. For example, if a physical computer contains virtual machines A and B and you create a management group that only includes virtual machine A and apply a monitoring policy to that management group, the policy-based job runs on the physical computer but only monitors virtual machine A.
Unlike a monitoring job, you cannot modify the monitoring values of a policy-based job by modifying the policy-based job itself. To change the monitoring values of a policy-based job, you must update the parameter values of the Knowledge Script Group member.
Properties propagation automatically publishes changes to the monitoring policy to corresponding policy-based jobs. For example, if you change the properties of a Knowledge Script Group that is part of a monitoring policy, AppManager automatically propagates the changes to create, remove, or change policy‑based jobs.
If a policy-based job encounters an error while attempting to monitor a resource, the monitoring policy attempts to restart the job. AppManager can only restart monitoring jobs; it does not automatically restart discovery- and AppManager agent-related jobs. If AppManager cannot automatically restart a policy-based job, or if you scheduled the policy-based job to run once, you can manually restart the job after its status changes to Stopped.
You can configure exceptions to monitoring values in a policy-based job. This is useful when a resource that a policy manages raises unnecessary events. For more information, see Section 5.5, Setting Override Values.
Unlike ad hoc jobs, you cannot add comments to a policy-based job. For more information about job comments, see Section 5.11.6, Viewing Job Comments.
If you are configuring a monitoring policy for a group of resources that are managed by more than one QDB, unlike ad hoc jobs, you cannot configure different parameter values for each QDB. To resolve this issue, you can configure override values or configure different management groups for each QDB.
NetIQ Corporation recommends that you implement a monitoring policy in the Control Center console. If you implement a monitoring policy in the Operator Console, the policy is not visible from the Control Center console. For example, if you use the Operator Console to configure a monitoring policy for the NT view, a management group with the NT view as a member does not display the monitoring policy.
NOTE:
A job that is not part of a monitoring policy is a monitoring job. A monitoring job monitors a particular resource on a physical computer or logical server. Unlike policy-based jobs, you must manually propagate Knowledge Script properties to monitoring jobs. In addition, monitoring jobs do not automatically monitor resources that AppManager discovers after the job starts.
The SQL Server Agent service (SQLSERVERAGENT) must be running on the repository database server. If SQLSERVERAGENT is not running, monitoring policies will not work.
If a Knowledge Script Group starts a job, AppManager prepends the Knowledge Script job name with the identifier of the Knowledge Script Group that started the job. This information does not appear in the Knowledge Scripts view of the Control Center console.
HINT:To avoid truncating the Knowledge Script job name when running a custom Knowledge Script as part of a monitoring policy or as an ad hoc job started by a Knowledge Script Group, NetIQ Corporation recommends that you limit the length of the Knowledge Script name to 120 characters. The maximum length for a Knowledge Script is 125 characters.
Do not run reports as part of a monitoring policy. You should not run the same report on more than one report agent as part of a monitoring policy.
To select the data streams you want, the Add Data wizard of the Chart Console lists the corresponding Knowledge Script job names. For policy-based jobs and ad hoc jobs a Knowledge Script Group starts, AppManager prepends the Knowledge Script Group identifier to the Knowledge Script job name.
Policy-based jobs appear in the Jobs view. The Job Type column displays Monitoring Policy for monitoring policy jobs and Ad Hoc (Knowledge Script) for ad hoc monitoring jobs.
The Jobs view does not display the Knowledge Script Group identifier for policy-based jobs or ad hoc jobs a Knowledge Script Group starts. For more information, see Section 7.1.2, How Knowledge Script Groups Work.