Global thresholds and policy application best practices

This topic discusses the best practices when applying global thresholds and applying policies.

Global thresholds

Global thresholds are related to thresholds configured in the BMC TrueSight Infrastructure Management Server and are not applied to the PATROL Agents. The following are best practices regarding global thresholds and instance threshold management.

Define and enter global thresholds for KPIs and performance parameters in the BMC TrueSight Infrastructure Management Server before you define and enter server and agent thresholds in the monitoring policies.

Server thresholds defined in monitoring policies override global thresholds. Use server thresholds defined in monitoring policies for instance level thresholds.

Although it is available, BMC recommends that you do not use the Options > Administration > Intelligent Event Thresholds feature available in the Infrastructure Management Server operator console to specifically manage global and instance thresholds. This does not mean that intelligent thresholding must not be enabled. It must be enabled.

Controlling policy application

Policy-based configuration provides significant advantages by helping to automate and streamline the application of monitoring configuration. This functionality allows administrators to define monitoring configuration criterion that are stored as policies. When agents check into the environment, the agents automatically receive the appropriate configuration and begin monitoring according to that configuration without the administrator having to take additional steps to apply the policies. Additionally, when changes are made to existing policies the changes are automatically applied to the respective agents without having to manually initiate the application of the changes after entering the changes. These capabilities significantly speed up and simplify the administration process assuming all policy configurations have been created appropriately.

The automated nature of policy-based monitoring configuration has further significant implications. It is imperative that policy application be configured and controlled properly. Failure to follow best practices and/or failure to consider all implications can result in widespread miss-configuration and/or interruption in monitoring until a mistake is resolved. Therefore, how policies are applied and control of policy application is very important. This section covers various key points regarding policy application and control.

The default setting for policies is disabled. Do not enable policies in production until they are tested and validated in a test environment. Leverage the ability to create and test in the development and QA environments. You can then apply policies to production from the same Central Monitoring Administration instance using the process outlined in the Staging policies best practices or you can leverage the Export/Import utility.

Agent criteria

Use tags in deployable PATROL packages when there is not enough detail in the agent selection criteria for policy assignment. Examples include the following.

Agent host naming conventions do not easily support managed technology identification.
- Host naming conventions do not align with monitored application types
- Host naming conventions do not align with operating system types
- Host naming conventions do not align with instance names
Configuration differences based on geography and IP address ranges are not enough to identify the related managed hosts automatically.
Configuration is different based on departments.

The above conditions are common in most environments. Therefore, in most environments an agent tagging methodology needs to be defined and followed.

Policy managed setting

PATROL Agents 9.5 and higher include an agent rule that designates if the agent is policy managed or not. The rule is as follows:

/AgentSetup/integration/denyCgf = false|true

When the value is set to false, the agent is policy managed in Central Monitoring Administration. This is the default setting. When the value is set to true, the agent is not policy managed. You can change this setting through the Central Monitoring Administration UI.

If the agent is policy managed, non-policy rules that conflict with the policy based rules are ignored.

The following are best practices regarding the policy managed setting:

Do not toggle this setting in production. Doing so may result in significant increases in an unrequired number of instances being monitored, or instances being marked for deletion and monitoring stopped when not intended. Plan and test the configuration in a development environment.

Decide if agents are primarily policy configured or not. Consider the following when deciding how the policy managed setting is applied.

If most of the environment benefits from policy-based management, then leverage the default setting for most agents.
Agents that cannot be policy managed must have this value set to true.

Controlling policies across multiple BMC TrueSight Infrastructure Management Servers

Policy application control across different BMC TrueSight Infrastructure Management Servers that share a common Central Monitoring Administration instance must be managed with at least one of the following settings.

BMC TrueSight Infrastructure Management Server defined in the policy agent selection criteria.

Integration Service nodes in the policy agent selection criteria.

Tags defined in the agent package policies for additional selection criteria when needed.

General recommendations

Do not enable policies until they have been tested and validated in the development and test environments.

Allow large domain collection like VMware vSphere discovery to complete before reviewing the data in the Operations Console. The hierarchy has to be built and will look odd until it is complete.

Allow large domain collection like VMware vSphere discovery to complete before enabling additional policies or adding more agents. This is to control initial collection and related performance.

Do not mix policy-based and non-policy based configuration for one Knowledge Module application class. Pick one or the other for the entire application class. If you have to use a mixed approach in an environment, then avoid mixing them at the PATROL application class level.

Leverage agent tagging in the deployable package configurations to properly control which policies are automatically applied to agents.

Page tree