Oracle Enterprise Manager Key Concepts and Subsystems

(For more resources on Oracle, see here.)


The term 'target' refers to an entity that is managed via Enterprise Manager Grid Control. Target is the most important entity in Enterprise Manager Grid Control. All other processes and subsystems revolve around the target subsystem. For each target there is a model of the target that is saved in the Enterprise Manager Repository. In this article, we will use the terms target and target model interchangeably.

Major building blocks of the target subsystem are:

Target definition:

All targets are organized into different categories, just like the actual entity that they represent, for example there is WebLogic Server target, Oracle Database target, and so on. These categories are called target types.

For each target type there is a definition in XML format that is available with the agent as well as with the repository. This definition includes:

  • Target Attributes: There are some attributes that are common across all target types, and there are some attributes specific to a particular target type. The example of a common attribute is the target name, which uniquely identifies a managed entity. The example of a target type specific attribute is the name of a WebLogic Domain for a WebLogic Server target. Some of the attributes provide connection details for connecting to the monitored entity, such as the WebLogic Domain host and port. Some other attributes contain authentication information to authenticate and connect to the monitored entity.
  • Target asociations: Target type definition includes the association between related targets, for example an OC4J target will have its association defined with a corresponding Oracle Application Server.
  • Target Metrics: This includes all the metrics that need to be collected for a given target and the source for those metrics. We'll cover this in greater detail in the Metrics subsystem.

Every target that is managed through the EM belongs to one, and only one, target type category. For any new entity that needs to be managed by the Enterprise Manager, an instance of appropriate target type is created and persisted in the repository.

Out-of-the-box Enterprise Manager provides the definition for most common target types such as the Host, Oracle Database, Oracle WebLogic Server, Seibel suite, SQLServer, SAP, .NET platform, IBM Websphere application server, Jboss application server, MQSeries, and so on. For a complete list of out-of-the-box targetsOut-of-the-box Enterprise Manager provides the definition for most common target types such as the Host, Oracle Database, Oracle WebLogic Server, Seibel suite, SQLServer, SAP, .NET platform, IBM Websphere application server, Jboss application server, MQSeries, and so on.For a complete list of out-of-the-box targets please refer to the Oracle website.

Now that we have a good idea about the target definition, it's time we get to know more about the target lifecycle.

Target lifecycle

As the target is very central to the Enterprise Manager—it's very important that we understand each stage in the target life cycle.

Please note that not all the stages of the lifecycle may be needed for each target. However, to proceed further we need to understand each step in the target lifecycle. Enterprise Manager automates many of these stages, so in a real life scenario many of these steps may be transparent to the user. For example, Discovery and Configuration for monitoring stages are completely automated for the Oracle Application Server.

Discovery of a target

Discovery is the first step in the target lifecycle. Discovery is a process that finds the entities that need to be managed, builds the required target model for those entities, and persists the model in the management repository. For example, the discovery process executed on a Linux server learns that there are OC4J containers on that server, it builds target models for the OC4Js and the Linux server, and it persists the target models in the repository.

The agent has various discovery scripts and those scripts are used to identify various target types. Besides discovery, these scripts build a model for the discovered target and fill in all of the attributes for that target. We learnt about target attributes in the previous section.

Some discovery scripts are executed automatically as a part of the agent installation and therefore, no user inputs are needed for discovery. For example, a discovery script for the Oracle Application Server is automatically triggered when an agent is installed. On the other hand, there are some discovery scripts where the user needs to provide some input parameters. An example for this is the WebLogic server, where the user needs to provide the port number of the WebLogic Administration Server and credentials to authenticate and connect to it. The Enterprise Manager console provides interface for such discovery.

Discovery of targets can happen in two modes—local mode and remote mode. In local mode, the agent is running locally on the same host as the target. In remote discovery mode, the agent can be running on a different host. All of the targets can be discovered in local mode and there are some targets that can be discovered in remote mode. For example, discovery of WebLogic servers can happen in local as well as remote mode.

One important point to note is that the agent that discovered the target does the monitoring of that target. For example, if a WebLogic Server target is discovered through a remote agent it gets monitored through that same remote agent.

Configuration for monitoring

After discovery the target needs to be configured for monitoring. The user will need to provide some parameters for the agent to use to connect to the target and get the metrics. These parameters include monitoring credentials, host, and port information, using which, the agent can connect to the target to fetch the metrics. The Enterprise Manager uses these parameters to connect, authenticate, and collect metrics from the targets. For example, to monitor an Oracle database the end user needs to provide the user ID and password, which can be used for authentication when collecting performance metrics using SNMP protocol.

Enterprise Manager Console provides an interface for configuring these parameters.

For some targets such as Application server, this step is not needed, as all the metrics can be fetched anonymously. For some other targets such as Oracle BPEL Process Manager, this step is needed only for detailed metrics; basic metrics are available without any monitoring configuration, but for advanced metrics monitoring, credentials needs to be provided by the end user. In this case, monitoring credentials are the user ID and password, used to authenticate when connecting to BPEL Process Manager for collecting performance metrics.

Updates to a target

Over a period of time, some target properties, attributes, and associations with other targets change—the EM target model that represents the target should be updated to reflect the changes. It is very important that end-users see the correct model from Enterprise Manager to ensure that all targets are monitored correctly. For example, in a given WebLogic Cluster, if a new WebLogic Server is added and an existing WebLogic Server is removed—Enterprise Manager's target model needs to reflect that. Or, if credentials to connect to WebLogic Admin Server are changed—the target model should be updated with new credentials. The Enterprise Manager console provides UI interface to update such properties.

If the target model is not updated there is a risk that some entity may not be monitored, for example if a new WebLogic server is added but the target model of domain is not updated, the new WebLogic server will not be monitored.

Stopping monitoring of a target

Each IT resource has some maintenance window or planned 'down-time'. During such time it's desirable to stop monitoring a target and collecting metrics for that resource. This can be achieved by putting that target into a blackout state. In a blackout state, agents do not collect monitoring data for a target and they do not generate alerts. After the maintenance activity is over, the blackout can be cleared from a target and routine monitoring can start again. Enterprise Manager Console provides an interface for creating and removing blackout state for one or more targets.

(For more resources on Oracle, see here.)


Enterprise Manager performs round-the-clock monitoring of targets by collecting the performance data. Unmanned monitoring is one of the key features of Enterprise Manager Grid Control. Monitoring subsystem is a crucial piece in unmanned monitoring of targets. Let's learn about monitoring subsystem.

We will now see the major building blocks of the monitoring subsystem in greater detail.


A managed resource can expose performance indicators through various interfaces like JMX, SNMP, and so on. For example, WebLogic Server performance indicators are exposed through a JMX interface. Enterprise Manager provides executables that can access performance data from most of the standard interfaces. These executables are called fetchlets. There is one fetchlet for each data access mechanism. Some useful fetchlets are SNMP, JMX, and URLXML fetchlets, which can be used to access data from SNMP interface; JMX interface, and URL interfaces respectively.

For a complete list of available fetchlets, please refer to the Enterprise Manager documentation.

Metrics definition

Metrics is the performance data that is collected from each target at fixed intervals and can also be collected on demand. The metrics definition for a target type defines all performance indicators that need to be collected and what fetchlet should be used to collect those indicators. This is defined in a template file. This template file is very important and we'll be referring to this file by the term target metadata.

For a given target type, the collection frequency of the metrics is defined in another template and we refer to that as a target collection file.

Metric collection and aggregation

To monitor performance indicators of a given target, metrics are collected by an agent, as per the definition in the target metadata file, and are collected as per the frequency defined in the target collection file.

After collection, the data is kept at a staging location; from there it is uploaded into the repository at fixed intervals. All performance metric data is persisted in the repository and can be used to analyze a system's performance over a period of time.
For coarse views, these metrics are rolled up every hour and every 24 hours. Data aggregated every hour is kept for 31 days and data aggregated for 24 hours is kept for 365 days. Raw data received from the agent is only kept for seven days. Data purge policies can be configured to suit user needs.

The following screenshot shows one such example, detailing the average execution for one of the web services deployed on a WebLogic Server. From this view, the user can see real-time data or historical data.

Metric alerts

Enterprise Manager can use metric data that is persisted in the repository in two ways. Firstly, the user can see and analyze data over a period of time. Secondly, any time a particular data value crosses acceptable limits; Enterprise Manager can keep track of such instances.

The user can define thresholds to in turn define the acceptable limits of performance metrics. Enterprise Manager supports two levels of thresholds for the metrics—warning and critical threshold. For example, a CPU % usage metric can have 70% as warning and 90% as critical threshold. Enterprise Manager provides default thresholds for many metrics that the user can customize. For metrics where no thresholds are defined, the users can define them.

Whenever a metric data value crosses the threshold, an alert is generated and stored in the Management repository. If a warning threshold is violated; a warning alert is generated, and if a critical threshold is violated; a critical alert is generated. These alerts can be used for generating some form of notification.

Monitoring templates

Monitoring template is a construction, using which, one can define the thresholds for a target type, and can apply this template to multiple targets of the same type. When there are multiple targets of same type, setting thresholds for all such targets can be a tedious task. Monitoring templates can make it simpler by providing one central place to define thresholds for all targets of the same type.

System Administrator can also define default-monitoring template for a given target type. Once a template is marked as default for a target type, all new targets of the same type will automatically get the same thresholds as defined in the template.

Recommendation: Define default-monitoring template for all target types in the datacenter and add metric thresholds to the template. This will ensure that all targets of the same type will have the same thresholds.

Configuration management

Enterprise Manager collects configuration data of targets to provide configuration management support. For collection of configuration data, Enterprise Manager uses the same mechanism as performance metrics, that is; all the configuration to be collected and mechanisms to collect are defined in target metadata, and frequency of configuration collection is defined in target collection. Agent collects configuration data and uploads it into the repository.

Though the data collection mechanism is the same for performance and configuration data, the usage of configuration data is very different from the usage of performance data. Configuration data is used for ensuring configuration compliance and configuration change tracking.

Let us look into building blocks that provide configuration compliance and change tracking.


Enterprise Manager Grid Control provides policy subsystem for configuration and security compliance.

Policy is a construct to define configurations and security recommendations for a given target type. For example, a security policy for OC4J recommends that all data sources should not have passwords in clear text; a configuration policy for WebLogic server recommends that the server should be running in production mode. The Enterprise Manager uses these policies to periodically check for conformance across multiple targets in a given datacenter.

Enterprise Manager comes with lots of out-of-the-box policies and users can customize those policies and define new policies; Enterprise Manager Console provides interface to customize or define new policies.

Policies are defined for a target type and can be enforced for all targets of a given type or only for some targets of a given type. The end user can configure what policies need to be enforced for a given target. For example, if there is a policy for a host target type that mandates that only port 80 should be open on all servers —the System Administrator may decide not to enforce that policy for a new server that is used for developmental activity.

Each policy definition is associated with a severity level. There are three severity levels, which are Informational, Warning, and Critical. Enterprise Manager evaluates these policies against the configuration data that is collected from the targets. Any violation of these policies is saved in the repository and can be used for sending out notifications.

We learnt in an earlier section how monitoring template can be used to set thresholds across multiple same targets. Policies can also be added to a monitoring template along with a metric threshold.

Recommendation: Define default-monitoring template for all target types in the datacenter and add metric thresholds to the template. This will ensure that all targets of the same type will have the same thresholds.

Configuration snapshot

Configuration snapshot of a target is a set of all configuration parameters at one point in time. Enterprise Manager keeps all related configuration for a target as configuration snapshot.

Enterprise Manager keeps a track of configuration changes by using configuration snapshots. When uploading a new configuration snapshot, it compares the new configuration snapshot with the existing snapshot, and the changes are saved separately in the repository.

Besides keeping track of changes, configuration snapshot can be used to compare the configuration of one target with multiple targets of the same type.

Comparing configurations is a critical part of any IT operations and troubleshooting. It is common to find that an application will work in one environment and not work in another environment. The fastest way to troubleshoot this is to compare the configuration between two environments, but configuration comparison can be a dreary job and issues are likely to be missed by the human eye, as configuration is spread out in multiple files across servers.

The following screenshot shows one such comparison of configuration snapshots of two WebLogic servers, where you can see the difference in heap parameters:


Job system of Enterprise Manager provides support for scheduling the operations and executing an operation as per the schedule. Enterprise Manager provides a framework where a unit of work to be done is defined as a job, these jobs can be scheduled to run on multiple targets and the outcome of that is persisted in the repository. For the scheduling of a job, Enterprise Manager console provides an interface, using which the user can specify the parameters to be passed on to the job and the targets where the job needs to be executed.

For example, the Database backup job contains all the details on how to perform database backup. Enterprise Manager console provides an interface to select on which database this operation needs to be run, what is the backup mode (online, offline), and what is the schedule to run this job.

Success or failure of the job execution can also be sent out as a notification.

Major building blocks of job system are as follows:

  • Job Definition: Job definition contains the parameters required by the job and the sequence of steps to be performed. It provides rich support for the orchestration of multiple steps in a job, like conditionally running some steps based on the outcome of earlier steps, waiting for one step to complete before starting the next and so on.

    Out-of-the-box Enterprise Manager provides many job definitions, like Oracle Application Server backup, WebLogic start/stop, and so on.

  • Job Library: To run a job, System Administrators provide input parameters for a job, and a schedule to run the job. Sometimes the Administrator who can provide input parameters is different from the Administrator who schedules the job.

    Job library provides the support where one Administrator can fill in all parameters in the job and save it in the job library; another Administrator can just pick up a job and schedule the execution of job. This feature is very useful when there are multiple levels of System Administrators, super Administrators can define the jobs parameters and save in the job library, and Operators can execute/schedule the jobs.

  • Multi-tasking jobs: Often, Administrators need to schedule multiple jobs in a particular sequence. Enterprise Manager provides "Multi-task job", using this, the Administrator can combine multiple jobs and run them as one job. Enterprise Manager console UI provides an interface for defining multi-task jobs where the user can define what jobs need to be run and in what order.?

    Multi-task jobs can also be saved in job library.

(For more resources on Oracle, see here.)

Notification system

As we saw in the earlier sections, Enterprise Manager collects monitoring and configuration information round-the-clock, and schedules the job at a specified time. All of these activities continue to happen even when nobody is actively looking at Enterprise Manager. Whenever required, System Administrators can see the history of metric alert, policy violation or job results. But there are some alerts, policy violations, or job results that need immediate attention. Enterprise Manager provides notification framework, and by using this, notifications for alerts, policy violations, and job failures can be sent out.

Major building blocks of Notification system are:

  • Notification Methods

    Enterprise Manager provides support for various notification methods that include SNMP trap, emails, and so on. Enterprise Manager console provides an interface for configuring the notification methods. For example, console provides an interface to configure SNMP notifications, where the user can provide details like SNMP community, SNMP host, SNMP port, and so on.

  • Notification Rules

    System Administrator should get paged only for the critical resources and only for the critical performance indicators or policy violations. Enterprise Manager provides support for Notification rules AND using that, Administrators can define for what type of events a notification should be sent out and which notification method should be used.

  • Provisioning

    The provisioning subsystem provides support for automating provisioning of software on multiple targets. Using provisioning subsystem, the System Administrator can do initial provisioning of software, for example provisioning of Linux operating system and RAC database on a new host. Provisioning system also provides support for provisioning software from a reference installation, where Enterprise Manager can clone software from reference environment to new environment. For example, if a database instance is running on host1, Enterprise Manager can provision a new database instance on host2 by cloning the database instance on host1.

    Major building blocks of provisioning subsystem are:

    Deployment procedures

    Deployment procedures define the steps that need to be executed to achieve a particular objective. For example, the deployment procedure for J2EE server installation defines all of the steps that need to be executed to install a J2EE server. The provisioning subsystem provides out-of-the-box deployment procedures for most common provisioning operations, it also provides support to customize existing deployment procedures or to define a new deployment procedure.

    Provisioning subsystem also provides support for scheduling and executing these deployment procedures. Enterprise Manager console provides an interface for scheduling deployment procedure and monitoring the status of scheduled deployment procedure.

    Software library

    Software Library is a central repository to keep installable software and gold images of software. Provisioning framework uses Software Library for storing gold images and provisioning new software from the images. For example, the provisioning subsystem can build a gold image from an existing Linux setup and store it in the software library. At some later point in time the provisioning subsystem can use the stored gold image to provision a new Linux host.

    Software library also provides support for versioning, maturity levels (beta, production) for installable software and gold images. Enterprise Manager Console provides interface to browse the contents of software library, and update the version, maturity level of software, and gold images.

    Service Level Management

    We saw in earlier sections that using target subsystem and monitoring subsystem we can monitor any resource in a datacenter. We can see the availability of any IT resource by looking at the history of status metrics. In the traditional approach, the history of status metric is good enough to measure system performance.

    In most of the datacenters today, IT systems performance is measured by Service Level Agreements (SLA). SLA includes the performance indicators to be used, thresholds for the performance indicators, and expected availability of the IT resource in terms of the performance indicators. For example, one sample SLA for a Linux host includes CPU usage and IO rate as performance indicator; it also includes acceptable thresholds for CPU and IO rate. This SLA measures the availability of Linux servers in terms of CPU usage and IO rate. Enterprise Manager provides support for defining and monitoring service level agreements. It provides necessary backend support and console UI, using that, SLA can be defined and stored in the repository. It also provides a console interface to monitor SLA performance over a period of time.

    The next screenshot shows the interface for defining the SLAs. You can see that a user can select the performance indicators to be included in SLA definition.

    Information publishing

    There is lot of useful data stored in the enterprise repository; the information-publishing system provides a means to publish this data in various useful formats. Report is a construct that is used for publishing data from the Enterprise Management repository.

    Enterprise Manager provides a lot of out-of-the-box reports, that the user can customize or use as-is. For example, a report on all policy violations, or a report on all metric alerts, or a report on all configuration changes. Besides these reports, the user can create new reports through the Enterprise Manager console.

    We will now learn about the major building blocks for Information Publishing System.

    Report definition

    Report definition contains details like what data should be shown, how to get that data, layout of the report, parameters for the report, and at what frequency the report should be generated. For example, a particular report provides details about the performance of a BPEL process, the data for this report is shown in tabular format and one pie chart and this report is generated every 24 hours, this report is also emailed out to some specific email ids.

    Report element

    Report elements are reusable components that users can include in the report definition when defining new reports. For example "Table from SQL" element can be used to extract data from repository, and to use this element the user needs to provide a query. At runtime this query is executed against the repository and the data is inserted into the report.

    Information publishing system provides support for scheduling of the reports, using that the user can define a schedule from the console to generate the reports. Generated reports are saved in the repository. Also, these reports can be sent out by emails.


    In this article, we learnt about the key subsystems of Enterprise Manager Grid Control. We learnt about the major building blocks for each of the subsystems. Here are the key takeaways from this article.

    • Users should be aware of subsystems of enterprise software.
    • Target subsystem provides support for target type definition and target lifecycle. Target type definition contains attributes, metric definition, and associations with other targets.
    • Monitoring subsystem provides support for collecting metrics, aggregating metrics, and raising alerts.
    • Configuration management provides support for policy definitions and conformance of policies in datacenter; any non-conformance is raised as policy violation.
    • As best practice, you should use monitoring templates to define the metrics threshold and policies across targets.
    • Job system provides scheduling mechanism. Job library provides ready-run jobs where the parameters are already filled in and any operator can execute the jobs. You can use Multi-task jobs to chain multiple jobs and run them as one job.
    • You can define the alerts, policy violations, and job statuses for which you want notifications to be sent out for.
    • Provision subsystem can be used to provision software from installation media or reference installations.
    • Service Level Agreements (SLA) can be defined and saved in the repository. Enterprise Manager provides a view of SLA performance over a period of time.
    • You can use information publishing system to publish pre-defined reports or create your own reports. Enterprise Manager console provides GUI to define new reports. Reports can be scheduled, and all generated reports can be persisted in the repository. Additionally these reports can be sent out via email.

    We have covered the key subsystems of Enterprise Manager Grid Control, so now we have a good insight into how these subsystems work and how we can customize them.

    Further resources on this subject:

    You've been reading an excerpt of:

    Middleware Management with Oracle Enterprise Manager Grid Control 10g R5

    Explore Title