Get started > Key concepts > Monitoring Automation

Monitoring Automation

Monitoring Automation automates the configuration of monitoring for infrastructure and composite applications. Whether the monitoring tool used is agent-based or agentless, Monitoring Automation deploys the appropriate monitoring configuration to the target instances. It offers easy-to-tune monitoring and reporting, detecting new instances of components and mapping them to management templates and aspects that model the desired configuration and resource type.

Monitoring is the generation of events if a CI behaves in an unexpected manner. Typical events are:

  • A monitored value exceeds a certain threshold. Example: Used disk space on a database exceeds a predefined limit of 90%.

  • A node is removed from the network. Example: A power cut causes a server to shut down so it can no longer be reached.

Monitoring Automation provides a complete management solution for an application or service, enabling you to create a management solution for the entire set of configuration items (CIs) comprising the application. The solution can be made to respond dynamically to changes in the topology, making the monitoring solution independent of the hardware and platform running the application.

The key to understanding Monitoring Automation is to familiarize yourself with the underlying terminology and architecture. Consider the stack shown in the following figure:

The base of the stack represents the CIs to be monitored. CIs can be network elements such as computers, as well as applications or sets of applications providing a service. CIs are accessed in the following ways:

  • Users interact with the CIs independent of any monitoring, as suggested in the central section of the figure.

  • OMi monitors the CIs using the familiar monitoring structure shown in the left-hand section of the figure.

  • A monitoring developer configures monitoring solutions as shown in the right-hand section of the figure.

  • An application expert starts the monitoring process after tuning the configuration made by the monitoring developer, and acts on events passed by the operator by inspecting deployment jobs and using application-specific administration tools.

Monitoring Automation offers a number of features for creating flexible monitoring solutions. The following section explains each configuration element in turn. The explanation follows the order of the layers comprising the configuration stack from bottom to top.

Node

A node is a physical element you can access on the network.

CI

A CI is a node or an application or services running on a node. CIs are what is actually monitored by OMi. Events always relate back to CIs.

Policy Templates

Policy templates define what is monitored and how the monitoring is done. Note that policy templates are platform-dependent.

Before Monitoring Automation, all configurations were done through Policies and Policy Templates, meaning that for each change in a CI with respect to the platform, the topology, or the monitoring policy, the values in the CI's policy templates against which the CI is monitored had to be modified.

Parameters and Instrumentation

Monitoring Automation introduces parameters. Each parameter corresponds to a monitoring setting for a single CI attribute in the policy template. Changing the parameter value changes the monitoring behavior, removing the need to manually change hard-coded values in a policy template. The concept of cascading default values is central to Monitoring Automation. The idea is that the monitoring developer or application expert uses as many default values as possible on a certain level, creating a baseline for monitoring. On the next level up, a subset of these values can and may need to be overridden for the specific monitoring task at hand, but every value already covered by the baseline setting can be taken over without having to redefine it.

The following features of parameters allow additional flexibility:

  • Conditional parameter values enable using the same parameter with several policy templates, allowing hardware- and platform-independent monitoring solutions.
  • Parameters with the same value can be combined into a single parameter. This removes the need to enter the same value multiple times.

Instrumentation includes scripts and programs executed by the HPE Operations Agent as defined in policies for managed nodes that have the agent installed on them.

Aspects

Policy templates and instrumentation representing a certain expected behavior of the application or service to be monitored are grouped together in aspects. At aspect level, developers streamline the configuration as follows:

  • They combine parameters with the same function into single parameters.

  • They can nest aspects to combine aspects representing the same behavior, but defined in different policy templates, into a single aspect. Each nested aspect can be coupled with a deployment condition telling OMi which nested aspect is to be used in which environment. This allows any CI of the target CI type to use the same aspect, independent of the platform.

  • They set default values at aspect level in line with the company monitoring policies.

Management Template

A management template combines all aspects needed to monitor a composite application or service. The management template configuration includes the topology of the composite application and the aspects to be monitored. In addition, the developer overrides any company-wide default values at management template level if the application to be monitored requires this.

The developer hands the finished management template over to the application expert, who uses it to start monitoring the target application.

Tuning, Assignment, and Deployment

Before starting the monitoring process, the application expert may want to override certain default values configured by the monitoring developer to take situation-specific monitoring requirements into account. This is called tuning.

The monitoring configuration represented by an aspect is defined in terms of a CI type. To start monitoring, this CI type has to be matched to an actual CI instance that has been discovered by the topology discovery process. This matching process is called assignment and can be done in the following ways:

  • Manual assignment of a management template. The application expert links the management template to a CI instance of the management template's root CI.

  • Manual assignment of an aspect. The application expert links the aspect to a CI instance of the aspect's target CI type.

  • Auto-assignment. If the application expert defines auto-assignments for a management template or aspect, OMi dynamically assigns aspects to the relevant CI instances as and when they are discovered.

After assignment is completed, the monitoring solution is deployed in the same step. While the monitoring is running, the application expert can keep an eye on any deployment jobs to make sure the monitoring process proceeds as expected, or to acquire information related to events reported by an operator.