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.
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.
Basic monitoring for Microsoft Windows operating systems that apply to all Microsoft Windows servers
Basic monitoring for Red Hat operating systems that apply to all Red Hat Enterprise Linux servers
Monitoring for Oracle databases that apply to all Oracle databases
Monitoring for SQL Server databases that apply to all SQL Server databases
Monitoring for Apache that apply to all Apache instances
Monitoring for WebLogic that apply to all WebLogic instances
Windows DSN Server monitoring
Windows DHCP Server monitoring
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 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.
By default an agent monitors nothing and no data is sent to the BMC TrueSight Infrastructure Management Server from the agent until it receives a policy. This assumes the agent is version 9.5 or higher, that it has been installed with the default monitoring settings, and that the policy managed setting has not been set to true. (The default setting is false).
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 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:
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.
There is no value in just pushing or copying data from one place to another without a reason. The above points are clear reasons to store the associated parameter data in the BMC TrueSight Infrastructure Management Server. If a parameter does not fit this criteria, reconsider carefully before you decide to allow data for it to be collected and stored in the BMC TrueSight Infrastructure Management Server.
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 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.
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 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.
The following is a list of example parameters that must have server thresholds and no agent thresholds. These are only examples.
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 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.
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.
The Server Configuration section provides three functions as follows:
The following are best practices for the server configuration settings:
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:
The preloaded Knowledge Module list is automatically populated with Knowledge Modules that you create policies for. Therefore, you do not need to manage the preloaded Knowledge Module list manually. However, if necessary, you can control it with a rule setting in the Configuration Variable section of a policy. All Knowledge Modules that you use for monitoring on an agent must be in the Knowledge Module's preloaded list for the agent.