In AppManager, Knowledge Scripts, which are programs that run on agent computers (servers and workstations), facilitate all management and monitoring tasks. Knowledge Scripts can collect data, monitor for specific events, and perform specific actions in response to events. Each script performs a certain task or set of tasks and works on specific types of resources.
A job is an instance of a Knowledge Script in the primary QDB that has been replicated to the QDB running the job on agent computers with a matching resource. That is, when you run a Knowledge Script you are creating a job.
Knowledge Scripts are organized into categories that are loosely connected to management groups in the Control Center console. For example, SQL Knowledge Scripts that check database statistics are available in management groups that include the SQL and Master views. You can apply General Knowledge Scripts to all Windows-based views for generic management of supported Windows platforms, and action Knowledge Scripts let you initiate actions in any view.
|
To... |
Do this... |
|---|---|
|
Select a Knowledge Script category |
Click a Knowledge Scripts view and in the view pane, expand a Knowledge Script category. |
|
Get detailed information about a Knowledge Script |
Double-click a script in the Knowledge Scripts view and on the Values tab, click Help. |
The individual Knowledge Scripts displayed in any Knowledge Script category vary depending on the resource objects actually discovered. For example, if printers have not been discovered in the environment, then the PrinterHealth Knowledge Script will not display in the NT Knowledge Script category.
Most Knowledge Script jobs are run on a regular basis to keep continuous or periodic watch over system resources. To monitor resources on a continuous basis, configure a monitoring policy. For more information, see Section 7.0, Monitoring by Policy.
In some cases, you need to run a combination of scripts to pinpoint a problem. As an example, assume you run only the Exchange_ServerHealth Knowledge Script on a particular resource. If the Knowledge Script sends you an alert indicating the server is overloaded, you might need to run additional Knowledge Scripts, using the run once schedule to determine the cause of the problem.
By running these additional Knowledge Scripts, you get a better sense of the activity on the resource and the potential sources of the problem you are investigating. To carry this example further, if you discover that a server’s CPU is busy, you can run the NT_TopCPUProcs Knowledge Script to pinpoint the processes that are consuming the CPU time.
Once you identify the problem source, there are several things you can do to take appropriate action. For example, in this case you might:
Spread out the CPU load so that the top CPU processes and users run at different times to reduce system load.
Change the computer’s hardware configuration. In some cases, a computer might not have adequate or appropriate hardware for the tasks it runs. For example, there might be insufficient RAM or disk space. You can determine this by examining the details of hardware resource objects.
When jobs that check general system health or a number of different resources report event conditions, investigate the event detail message and consider running additional, more specialized jobs to find the real source of the problem and the best solution.
When you create a Knowledge Script job, AppManager creates a parent job and a child job on each agent computer. The number of child jobs AppManager creates corresponds to the number of objects selected on the Objects tab of the Job Properties window. For example, if you run the Knowledge Script on one computer, AppManager creates one child job; if you run it on several computers, AppManager creates a child job for each one.
In the Control Center console, you can group child jobs by Parent Job ID. You can also select default Jobs view settings to group jobs by Parent Job ID, to show all jobs in a flat view, or show only child jobs in a flat view. Grouping child jobs by parent job enables you to modify all the child jobs under a parent job simply by modifying the parent job. Modifying the properties of a single child job requires that you update each child job individually.
To monitor the overall health of your environment, configure a monitoring policy. One advantage of implementing a monitoring policy is that you can automatically configure changes to policy-based child jobs. For more information, see Section 7.0, Monitoring by Policy.
You can add additional child jobs to an existing parent job. This allows you to run an existing job on additional resources in your environment without needing to start a new parent job to include the new resources. You can only add child jobs to ad hoc parent jobs, and you can only include resources that are managed by the same QDB that contains the parent job. Also, you can only add resources from the management group containing the Jobs view you are using to add a child job.
To add a child job to a parent job:
In the Enterprise Layout view of the Navigation pane, select the Jobs view containing the parent job where you want to add a child job.
Right-click the ad hoc parent job you want and then click Add Child Jobs.
Select the resources where you want to run the Knowledge Script job, and then click OK.
Each Knowledge Script runs on certain types of objects that correspond to the types of resource objects you see on the Details tab of the Server Information pane. AppManager handles all of the appropriate type matching so you never have to worry about running the wrong type of Knowledge Script on a computer or resource.
In deciding which Knowledge Scripts to run, consider the critical resources in your environment, how servers and applications are distributed, potential system bottlenecks, and the breadth and depth of monitoring you want to do.