Central Monitoring Administration best practices


This section describes the best practices and recommendations to be used for BMC ProactiveNet Central Monitoring Administration.

Types of architectural deployments

BMC recommends implementing one of the following two choices of architectural deployments for Central Monitoring Administration.

Implementing a single Central Monitoring Administration instance for all environments

The first choice is to implement a single Central Monitoring Administration instance for all environments including development, test, and production.

Pros

  • Creating, testing, and deploying monitoring policies into production are very easy because you do not have to copy or export or import any data. The application of policies to the development, test, and production environments is simply managed in the policy’s agent selection criteria.
  • It requires less infrastructure nodes and components. Only a single staging Integration Service host is needed. Only a single Central Monitoring Administration instance is used.

Cons

  • This many not be supported in some sites where all the necessary connections in the development, test, and production environments are not available or allowed to be connected over the network.
  • Due to the powerful ease of use, it is easier for administrators to make mistakes applying policies unintentionally to production. However, this can be managed.

Implementing a separate Central Monitoring Administration instance each in the development, test, and production environments

The second choice is to implement a separate Central Monitoring Administration instance each in the development, test, and production environments.

Pros

  • Is supported in sites where all necessary connections in the development, test, and production environments are not available or allowed to be connected over the network.
  • Provides a platform and supports policy management methods that help prevent administrators from making mistakes when applying policies to production.

Cons

  • Creating, testing, and deploying monitoring policies into production require more manual effort because you have to export or import policy data from the development to the test environment and from the test to the production environment.
  • Policies can get out of sync across development, test, and production environments if not managed properly. Keeping them up-to-date is more of a manual process supported by the export/import utility.
  • It requires more infrastructure nodes and components. The development, test, and production environments must each have a dedicated staging Integration Service host and a dedicated instance of Central Monitoring Administration.

Important

Neither method supports seamless creation, testing, production, deployment, and deletion of updates for existing policies. Updates and deletion of existing policies that are already in production must be created, tested, and populated to production leveraging the policy export/import capability. For more information see Staging-and-policy-management-for-development-test-and-production-best-practices.

In all scenarios, Central Monitoring Administration communicates thorough the agent controller process on the BMC ProactiveNet Server(s) to the Integration Service nodes. 

These implementation architecture options are not installation options. The Central Monitoring Administration components are the same. These two implementation architecture options are just choices in how you install Central Monitoring Administration instances and connect them to the various BMC ProactiveNet Servers.

Single Central Monitoring Administration architecture overview

The following diagram illustrates the high-level architecture for a single Central Monitoring Administration instance in a multiple BMC ProactiveNet Server environment including development, test, and production.

single_cma_architecture.png

In the single Central Monitoring Administration architecture, a single staging Integration Service node is used in the agent deployment process for all agents. All BMC ProactiveNet Servers leverage the single Central Monitoring Administration instance for the entire policy management.

Multiple Central Monitoring Administration architecture overview

The following diagram illustrates the high-level architecture for multiple Central Monitoring Administration instances in the development, test, and production environments.

multi_cma_architecture.png

In this architecture, each environment has its own dedicated Central Monitoring Administration instance and a staging Integration Service. All policy application between environments is supported by the policy export/import utility.

Standalone Central Monitoring Administration architecture overview

In most BMC ProactiveNet multiple server environments, Central Monitoring Administration is installed automatically when the BMC ProactiveNet Central Server is installed. However, it is possible to install Central Monitoring Administration when you are installing a standalone BMC ProactiveNet Server and then manually register the additional BMC ProactiveNet Servers with Central Monitoring Administration after the installation.

The following are reasons for installing Central Monitoring Administration on standalone BMC ProactiveNet Servers and not leveraging the Central Server capability:

  • The top tier BMC ProactiveNet Server is only needed to provide an enterprise event console.
  • The functions of the Central Server are not required.
  • It serves as a single point of entry for service model visualization.
  • It serves as an enterprise level map view.

Details of the Central Monitoring Administration architecture

The following diagram illustrates the default ports and connectivity that support Central Monitoring Administration across multiple BMC ProactiveNet Servers. The arrows indicate the direction from which the connections are established.

cma_architecture.png

The detailed architecture applies to both, single server deployment and multiple server deployment.

 

 

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*