Monitoring policy naming standards and definition best practices

It is a best practice to organize and separately define policies according to the monitored technology that the policies apply to. For example, create separate policies for monitoring Microsoft Windows operating systems, UNIX operating systems, Linux operating systems, Oracle databases, SQL Server databases, Apache, and so on. 

The following sections discuss best practices according to the configurable sections of the monitoring policies.

Naming standards for monitoring policies

Use meaningful names for policies and put the information with the maximum impact at the beginning of the policy name. Define and follow a standard for doing this. Consider the following example.

If you are creating eight policies as follows, name them as indicated.

Enter complete descriptions in every policy description field. Put the most important information at the beginning of the description so that it is readily visible without having to hover your mouse over it.

Disable policies until they have been tested and validated for production.

Monitoring policy best practices for configuration

Monitoring configuration defines what Knowledge Modules and Knowledge Module application classes are activated on agents and used for monitoring. The following are best practices for monitoring configuration settings.

It is a best practice to enter monitoring configuration settings for one type of managed technology per policy. For example, create a policy for Microsoft Windows operating system monitoring that contains monitoring configuration settings for Windows only and does not contain other monitoring configuration settings for other technologies such as monitoring for SQL Server. Do not mix and match monitoring configuration settings for different managed technologies in one policy. Doing this creates confusion and difficulty in managing policies. There are certain exceptions to this recommendation. For example, if you want to monitor the Apache service running on a Windows computer as a process in addition to other Windows services, it is best to create a combined policy.

The following are navigation tips when working on monitoring configuration settings.

Add all instances you want to monitor to a list of monitored instances the first time you create a policy. Ensure that you add all the instances before you click the Add to List button in the Services Host Configuration area. See the following example for Windows Services.

When editing a list of existing monitored instances, ensure that you select the host configuration to edit first. If you do not select the host configuration first, your changes will not be saved. See the following figure for Windows Services monitoring configuration.

Filtering best practices

Filtering allows you to independently control information sent from the PATROL Agents to the BMC TrueSight Infrastructure Management Server per parameter. The following options are available:

• Send events only
• Send trended performance data only
• Send trended performance data and events
• Send no trended performance data and no events

Although this feature is available, BMC does not recommend that you send both trended performance data and events for the same parameter to the BMC TrueSight Infrastructure Management Server. If you are sending trended performance data for a parameter, configure thresholds in the BMC TrueSight Infrastructure Management Server for that parameter and let the Infrastructure Management Sever generate events for it.

Certain types of parameters must have only trended performance data sent to the BMC TrueSight Infrastructure Management Server from the PATROL Agents; they must not have events sent. Other types of parameters must only have events sent to the BMC TrueSight Infrastructure Management Server from the PATROL Agents, with no performance data sent. Examples of both scenarios are discussed below.

In Infrastructure Management 9.6 and higher, parameters do not have to be collected and stored in the BMC TrueSight Infrastructure Management Server to be trended and visible in the BMC TrueSight Infrastructure Management Server. Properly controlling and limiting the data collected into the BMC TrueSight Infrastructure Management Server(s) and related database has a significant positive impact on scalability of the solution. For this reason, it is important to properly identify parameters that truly need to have data stored in the BMC TrueSight Infrastructure Management Server database, and configure accordingly. In general, this must be limited to the following parameters based on parameter usage.

• KPI parameters
• Parameters required in performance reporting
• Parameters requiring “duration” thresholds. For example, you do not want an alarm unless the parameter has breached a threshold for 15 minutes.  (BMC PATROL does not support this capability.)
• Parameters requiring “time of day” type thresholds. (This is accomplished using baselines.)
• Parameters for which predictive alarming and abnormality detection are required. This generally applies to all KPIs, which can be extended.

Do not import trended performance data into the BMC TrueSight Infrastructure Management Server unless required. Leverage on-demand trending from PATROL Agents unless you need to baseline and report on the related performance data or require duration thresholds.

If you filter objects after they have already been collected in the BMC TrueSight Infrastructure Management Server, these objects display in the data collection gap report and they cannot be removed. This happens even if BMC PATROL is still trending the data and the data it visible in Infrastructure Management. 

After data for a monitored parameter is “streamed” to the BMC TrueSight Infrastructure Management Server, graphing is only available for the parameter when the data is streamed. If you filter the parameter after streaming for it was set up, you will not be able to view the trended data from the PATROL Agent for the parameter in the Infrastructure Management UI. Plan filtering first, then implement. Err on the side of not streaming the parameter data into the BMC TrueSight Infrastructure Management Server to avoid this problem. If necessary, the parameter can be streamed into the BMC TrueSight Infrastructure Management Server later.

Agent threshold best practices

Agent threshold configuration settings are applied to BMC PATROL Agents and are related to parameters monitored by the PATROL Knowledge Modules. This section discusses best practices for these agent thresholds.

Do not set agent thresholds for performance-oriented KPI parameters or any other parameter that has trended data stored in the BMC TrueSight Infrastructure Management Server database.

Set agent thresholds for availability and Boolean type parameters in the BMC PATROL Agent threshold configuration section of monitoring policies. This allows the agents to generate the related events and forward them to the BMC TrueSight Infrastructure Management Server. This prevents you from having to trend these parameters in the BMC TrueSight Infrastructure Management Server and helps increase the scalability of the overall solution without losing functionality. The following is a list of example parameters that fall into this category. These are only examples.

• Windows service status
• Process up/down monitoring
• Monitoring for error messages and strings in log files
• Windows Event Log monitoring
• Database listener status

Define agent threshold settings in the Agent Threshold section of policies that also contain monitoring configuration for matching Knowledge Modules and monitor types so that the all settings specific to a Knowledge Module or monitor type are configured in the same policy.

Server threshold best practices

Server threshold configuration settings are applied at the BMC TrueSight Infrastructure Management Server and not to the PATROL Agents. This section discusses best practices for the server managed thresholds.

Use server thresholds for instance level thresholds settings. Use Global thresholds to manage thresholds that apply to all instances across the environment.

Do not set server thresholds for availability or Boolean oriented parameters, or any other parameters that have events generated for them by the PATROL Agents.

Set server thresholds for performance-oriented KPI parameters and any other parameters that have trended data stored in the BMC TrueSight Infrastructure Management Server database. The following is a list of scenarios for server thresholds based on parameter use cases. Note that these recommendations are the same for filter configurations.

• KPI parameters
• Parameters required in performance reporting
• Parameters requiring “duration” thresholds. For example, if you do not want an alarm unless the parameter has breached a threshold for 15 minutes.  (PATROL generally does not support this capability.)
• Parameters requiring “time of day” type thresholds.  (This is accomplished using baselines)
• Parameters where abnormality detection is needed. This generally applies to all KPIs and can be extended. 

The following is a list of example parameters that must have server thresholds and no agent thresholds. These are only examples.

• URL Response Time
• Application Response Time as reported from BMC End User Experience Management or BMC TM ART
• CPU Utilization
• Disk Drive Free Space
• Queue Depth
• Memory Utilization
• Database Table Space Extents Left
• Heap Space Free

Define server threshold settings in the Server Threshold section of policies that also contain monitoring configuration for matching Knowledge Modules and monitor types so that all settings specific to a Knowledge Module or monitor type are configured in the same policy.

Agent polling frequency best practices

Agent configuration settings include general settings that apply to PATROL Agents and Knowledge Module application class polling frequencies. The following are best practices related to settings in the Agent Configuration section of monitoring policies.

Avoid configuring the following settings in the Agent Configuration section of policies that also contain monitoring configuration for Knowledge Modules and monitor types. Instead, configure these settings in policies that are specifically for these agent settings and infrastructure configuration.

• Agent user ID and password
• Agent restart
• Agent tags (see note below)
• Integration Service node configuration (see note below)
• Event configuration properties

The following screen shot shows the location of these settings in Central Monitoring Administration.

Define polling interval settings in the Agent Configuration section of policies that also contain monitoring configuration for Knowledge Modules so that the all settings specific to a Knowledge Module are configured in the same policy.

For many Knowledge Module application classes, the default data collection period is one minute. If this frequency of collection is not required, it must be reduced. This greatly reduces the amount of data transferred, reduces the associated load on the BMC TrueSight Infrastructure Management Server(s) and increases overall scalability.

Server configuration best practices

The Server Configuration section provides three functions as follows:

• Automatically assign agents as devices to groups. If the specified group does not exist. it is automatically created.
• Automatically copy baselines from an existing device to the device that is automatically created for a new agent.
• Associate the device for a new agent with a user group in the BMC TrueSight Infrastructure Management Server (this provides automation for access control of new devices as agents are brought online).

The following are best practices for the server configuration settings:

• Do not use the automated group creation functionality excessively. Plan the groups you need appropriately and configure accordingly.
• Use the copy baseline feature only when you know the existing baseline is appropriate seed data for a new agent/device. A good example is if you are adding an additional server to an Apache web server farm behind a load balancer where the new server has the exact same configuration as the other servers in the farm (OS version, machine sizing and type, Apache version, Apache configuration) and the new Apache web server processes the exact same types of transactions for the same application. If you are not certain, do not use the copy baseline feature.

Configuration variable best practices

The Configuration Variables section allows you to manually create agent configuration rules that are not created in the other policy configuration screens. This includes certain settings such as agent history retention, agent run queue schedule settings, disabled Knowledge Modules, and so on. 

The following are best practices regarding the usage of the Configuration Variables section:

• If there is a policy setting available for a configuration, use the policy and avoid importing old configuration from PATROL Configuration Manager when it is not needed. Create separate policies for old PATROL Configuration Manager rules if no monitoring policy wizard is available.
• Do not try to manually convert policy data from the old format or from PATROL Configuration Manager to the new format. The PATROL Agent rule data related to policies must be associated with a policy for the policies to work correctly. This association is handled by Central Monitoring Administration and stored in the database when policies are created.
• Do not try to import large rule sets from PATROL Configuration Manager so that they are controlled and managed as policies. There are two reasons to avoid this:
  • Very large rule sets fail to import.
  • If you are not going to use the other settings discussed above regarding monitoring policy configuration for a particular agent or managed technology, it is not required to create polices for it. Continue to manage the configuration using PATROL Configuration Manager in this scenario. 
• The preceding recommendations do not mean that you must avoid using the Configuration Variables section in policies. Use this section to manage various agent settings such as the disabled Knowledge Modules list, agent history retention, and so on.
• You may also decide that configuration regarding a particular Knowledge Module be non-policy managed, while other Knowledge Modules be policy managed. One example is monitoring for Oracle instances. Due to Oracle instance monitoring configuration steps, it may be better to manage their monitoring configuration without using policies while still leveraging policies for operating system monitoring.

Related topic

Monitoring configuration best practice reference