Monitoring configuration best practices

This topic lists some of the best practices to be followed for monitoring configuration.

Monitoring configuration prerequisites

Before you begin creating policies and entering monitoring configuration settings, you must complete the following major steps:

1. You must have completed an implementation architecture design based on a sizing analysis and a study of the managed environment. This is important overall, but it also has detailed implications regarding policies that control how agents connect into the BMC ProactiveNet infrastructure. If you have not completed and documented the implementation architecture, you will not know which Integration Service nodes various agents must connect to, and therefore will not be able to create the appropriate policies to control this.
   
   Review the architecture and scalability best practices for BMC ProactiveNet Performance Management 9.6. The webinar series for these best practices is at https://communities.bmc.com/docs/DOC-28658
2. You must decide if the agents are going to be managed by policies or not. BMC recommends that you make this decision globally, meaning that the decision must apply to all agents across the entire environment. However, it is understood that some environments benefit with some agents being policy managed and others do not. Additionally, there are certain scenarios that may benefit from some PATROL Knowledge Module application classes being policy managed while other applications classes within the same agent or Knowledge Module are not policy managed. Examples are discussed further. There are a few scenarios that requirea PATROL Console and PATROL Configuration Manger to manage monitoring configuration. These scenarios are primarily limited to agent platforms and environments that are not supported by 9.5 agents. They include the following:
   1. iSeries (AS/400)
   2. OpenVMS
   3. Custom Knowledge Modules that are not BMC ProactiveNet Performance Management 9.6 compliant
   4. Older operating systems such as Microsoft Windows 2000

   5. Knowledge Modules not yet 9.6 compliant. For a list of Knowledge Modules that are configurable through policies in Central Monitoring Administration 9.6, see List-of-Monitoring-Solutions-and-KMs-in-BMC-ProactiveNet-Performance-Management.

      Warning

      Note

      You can configure agent rule sets in PATROL Configuration Manager, then import the rule sets into policies and allow the policy application process to manage automated application of the settings to agents. However, BMC does not recommend this. Use this only in situations in which the other monitoring configuration is not defined in policies and use it sparingly. The only advantage of doing this is that the related configuration settings can be applied automatically which is not a feature available out-of-the-box in PATROL Configuration Manager.

3. The BMC ProactiveNet Server and all infrastructure components including the Integration Services and event management cells must all be installed and configured including any high availability configurations.
4. Establish a naming convention and policy precedence scheme before you begin creating policies. Information about this is discussed further in this topic.
5. Complete the infrastructure configuration regarding heap settings and tuning.

Steps for overall monitoring configuration

1. Install the BMC ProactiveNet Server(s) and import the Central Monitoring Administration repositories.
2. Install at least one (if not more) remote Integration Service node.
3. Configure heap, etc, for the BMC ProactiveNet Server(s) and Integration Service nodes.
4. Configure the Integration Service on the BMC ProactiveNet Server(s) to be a staging Integration Service. This protects the BMC ProactiveNet Server by preventing the Integration Service node installed on it from consuming resources related to data collection. As in earlier releases, dedicate the resources on the BMC ProactiveNet Server to server activities and distribute all of the data collection.
5. Add the additional remote Integration Service nodes in Central Monitoring Administration and perform the following best practices:
6. 
   
   1. Configure according to the architecture best practices.
   2. Implement a standard naming practice that uniquely identifies each Integration Service node and has technical relevance. For example, name the nodes according to the domain in which they are installed.
7. Configure Integration Service clusters.
8. Create staging policies.

9. Create BMC PATROL deployable packages for test agents (including the 9.5 PATROL Agent and the required Knowledge Modules).
   
   

   Warning

   Note

   If previous versions of PATROL agents already exist, the packages must be configured to install into the same directory as the existing PATROL Agent.

    

    

10. Consider the following options:
11. 
    
    1. A package can contain an integration tag value. This tag can then be used as part of the selection criteria in a staging policy to help determine the proper data collection Integration Service to assign the agent to. You must also leverage criteria such as the BMC ProactiveNet Server that the agents are to report into for staging policies.
    2. Settings in a package can allow or deny the use of policies. If you choose to deny policy usage, the PATROL Agent does not leverage policies until the special tag is set to allow. You can manage this from the Central Monitoring Administration UI.  Note the following points:
    3. 
       
       1. If you allow policy management, the installation package must include configuring the PATROL Agent to connect to the staging Integration Service. Using the allow setting causes the agent to leverage the new policy configuration format rules, and the old configuration rules that conflict with the new rules format are ignored by the agent.
       2. If you deny policy management, the package must include configuring the PATROL Agent to connect to a data collection Integration Service. The deny setting is useful during upgrades and migrations. It ensures that the current Agent configuration is maintained but used in the newly updated PATROL Agent and BMC ProactiveNet infrastructure.
12. Deploy the PATROL deployable packages to test managed computers and unpack the compressed file.
13. Run the PATROL packages silent installer on the test managed machines.
14. Validate that the installations were successful.
15. Validate and test the PATROL Agents in Central Monitoring Administration.
16. Configure global server thresholds in Central Monitoring Administration.
17. Create test monitoring policies.
18. Create time frames.
19. Create blackout policies.
20. Enable the policies.
21. Test and validate that data is collected according to the policies you defined. Resolve any issues.
22. Move the validated policies from test to production leveraging the export/import utility.
23. Repeat steps 12 to 15 for the first small group of production computers.
24. Enable the policies in production.
25. Validate agents and data collection in production. Resolve any issues.
26. Repeat steps 23 – 25 for additional groups of production agents.

Monitoring configuration process workflow

The following process workflow diagram illustrates the process steps discussed in the preceding section. 

The most critical points to note are the following:

• Create, test, and validate before moving to production.
• Do not edit in production unless you find a problem in production that requires editing.
• Monitoring is not applied to policy managed agents until the policies in production are enabled. This is the point where you “go live” in production with monitoring. Backing out before then is easy. Backing out afterwards can be difficult depending on the situation. (Massive unintended data collection into the BMC ProactiveNet Server due to poor policy configuration is an example of a potentially difficult situation.)
• Start with a small number of agents in production to minimize risk.