This chapter provides information about managed targets and contains the following sections:
Each plug-in defines a new type of target that can be monitored by Enterprise Manager. A target, or more specifically, a target instance, can be defined as any entity that can be monitored within an enterprise. Managed targets are the entities that Enterprise Manager can monitor and manage. Examples of targets include hosts, databases, application servers, applications, and listeners. As your environment changes, you can add and remove targets from Enterprise Manager as required.
Many of the commonly-used managed targets have been defined as part of the base Enterprise Manager product. They are preconfigured for management automatically when a management-ready product is installed. Oracle applications, Oracle databases and applications servers, and many of the operating systems that run Oracle products are all classified as management-ready targets.
Even though a target is predefined - for instance, monitoring levels, thresholds, and notification rules - you can still customize Enterprise Manager as required to meet business requirements. That is, you can perform value-added instrumentation to access more of the rich management functionality of Enterprise Manager than is provided with the standard target configuration.
Managed targets include:
Applications that require management
Separately configurable or controllable subsystems of an application
Management components of the underlying application hardware topology
The target model consists of many different types of entities, all of which are modeled as targets to derive the benefit of the security provided by the security infrastructure for targets. For example, systems, services, and groups are all modeled as targets. The line of distinction between the various entities has become blurred over time and has been subsumed into the overall notion of target. So a target could mean different things to different plug-in developers.
To bring distinction and clarity into what kind of entity is actually being modeled, Enterprise Manager employs the concept of high level classes called manageable entity (ME) classes into which each of the entities falls. Each of the classes has a well-defined definition and capabilities. By looking into definitions, you should be able to tell which class the entity being modeled falls under.
For example, today redundancy groups are commonly mistaken for groups, whereas redundancy groups are systems. By following the definition of group and system, it should be clear under which class it falls.
In the Enterprise Manager context, a manageable entity is an entity that Enterprise Manager is capable of managing. This implies that the entity is exposed in some form to end users in the Cloud Control application, and has well-defined attributes and semantics.
There are several classes of manageable entities in Enterprise Manager. Each manageable entity class has the following characteristics:
All manageable entities have the following common capabilities in Enterprise Manager. The capabilities listed under each ME are in addition to the common capabilities.
They are protected by Enterprise Manager security model.
They can all participate in relationships (associations) with other MEs. There are some restrictions that are noted alongside the class.
They have unique identification
Properties (name-value pairs) can be attached to the ME
A manageable entity in Enterprise Manager falls into one of the following classes only. Additional classes can be added in future releases. If an entity does not fall into any of the classes, then it is not a manageable entity or it is a new class of ME that requires support.
Initially when a target is discovered, it is loaded into the Management Repository as an NYM entity. In this state, the entity can have associations but is not managed by a Management Agent yet. The user can go to the discovery results page and assign them to a Management Agent along with required credentials. The entity then goes to managed state. It is possible also to manually initiate target discovery from the Enterprise Manager UI and retrieve or provide all necessary properties of a target and save it as a managed target directly. Automatic discovery is one use case where NYM targets come to existence.
When the plug-in developer registers this target type, they must add the
is_existence type property to the target type metadata file. For more information about type properties and the target type metadata file, see the "Creating Target Metadata Files" chapter of the Cloud Control Extensibility Programmer's Reference on the Extensibility page of the Oracle Enterprise Manager Online Documentation set.
Note:Plug-in developers using the EDK can define new target types that are managed within Enterprise Manager, but this is limited to Managed Targets and Target Components.The ability to define new install home, service, system, or group types is not supported as part of the EDK.
The definition and capabilities of each of the classes are explained in the following sections.
A managed target is a manageable entity in Enterprise Manager that satisfies all the following conditions inherently (and is worth modeling). These are native to the entity and not derived from being represented in Enterprise Manager.
Availability (Up/Down Status).
Configuration attributes that can be collected
Performance attributes that can be measured such as response time
The target type can be registered using target metadata XML described in Section 22.214.171.124, "Target Identity".
In this release of Enterprise Manager, you can rename a target to a new name without loss of history. You should not store an Enterprise Manager target name with any external data associated with the target that might be used later to locate the target in Enterprise Manager.
A group is a collection of manageable entities that allows end users to manage many MEs as a single logical unit. There are no required associations between members of the group – thus, members of a group may or may not have inherent relationships among themselves and with the group containing them. The group will have a contains association with its members.
Users decide membership in the group (direct addition or by criteria), so do not make any assumption on the composition of the group at design time.
The main difference between a system and a group is that a system is a collection of inherently related entities while groups are created mainly to manage many entities as one. Systems cannot contain groups; however, groups can contain systems.
A system is fully formed if all of its underlying targets and the required associations have been discovered. If any of the required target and associations has not been discovered, then the system is partly formed. If the system cannot be created due to underlying logic problems, then the system is broken.
Availability will be computed for fully formed systems only. Charts and topology can be viewed for partly formed or broken systems. Root Cause Analysis (RCA) and other diagnostic utilities can work reliably on fully formed systems only.
A composite target is a target that is composed of a number of related targets that are managed as a group. The related targets are often referred to as children or members of the composite target. As part of your plug-in, you will define the different target types that describe the composite target itself as well as its children target types
The composite target is a natural group of targets, the semantics of which are described in the plug-in itself. Enterprise Manager does not assign any additional semantics to the composite target other than the ability to represent the relationships between the composite and its children visually, either in the target navigator or in the topology view of the composite target. Any other semantics are assumed to be enforced with the plug-in code, either as an aggregation of data into composite metrics, associations between members, or operations (tasks or jobs) that span the composite children.
One typical composite example is that of a redundancy group. In this situation, a series of related targets form a group that is managed as a single composite entity. Each member of the group can also be managed separately as well as part of the group (composite) itself. The specific semantics of how the group operates, such as how failover occurs, how monitoring information is aggregated, and so on, are part of the logic defined within the plug-in. Enterprise Manager does not attempt to infer additional semantics from the composite definition, but it can display the set of members of the composite together and provide services of managing the associations between the members and other targets, associations between the members and the composite target itself and for retrieving membership or association details about the composite target or its members.
In addition to composite targets, this release of the EDK adds support for the definition of a system target type as part of a metadata plug-in. While a composite target allows you to define a set of related targets that should be managed as a group, a system target type includes support for additional semantics provided by Enterprise Manager.
System targets are the basis for defining monitored services, which are the components of applications that run on the IT infrastructure. The IT infrastructure is modeled as a series of systems on which the services run. As such, Enterprise Manager supports the ability to view and monitor a system, and perform operations such as Root Cause Analysis of service failures for services that run on the system.
A service models the access point of a business function offered by a target or system. A service can be associated with zero or one system. A service can use beacons or system components to compute availability and performance data.
For example, the e-mail service in the Beehive Application System uses a beacon transaction, which uses the SMTP protocol to check e-mail availability. Alternatively, service availability for a end user system can be defined by defining the key components of the system on which the service depends and then specifying the condition ALL key components up or ANY key component up.
A remote web service is an example of a service not associated with a system that Enterprise Manager manages. Enterprise Manager can still monitor the service using a beacon transaction to checks its availability and performance even though the underlying system is an infrastructure that is not known to or otherwise managed by Enterprise Manager.
This allows Enterprise Manager users to include remote services in the topology of their applications and to include the monitoring of those services as part of the application monitoring solution.
The following table represents the type of capabilities that are supported for each of the various entity types that Enterprise Manager supports. Members only means that the operation is on the members of the ME and not on the ME itself. For example, Jobs can be run against members of the group but not on the group itself even though the job is submitted against the group.
|Capability||Target||NYM||Group||Systems (Discovered)||Systems (user defined)||Service|
|Availability (up/down status)||Y||N||N||Y (optional)||N||Y|
|Performance Metrics (collected and rollup)||Y||N||Rollup only||Y||Rollup only||Y|
|Configuration Collections (save/compare operations)||Y||N||N||Y||Members only||Y|
|Compliance Rules and Standards||Y||N||Y||Y||Y||Y|
|Can participate in associations||Y||Y||Restricted to contains with members||Y||User-defined only||Y|
|Jobs||Y||N||Members only||Y||Members only||Y|
|Events||Y||N||Members only||Y||Members only||Y|
|Patching, Provisioning||Y||N||Members only||Y||Members only||Y|
|Blackouts||Y||N||Members only||Y||Members only||Y|
|Templates||Y||N||Members only||Y||Members only||Y|
|Automatic Discovery (entity can be discovered or constructed automatically by Enterprise Manager)||Y||Y||N||Y||N||Y|
|Privilege Propagation (propagate privileges to members)||N||N||Y (optional)||Y (optional)||Y (View only)||N|