Skip Headers
Oracle® Enterprise Manager Cloud Control Extensibility Programmer's Guide
12c Release 4 (12.1.0.4)

E25159-10
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

3 About Managed Targets

This chapter provides information about managed targets and contains the following sections:

3.1 Introduction to Managed Targets

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

3.2 What's New in Managed Targets?

Metric Extensions are the next generation of user-defined metrics, enabling you to extend Enterprise Manager to monitor conditions specific to the enterprise's environment by creating new metrics for any target type. A migration feature is provided to enable migration of existing user-defined metrics to Metric Extensions.

Additional enhancements include:

  • Improved support for data collection mechanisms beyond operating system and SQL queries.

  • Create and update lifecycle support for metrics, including versioning and deployment.

  • Implicit support for all features that support metrics, such as the System Dashboard and reporting capabilities.

  • Support for composite and system target types

3.3 About the Target Model

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.

3.3.1 Manageable Entity (ME)

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:

  • Definition: Specifies the rules and inherent attributes of the entity class

  • Representation: Deals with how entities of that class are represented in the Enterprise Manager data model and exposed to end users

  • Enterprise Manager Capabilities: Features and capabilities that Enterprise Manager provides to entities of that class

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.

  • Managed Targets

  • Services

  • Systems

  • Groups

  • Target components

A manageable entity can be in multiple states, as outlined below.

  • Managed state or Not-Yet Managed (NYM) state

    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.

  • Existence only state

    A discovered entity that Oracle does not support will have an existence only state. It is similar to an NYM entity except that it cannot be managed by Oracle.

    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.

    http://www.oracle.com/pls/em121/homepage
    

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.

3.3.2 Managed Target

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

Hosts, databases, listeners, and so on, are examples of managed targets.

The target type can be registered using target metadata XML described in Section 3.3.2.1, "Target Identity".

3.3.2.1 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.

3.3.2.2 Lifecycle Status

The lifecycle status property is set by the end user to one of the following values:

  • Development

  • Test

  • Release

  • Production

For example, this property can be used in the priority processing of events. You do not have to do anything to make use of this property.

3.3.3 Groups

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.

Groups can be assembled by end users in an ad-hoc manner or by specifying specific business criteria (for example, by Line of Business, test versus production, target version, and so on).

There are two different types of groups from privilege perspective:

  • Normal group

    Only view privilege on the group is propagated to the members.

  • Privilege Propagating group

    Any privilege on the group is propagated to the members.

3.3.4 Systems

A system is a collection of inherently related manageable entities, which together provide one or more business functions or services.

The members of a system have well-defined relationships. These relationships are specified by associations.

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.

3.3.4.1 System State

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.

System operations are possible only on fully formed systems. System operations can be done on partially formed systems. It is your decision to support operations on partly-formed systems.

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.

3.3.5 Composite Targets

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.

3.3.6 System Targets

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.

3.3.7 Services

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.

3.3.8 Management Capabilities Supported

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
Assoc Derivation Y N N Y N 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
Privileges Y Y Y Y Y Y
Privilege Propagation (propagate privileges to members) N N Y (optional) Y (optional) Y (View only) N
Metric Extensions Y N N Y N Y