Cloud Control monitors a vast array of performance metrics automatically and compares them with predefined metric thresholds. You can have Cloud Control issue alerts whenever performance metric values exceed a specific threshold value, which serve as the triggers for the sending of alerts. You can specify both critical and warning alerts following the crossing of alert thresholds by monitored metrics. You can thus set up a comprehensive alert system that lets you know when performance is slow or when a target is down. For routine tasks, you can even set up the correct actions to automatically resolve certain alert conditions, during which Cloud Control won’t monitor that target.
Cloud Control notifications include e-mail messaging and even the execution of scripts and the relaying of SNMP traps. You can also automate the opening of help desk tickets following an incident, with the help of management connectors.
For JMX-managed applications, you can extend monitoring deployed to WebLogic Server by adding performance metrics that go beyond the out-of-box metrics. You can also define new target types for monitoring via management plug-ins for more comprehensive monitoring of JMX-enabled applications. Use the command-line tool
emjmxcli to automate the generation of metadata.In order to increase the effectiveness of your Cloud Control deployments to manage your middleware environments, Oracle recommends that you start by creating metric thresholds and monitoring templates. Oracle further recommends that you should make the monitoring templates a part of a template collection and, finally, create administrative groups to group various target types together, so you can associate your monitoring template collections to the administrative groups. It’s an Oracle recommended best practice to set up notifications by creating rules and rule sets, so you can proactively manage problems in your environment.
In the following sections, we describe these monitoring best practices in more detail.
Defining Metric Thresholds
It’s extremely important to define a set of metric thresholds to guide your management and monitoring of your middleware environment. You set metric thresholds for all performance and availability–related metrics, so you are alerted when a monitored metric value crosses its threshold value. Using metric thresholds for alerts, ideally based on your service level agreements, will help you proactively monitor the availability and performance of your middleware environment instead of waiting for users to call about performance issues. As described earlier, you can set both warning and critical alerts for things such as the JVM heap usage in a production WebLogic Server.
All your Java applications, the WebLogic servers, and SOA composites will be ideal candidates for setting alert thresholds. Choose only those alerts that are really meaningful to you, and disable the rest of the metrics so you won’t get unnecessary alerts. You can define acceptable performance on the basis of your existing service level agreements. You determine your performance thresholds based on your service levels. Although there are several out-of-the-box thresholds, you may need to customize them to fit your requirements.
Creating Monitoring Templates
To make it easy for you to set thresholds across your middleware environment, Cloud Control offers you monitoring templates, which help you apply uniform monitoring settings everywhere in your enterprise. By bundling templates for a set of targets into a template collection and associating that template collection with a group of targets, you can easily automate the application of monitoring settings across your middleware environment. When you add new targets, the targets automatically inherit the monitoring settings you’ve defined for that group through a monitoring template.
You can create monitoring templates from scratch, or better still, use Cloud Control’s predefined templates for target types such as Oracle WebLogic Domain, Oracle Fusion Middleware Farm, Application Deployment, Oracle WebLogic Server, and so on. Monitoring templates help you set thresholds for various target types, which will then be automatically applied to those targets. If, for example, you want to monitor the average response time for production web services, you define a threshold for this metric, to accurately reflect your SLAs for that service.
In order to apply this threshold to all Web Services, for example, create a monitoring template named Production Web Services. Any production web service that you’re running on a server will be subject to the thresholds you set through this monitoring template. Since you can create thresholds at varying granularity levels, first create broad thresholds and create a template for those thresholds. You can then set fine-grained metric thresholds using the coarser-grained templates as the base.
Creating Template Collections
In order to further ease your administrative burden, you can create template collections for a set of thresholds for groups of targets that belong to a specific target type. A template collection consists of different monitoring templates, for example, one for production targets and the other for development targets. In each template collection, you can have a single monitoring template for each target type that’s a part of the template collection, such as a template for WebLogic servers and another for Application Deployments and yet another for Web Services, for example.
Oracle recommends that you use template collections to apply monitoring settings and keep direct ad hoc application of monitoring templates to targets only when you have to.
Creating Administration Groups
Grouping similar targets such as WebLogic domains, SOA infrastructure, and other components into Administration Groups facilitates the application of monitoring settings across a far-flung environment with numerous components. Cloud Control offers quite a bit of flexibility in creating the Administration Groups. You can create logical groupings of targets that support key applications and associate a template collection with the Administration Groups. In fact, the main motivation behind the creation of template collections is to associate them with the Administration Groups. The association of template collections with the Administration Groups ensures the uniform application of monitoring settings to all of a group’s members.
Associating template collections to Administration Groups is an Oracle recommended best practice for managing middleware. As explained earlier, doing this means that your standardized mentoring settings are quickly and automatically applied to targets of different types, including any new targets you add.
Leave a Reply