Once you have established your core monitoring needs and identified appropriate monitoring thresholds, you are ready to manage these systems and applications on a daily basis. Depending on how and where you deploy your core Knowledge Scripts, you may be able to better manage the resulting jobs now and in the future.
AppManager simplifies the management of your Windows, UNIX, and Linux systems by automatically managing similarly configured and loaded systems and applications. When the servers in a group are similarly configured and loaded, they are conformant. By organizing the systems and applications in your environment into groups of conformant servers, you can easily monitor for event conditions and collect data on those servers using a standard set of Knowledge Scripts.
Ideally, implement core monitoring using monitoring policies, with ad hoc jobs used only to diagnose problems detected by these policies. A simple strategy for managing your environment with AppManager is to:
Identify the critical systems and applications in your environment and configure jobs that raise an event if something goes wrong with those systems.
Organize your critical systems and applications so that you can effectively manage them on a daily basis.
Configure jobs to collect data for historical reporting and trend analysis.
Manage additional systems and applications by organizing conformant systems and applications under existing monitoring policies.
Remotely diagnose problems on your policy- systems and applications by running additional jobs.
The Control Center console uses management groups to organize managed computers and discovered resources. The console has a default Master management group that includes all managed computers and discovered resources in all QDBs you are managing with the Control Center console.
You can create additional management groups and determine membership in the management group in several different ways:
Ad Hoc membership. Membership is determined by including specific managed computers. This is similar to a server group in the Operator Console.
Repository View. Membership is determined by discovered resources on the managed computer, such as IIS or SQL. This is similar to a standard view in the Operator Console. You can also define membership based on the Master repository view, which includes all managed computers and resources.
Server Group. Membership is determined by membership in an Operator Console server group. You cannot create server groups in the Control Center console.
Rule. Membership is determined by one or more rules. Rules evaluate a managed computer and its discovered resources and either include or exclude the managed computer based on the criteria defined in the rule.
You can combine all of these methods to determine membership in a given management group. For more information about management groups, see the Control Center User Guide for AppManager, available on the AppManager Documentation page.
The following sections outline how you can use the Control Center console to successfully monitor the systems and applications in your environment.
The Master management group is a default group that displays all managed computers and discovered resources in all QDBs managed by the Control Center console. You can use the Master view to discover and monitor all of the resources on a server, including the operating system, hardware, and application resources. Depending on your environment, you may not want to allow your operations staff to have access to the Master management group.
Since the Master management group includes all the managed computers in your environment, it is not recommended that you apply any monitoring policies to this group. Doing so could adversely affect the performance of AppManager and your ability to manage the resources in your environment. You should also exercise caution in running any ad hoc jobs in the Master management group since this will create jobs on every agent computer.
A management group can include computers that you identify specifically for inclusion in the management group. This allows you to create a static set of computers that you want to manage as a group. You can include any managed computer. Unlike rule-based management groups, any computer you add to the ad hoc list will remain as a member until you remove it from the list.
Management groups based on a repository view allow you to view and manage only the resources that correspond to a particular resource type. For example, the SQL view only displays SQL resources and SQL-related Knowledge Scripts. To run Knowledge Scripts on NT resources, such as ASYNC and NTAdmin Knowledge Scripts, you must use another view. You can include more than one repository view in a management group.
You may find it advantageous to implement a monitoring policy on a repository view when you want to automatically monitor a particular system or application as it is discovered. For example, a monitoring policy on the SQL view ensures that as SQL Servers are discovered, they are managed.
If you create a management group based on the Master repository view, the management group includes all managed computers and discovered resources just as the default Master management group does.
Management groups based on an Operator Console server group include only those computers that are members of the server group. This allows you to take advantage of any server groups you have already established in the Operator Console for use in the Control Center console.
A rule-based management group allows you to discover and monitor servers that match a specific set of criteria. Unlike other management groups, rule-based management groups uses rules to dynamically update membership in the management group.
A rule-based management group provides the flexibility to select conforming systems and applications as well as logically group systems using custom properties. Rule-based groups work well when you have less information about the system that is being managed and you need to rely on the rules to select the correct system or you do not want to give access to the Master view.
Rule-based groups are particularly useful when you want to:
Organize a subset of servers into a group that can be managed by your operations staff. For example, if you configure a rule-based management group that selects a custom property value, you can easily control the servers that can be managed by your operations staff.
Automatically monitor conforming systems and applications. For example, you can configure a rule-based management group to automatically select similarly configured and loaded systems, and automatically monitor those systems by policy.
Implement group-based reporting. For example, you can use a management group to select similarly configured systems and run a report on the servers in that group.