Oracle Enterprise Manager Grid Control 11g R1: Business Service Management — Save 50%
A Hands-on guide to modeling and managing business services using Oracle Enterprise Manager 11g R1 using this Oracle book and eBook
This article by Ashwin Kumar Karkala & Govinda Raj Sambamurthy, authors of Oracle Enterprise Manager Grid Control 11g R1: Business Service Management, will introduce the enterprise IT modeling concepts such as passive and active monitoring capabilities of the OEM. It will also provide an overview of the architecture of OEM. It will cover definitions of concepts such as Oracle Management Server (OMS), OEM agent, targets, metrics, alerts, beacons, and service tests. This will be followed by an introduction to system and service target types in OEM. The article will subsequently cover the definitions of various features such as availability management, performance management, and service level management. Finally, it will conclude with a brief note on the various product focus areas and the management packs within OEM that enable Business Service Management (BSM).
|Read more about this book|
(For more resources on this subject, see here.)
IT staff in any enterprise need different perspectives to get a comprehensive view of the health of the various business services and the underlying IT infrastructure. In the previous article, the various models of visualizing the IT infrastructure were introduced. Oracle Enterprise Manager (OEM) is one of the industry leaders in the system management products arena. OEM 11gR1 addresses the complexities of managing today's IT infrastructure by providing different models for visualization.
Oracle Enterprise Manager concepts
OEM is a software offered by Oracle that provides a single unified platform for modeling and managing enterprise data centers. Although targeted primarily towards managing the Oracle suite of products within an enterprise, it also has built-in capabilities to model and manage a limited set of widely adopted non-Oracle software products. It provides comprehensive monitoring and management capabilities for the entire Oracle Grid within the enterprise. It covers all aspects of the Oracle stack starting from the physical host management to database management. It also includes management for Oracle middleware components and the applications running on it. As discussed in the previous article, the mindset of IT executives has shifted more towards business enablement using IT infrastructure rather than just IT operations management. However, the shift in focus does not mean that IT operations can be ignored. In fact, companies are now keen to understand the impact of IT operations on their business service offerings.
Therefore, in the current context, an enterprise-wide IT infrastructure management product must be able to provide modeling and management functionalities for business services, along with excellent capabilities around the management of the day-to-day IT operations. OEM is one of the few products that provides complete capabilities around service modeling as well as tools to assess the impact of IT operations on the business service.
Let's now look at some of the key features provided by OEM. OEM provides discovery, monitoring, and management of various pieces of the IT infrastructure. Each of the pieces or entities that need to be monitored and managed is known in the OEM parlance as a target. The above features provide the foundation for the rich set of management capabilities offered by OEM. Therefore, prior to proceeding any further, let's take a cursory look at these features:
- Target discovery: It involves finding, mapping, and then modeling a physical or logical entity in the IT infrastructure in OEM. Each of these entities that are part of the IT infrastructure must be modeled in OEM as one or more targets. The discovery part begins with finding the entity, then mapping it to a particular OEM type, and it ends with the creation of the actual target instance within OEM.
- Target monitoring: It revolves around providing an insight into the basic functioning of the target. For example, target monitoring essentially provides the answer to the administrator's question: "Is the target up, and if so is it performing as well as we expect it to?"
- Target management: It revolves around performing active changes to either the current process status or the configuration of the target. As an example, changing the status of a target process might involve stopping a current process related to the target (or the entire target itself). Similarly, as an example, changes to the configuration might involve changing the number of simultaneous user requests a server might have to handle.
Target modeling and monitoring is the base on which other models can be designed. These higher level models are important and allow administrators to aggregate individual targets into buckets that are more aligned with the business. These buckets are also OEM targets in their own right and are modeled as such. These aggregate targets now allow OEM developers and integrators to build higher level features and capabilities that allow mapping of business priorities onto the IT infrastructure. These aggregate targets are of three main types:
- Group: A group target is a collection of individual targets of the same type. This aggregation is intended to provide a mechanism to monitor and manage targets of the same type. A typical example of such an implementation is a database group. A DBA might be responsible for all the databases within such a group. The group target now presents the administrator with a view of all the databases of concern.
- System: A system target is a collection of individual targets that form the base for providing a business service. While the group target can be viewed as more of a physical aggregation, the system target is intended to provide a functional one. An example of a system target is a website. This system will include disparate targets that are involved as part of the hosting website.
- Service: A service target is a logical target and more often than not, represents the end user functional view of the IT infrastructure. The service model is the one closest to the business view and is used to represent the business functionality provided by the underlying infrastructure. It is therefore the target most likely used to map and subsequently track business priorities. An example of a service target is user authentication service. This service maps to the functional business service of providing user authentication. It might be modeled on an underlying authentication system that represents the physical infrastructure used to provide the functionality. The service target provides a mapping of the business function to the physical infrastructure.
These are very brief examples that are intended to introduce some of the concepts in OEM. A more detailed introduction and a deeper dive into these concepts are provided later in this article.
Flavors of Oracle Enterprise Manager
The OEM product provides features to manage and monitor the IT infrastructure within an enterprise. These features enable the users to perform configuration changes and also monitor the installed products. These installed products need to support the various business functions of the enterprise. It is therefore a reasonable assumption that these products are very complex in nature and need detailed support utilities and console applications to allow administrators to configure and manage them. To elaborate further with an example, let's consider the case of an Oracle database installation. The database might be installed in a cluster to provide high availability and failover support. The database product by reason of having evolved over a couple of decades will expose many different installation and subsequent configuration options. In fact, the configuration of a database is very specific to the business function that it needs to support. There can be hundreds of options that an administrator needs to tweak in order to get the database configured just right. To support the above installation and configuration options of a specific database instance, the database comes equipped with a set of command-line utilities and also a console application.
As one can imagine, the command-line utilities and the console application are very specific to the database version and provide a means to view and change the configuration parameters. Just as any other product in the market, the database product also evolves with time. This evolution results in newer versions of the product with features that cater to the demands of the administrators, the end users, and the applications that run on it. Just as the old features, these new features also need to be configured and tuned to the environment in which the database will be installed. Therefore, along with the newer features, the associated command-line utilities and the console application that allows the administrators to view and configure the parameters also needs to change. Hence, the console application is closely tied to the version of the database. This console application is also a favor of OEM and is referred to as Oracle Enterprise Manager Database Control or OEM DB Control in short.
All the preceding arguments for the database product also hold true in the case of a middleware application server. In case of the application server as well, there are a set of command-line utilities and a console application that is deployed out-of-the-box that provides detailed configuration options. The console application and the command-line utilities are very specific to the application server and provide the ways and means to view and change any and all of the configuration parameters that are exposed by the middleware server. Just as in the case of the database, the console application that configures the various parameters of the middleware server is another favor of OEM and is referred to as Oracle Enterprise Manager Application Server Control or OEM AS Control in short. While AS Control is responsible for management of OC4J targets, Oracle Fusion Middleware (FMW) Control provides management capabilities for Oracle WebLogic server and the middleware components that are deployed on it.
We have now seen two favors of the OEM product that provide configuration support for the Oracle database and the Oracle middleware servers. Both these favors are very specific to the respective products that they come bundled with. Each installation of the database of the middleware server will be associated with its corresponding installation of the configuration application and utilities. From this, it is evident that each instance of these favors of OEM is only aware of the product installation that they are configured.
This leaves us with a huge gap at the wider enterprise level. This gap can be bridged by a favor of OEM that sits above the other favors and provides a wider view of the entire enterprise IT infrastructure. At the enterprise level, there might be hundreds, if not more, of these individual database and middleware server installations. It is also very likely and indeed is the case that these installations are of different versions. As an example, the data center of a large enterprise might have a few hundred installations that span the 10g and the 11g versions of the database. Similarly, there might be a few hundred installations of Oracle OC4J and WebLogic middleware servers. The OC4J servers versions can be 10.3.3 or 10.3.4 and the WebLogic servers can be of versions 10.3.0 and beyond. Unlike the previous two favors of OEM, this favor must not only be able to manage different product installations, but also seamlessly manage the different version of these products. This favor of OEM is referred to as Oracle Enterprise Manager Grid Control or OEM GC in short.
The Grid Control favor of OEM is centrally installed within the data center and is capable of providing a business view of the infrastructure. As seen by this description, this favor is not specific to one product, but is a step higher and looks at all the products in the enterprise data center. It is capable of reporting summary status of the infrastructure in a manner that is aggregated by the business function. The user can then drill down to a business service of interest, and then further drill down to any of the target instances from this view. This flow is much more meaningful as it not only provides a business service mapping of the infrastructure, but also provides significant information for the administrator to drill down to the correct target instance in case of service outage issues.
The following image provides a pictorial view of the three different favors of OEM:
Let's now look at each of these favors and their functionalities in more detail.
OEM Database Control
OEM Database Control or just DB Control is a web-based console application that is shipped and optionally installed when an Oracle database product is installed. It may be noted right here that this favor of OEM is optional during the installation of the Oracle database product. In its absence, various command-line tools and utilities must be used to configure and manage a single database instance. However, the DB Control application provides a graphical and more intuitive view of the database installation.
The DB control favor of OEM primarily supports the database and the listener targets, and provides the following key set of features to the DBAs:
- Database status: It shows the current status of the database and listener instances.
- Administrative tasks: It provides graphical UIs to the DBAs to perform routine administrative tasks such as management of table spaces, indexes, and tables.
- Backup recovery: It provides graphical UIs to the DBAs to configure a database instance for backup. It also allows the DBAs to manage the backup snapshots by setting retention policies. It is also capable of restoring the database using any of the available backup snapshots. Apart from a full database backup, it also provides UIs to export and import data from a specific schema of an instance.
- User security management: It provides graphical UIs to the DBAs to view the current set of users and their corresponding roles. It also provides an exhaustive set of views to manage and audit these database users and roles.
- Process control: It provides graphical UIs to the DBAs to view and edit all the initialization and memory parameters of the database. It supplements this by also allowing the DBAs to stop and restart the individual instances of the database.
- Monitoring and tuning: It provides graphical UIs to the DBAs to monitor the availability and performance in real time and set thresholds on the key performance indicators of the database instance. When these thresholds are violated it raises alerts and can send e-mails to the configured administrative accounts. It also provides UIs that enable the DBAs to make use of the tuning features provided with the database.
More information on the latest version of OEM DB control is available at:http://download.oracle.com/docs/cd/E11882_01/server.112/e10897/toc.htm
OEM application server and Fusion Middleware Control
As seen above with the database, this favor of OEM is used for viewing and managing a single middleware instance. Under the Oracle middleware family, there are many suites of products available. Each of these comes bundled with its own console application that is used to view, configure, and manage the individual installations. Oracle middleware products run on two different application servers. These are Oracle Container for J2EE (or OC4J in short) and WebLogic Application Server. The console application shipped with the suite of products that run on OC4J is called OEM Application Server Control. The console application shipped with the suite of products that run on WebLogic is called OEM Fusion Middleware Control (or OEM FMW Control in short). It may be noted at this time that a number of products that run on the OC4J server, are deprecated and are replaced by the suite of products running on the WebLogic server.
The FMW Control favor of OEM primarily models the WebLogic domain, server, application deployments, and the suite of applications that provide the general middleware functionality. A comprehensive listing of the features of FMW Control is outside the scope of this article. However, some of the key features provided to the middleware administrators are listed as follows:
- Status tracking: It shows the current status of all the middleware targets that are present in the installation.
- Process control: It provides graphical UIs to the administrators to stop and start the individual pieces of the middleware installation.
- Monitoring and tuning: It provides graphical UIs to the administrators to monitor in real time and set thresholds on the key performance indicators of the middleware targets. When these thresholds are violated it raises alerts and can send e-mails to the configured administrative accounts.
- configuration pages: It provides detailed graphical UIs to the administrators to view and modify all the parameters of the applications and processes that form a part of the middleware suite of products.
- Diagnostic tools: It provides graphical UIs that help administrators perform diagnostic activities for some of the products in the middleware suite.
More information on the latest version of OEM FMW control is available at: http://www.oracle.com/technetwork/middleware/docs/middleware-093940.html
OEM Grid Control (GC)
This favor of OEM works at the enterprise level and primarily focuses on managing the entire Oracle grid of products. It works one step above the DB Control and the FMW Control favor of OEM. While these two favors look at each installation, Grid Control looks at the entire enterprise as a whole. The Grid Control favor of OEM can manage the entire enterprise grid and covers most of the Oracle product suites. Apart from this it also comes with out-of-the-box support for some non-Oracle product suites. The Grid Control architecture is extensible by design, and allows third-party vendors and distributors to add support for newer products. These third-party extensions are known as OEM Grid Control Management plugins. Such a model enables external vendors and integrators to add to the breadth of products whose management is supported by OEM Grid Control.
As OEM operates at the enterprise level, it can provide a richer set of models to support mapping business functions and IT operations. At the same time, it can seamlessly link into the individual product controls as required by the administrators. As an example, consider the travel portal. With DB and AS control, while we can certainly monitor each middleware and database server, we cannot configure a perspective that shows the relevant IT infrastructure that is used to provide the portal function. However, by introducing Grid Control we can build this perspective as it has visibility into all the components of the IT infrastructure. At the same time, in case a change is required in the configuration of the database, it has built-in capabilities to navigate to the relevant page in the corresponding DB Control.
Another important distinction is that the Grid Control variety of OEM comes with its own repository where all the model and target data is stored. This repository is also used to store the performance metrics. This implies that Grid Control can provide views and trends of the performance of any component or a composite model. This enables the administrator to get a sense of the system performance on both a real-time and historical basis. By having snapshots of historical configuration and behavior, administrators can also compare these snapshots. In combination with the system and service models, this provides the administrator with a valuable tool to link business service behavior with configuration changes. As an example, consider that end users are reporting a sudden drop in performance on Monday morning as compared to the past Friday. The service administrator knows that there was a maintenance window scheduled during the weekend, but doesn't know what parameters were changed. Using Grid Control the administrator can now compare the current configuration with the snapshot taken on Friday prior to the maintenance. If the comparison shows that database sort cache size was (inadvertently) reduced, the service administrator in conjunction with the DBA can immediately correct this and restore the service to normal levels.
OEM Grid Control provides the following key features:
- Data center level visibility: As it resides and operates at a higher level, it provides insight into the entire data center by providing a comprehensive view.
- Enterprise availability view: Provides an enterprise-level view of the targets that are currently up or down or in any other state.
- Incident management: Provides an enterprise-level view of the various critical and warning alerts as well as policy violations.
- Business modeling paradigms: Provides a richer set of modeling paradigms that enable the IT staff to map business functions to the underlying IT infrastructure.
- Historical data and comparisons: As it comes with its own repository for data storage, it exposes historical views from which trends can be derived. It also allows comparison of data from two different times thus enabling the mapping of service behavior with underlying changes to IT configuration.
- Scheduling of jobs: Using Grid Control administrators can schedule mundane operations such as running scripts and target stop starts. Based on the schedule these operations will automatically be run on the right set of targets. The status of these operations can be tracked independently at a later stage.
- Data center inventory: Most often overlooked, but an important feature of Grid Control is the ability to provide the IT staff with an inventory of the components deployed within the data center. This eliminates the need to maintain complex sheets to track components and their locations.
- Provisioning new components: Grid Control allows the creation and maintenance of a gold image of the configuration of supported products. These images can then be used to automatically provision new systems in the data center.
- Information publishing using reports: Grid Control provides extensive reporting capabilities around the targets configured. This is supplemented by many out-of-the-box report templates that can be applied on targets to automatically publish information related to it. These reports can also be scheduled and e-mailed to the relevant IT staff
- Always on monitoring: The architecture of Grid Control enables it to be always on and monitoring the enterprise grid. Rules can be set throughout the product to identify problems and alert the concerned IT staff based on the targets.
As the features related to BSM are provided by this favor, we will focus primarily on OEM Grid Control.
More information is available at the official OEM Grid Control website at: http://www.oracle.com/technetwork/oem/grid-control/overview/index.html
|A Hands-on guide to modeling and managing business services using Oracle Enterprise Manager 11g R1 using this Oracle book and eBook|
eBook Price: £22.99
Book Price: £36.99
|Read more about this book|
(For more resources on this subject, see here.)
OEM Grid Control 11gR1 architecture
There are great demands on the functionality of an enterprise-wide infrastructure management solution. Not only should the centralized solution be capable of managing tens of thousands of physical entities spread across the landscape that forms the infrastructure, but it also must have the capability to model, monitor, administer, and configure higher-level logical entities that map to business functions. Apart from these, it must also be able to perform complex computations that assess the impact of the various targets on the business functions. Another often ignored demand on the management solution is to take into consideration the geographical spread of the infrastructure landscape. This spread means that data needs to be collected across geographies with differing time zones. Business service models that take into account targets spread across geographies must consider data normalization into a common time zone prior to any computation and impact assessment. The demands of these already complex computations are magnified when we take into consideration the scale of operations across the enterprise.
The key requirement of any management solution including OEM is to be able to provide and perform the above functionalities in a seamless manner. The above demands imply that the architecture must be capable of scaling and performing complex computations, but at the same time it must be simple enough for the administrators and must not overwhelm the enterprise. The success of any management solution will depend on its footprint within the enterprise. A successful management solution must be able to perform complex computations and scale very easily with a simple architecture and a small footprint.
The following image illustrates and introduces the high-level architecture of OEM 11gR1:
The key pieces of the architecture are as follows:
- Oracle Management Agent (Agent): As implied by the name, this is a piece of software installed on a host. This software runs on the host and collects information about the targets on the host. The agent can also be configured to monitor targets on remote hosts. The collected data is then passed onto the management service.
- Oracle Management Service (OMS): This is the brain of the OEM. This is a J2EE web application that provides the management functionality. It acts as the centralized management solution and also acts as the server to which all the management agents upload the collected data.
- OEM Console: This is the user interface that exposes all the management functionalities to the end user of OEM. It's the interface through which the OEM and the end user communicate with each other.
- Oracle Management Repository: This is the central repository that is used by the OMS to store all data. It hosts the complex schema that is used by the OMS to provide the management functionality.
The key parts of the management solution are the management agent, the OMS, and the management repository. The management repository provides the data storage to the OMS. The OMS provides current and future insights into business function and services by looking at the historical data that is stored in this management repository. The OEM console application bridges the gap between the end administrative user and the OMS. It provides views into each of the targets and also allows the user to initiate actions and configuration changes on these targets.
As seen in the preceding screenshot, the Grid Control architecture is distributed in nature and relies on the agents to collect data on the individual hosts. This data is then transferred by the agent to the OMS and aggregated by the OMS at the enterprise level. The OMS has built-in logic that operates on the data to determine target states and performance. By distributing the data collection to individual agents the OMS is freed up to perform more important tasks. Let's now look at each of these architecture pieces in detail.
Oracle management agent
As seen in the previous screenshot, the Oracle Management Agent is a local piece of software running on the host that needs to be managed. The agent is native to the host and it implies that the right agent needs to be downloaded and installed, based on the operating system (OS) installed on the host. The agent can either be installed manually on the host or using the OMS to push the agent onto it. In case the OMS push method is used then the host login credentials must be provided so as to enable a SSH access to the host
In case of the OMS push method, to install the agent, the host login credentials must have sudo or administrative privileges so as to automatically run the root.sh file after the installation.
Once installed, the agent automatically discovers the host and itself as the two targets running on the host. In case other Oracle products are installed and registered in the local Oracle Inventory on the host, then these targets are also automatically discovered.
In local monitoring, the agent is deployed on the host that it is collecting information about. Once installed, it can automatically discover the Oracle products that are installed. Any Oracle product when installed or patched will update this information into the Oracle Inventory. The agent upon its installation will parse this inventory to determine the installed set of products. Based on the product suite and its installed location, it automatically runs the relevant scripts to discover these as OEM targets and uploads this information to the OMS. Upon upload of this information it automatically starts monitoring these installed products.
In case of an automatic discovery of targets upon agent install, the OS user used to install the agent must have the necessary privileges to read the Oracle Inventory location. The discovery will fail and not proceed in case the required permissions are not present.
In the case of local monitoring, an agent is required on every host in the enterprise. This can be a burden on the administrator to not only install an agent on every host, but the agent process itself can consume precious memory and CPU cycles, thus impacting performance. Certain Oracle products, especially in the middleware arena, are built taking into consideration the enterprise management requirements. These products expose the necessary discovery, monitoring, and management capabilities remotely. The Fusion Middleware suite is an example of these kinds of products. In cases where only these products are installed on the host, an existing agent on a different host can be used to discover, monitor, and manage the installation.
In case of remote monitoring, there is no automatic discovery support and the administrator must use the console UI pages to initiate the remote discovery. However, once the discovery is performed, the agent automatically begins monitoring them.
Prior to remote discovery of middleware targets, the middleware servers must be enabled to accept remote management connections. Example: for remote discovery of WebLogic servers, the remote JMX connectors must be enabled.
Oracle Management Service (OMS) and console
The OMS is the brain of the entire Grid Control product. It provides all the functionality spoken in the context of Grid Control thus far. It is also responsible for managing all the communications with the Grid Control Agents. As an example, if an agent is uploading a large amount of data or is very slow to respond, it can disable the agent and indicate the same to the configured set of IT staff. The OMS is developed as a J2EE application and is deployed on the WebLogic server. The installation creates a WebLogic domain with an admin server and a managed server. The OMS application is deployed on the dedicated managed server.
The console application provides the necessary UI pages for the IT staff to interact with the Grid Control product.
Any enterprise IT infrastructure contains numerous disparate components that are geographically distributed across various data centers. These components include both hardware components such as servers hosting different applications, network switches, routers, storage devices, and so on, as well as software components such as operating systems, database servers, application servers, middleware components, packaged applications, distributed applications, and so on. Although these components exhibit various management traits and expose multiple management operations, they also have certain common attributes that need to be monitored by the IT administrators. For instance, the performance characteristics of an Oracle database instance are completely different from those of an Oracle WebLogic managed server. However, both these components still exhibit a common trait of indicating their health or current state. This indicates if the corresponding component functions are available or not. The components themselves and the management of both their common and dissimilar traits form the building blocks of the IT infrastructure management. Each of these components is a monitor-able entity and is represented as a target in OEM. A target represents any component that is managed by OEM. Targets are the fundamental building blocks, on which the different systems management capabilities of OEM are built upon.
Continuing with our travel portal example, each of the components within the travel portal is represented as targets within OEM. These include the Oracle database targets, Oracle WebLogic server targets, the host targets on which these run, and so on. Other than the physical hosts, OEM 11g does not support the management of physical hardware such as network routers, switches, and so on. Hence, a discussion on the management support for those components is beyond the scope of this article.
OEM categorizes targets primarily based on the type of the component that they represent. This classification based on the type of the component is known as a Target Type. The targets are first classified based on the component type and subsequently based on the vendor type. The kind of target types depends on the favor of OEM that is used to manage the target, while target specific favors such as OEM Database Control and OEM Fusion Middleware Control support only database and middleware components to be modeled within their respective consoles. OEM Grid Control provides a wider canvas to support multiple target types within the same console. OEM Grid Control supports all manageable products from the Oracle product family as well as certain popular products within each target type from other vendors. The different kinds of target types supported by OEM Grid Control include:
- Host targets: These represent the physical boxes of hosts that run different products such as databases, application servers, and so on.
- Database targets: These represent the various database server instances that run within the enterprise such as Oracle database instance targets, Oracle Real Application Clusters (RAC) targets, and so on.
- Middleware targets: These represent the various middleware components such as Oracle WebLogic servers, domains, clusters, Oracle application servers (OC4J), service oriented architecture (SOA) components and composites, Oracle coherence server, and Oracle Identity Management (IDM) components. Middleware servers from other vendors such as IBM Websphere Application Server (WAS) and, JBoss Application Server are also supported.
- Application targets: These model various applications such as custom J2EE applications deployed on various application servers, packaged applications such as Siebel, Peoplesoft, Oracle E-biz Suite, other functional applications such as Oracle Business Intelligence products like OBIEE, Oracle Beehive, and so on.
- Composite targets: These include logical target types that provide business abstraction such as systems, groups, and service targets.
- OMS targets: These model the OEM itself as a target. OEM provides Monitor-the-Monitor (MTM) capability and is represented as OMS and repository targets within.
The following image is a screenshot of OEM Grid Control and displays a small subset of the large number of target types supported by OEM Grid Control. This page is referred to as the All Targets page within OEM Grid Control.
The user can navigate to this page by first clicking on the Targets link in the global tab and then subsequently clicking on the All Targets link within the subtab. This page displays all the targets configured within an enterprise. It also displays the current status of the target as well as the corresponding target type.
In any enterprise, there are numerous IT components deployed to support various business functions. The All Targets page has a search feature that helps to filter the targets displayed based on either the target type or target name. In addition, the OEM Grid Control also provides quick filters based on key target types such as databases, middleware components, services, and so on. These quick filters can be viewed by clicking on the Targets link in the main tab and then clicking on the respective filter links within the subtab.
For a component to be modeled within the OEM as a target, certain parameters may need to be provided to monitor the component. The process of modeling a component in OEM as a target by specifying these monitoring properties is known as target discovery. The discovery is a process through which the OEM instance learns about the target, its type, configuration, and so on. It starts periodically monitoring the various performance characteristics. This discovery process helps in representing any physical manageable entity such as a host or an application as a target within OEM. The steps to discover any component as a target within OEM may vary based on the target type. OEM provides the administrator with a wizard or a guided flow. This is a series of steps that ask the administrator to provide the relevant parameters so as to discover a specific component based on the target type. During the discovery of the target, the OEM requires the user to specify the name for the target. The combination of the target name and the target type must be unique. OEM Grid Control supports multiple targets having the same name as long as their target types are different.
The process of discovery can be manual or automated based on the target type. Host targets are automatically discovered by OEM whenever there is an agent deployed on the physical host machine. However, an Oracle Siebel Server instance needs to be manually discovered by the OEM Grid Control before it can be monitored and managed.
The discovery process varies based on the target type to be modeled. The target discovery for a specific component can be initiated from the All Targets page within OEM Grid Control by choosing the appropriate target type in the drop down next to Add label in the All Targets page and then clicking on the Go button.
Agent-monitored and repository targets
In order to model a component OEM must support the type of the component and its attributes. In most cases, OEM uses an Oracle Management Agent to monitor these components as targets. Such targets that are modeled and monitored by an Oracle Management Agent are called agent-monitored targets. Prominent agent-monitored targets include databases, application servers, applications, and so on. For instance, if a database component that stores the inventory information within the travel portal example is to be modeled as a target, the database will need to be monitored by an Oracle Management Agent instance.
The targets to be monitored expose different attributes that can be determined using various protocols such as Simple Network Management Protocol (SNMP), Java Management Extension (JMX), and so on or just by running some shell or batch scripts. An Oracle Management Agent may use one or more of the above techniques to determine the monitor-able aspects of each component by running some executable modules. Such modules within the agent that are executed to monitor the performance characteristics of a target are known as fetchlets. Examples of fetchlets include JMX fetchlets, SNMP fetchlets, OS Line Token fetchlets, and so on. An Oracle Management Agent may use different fetchlets to monitor the various performance aspects of a single target. Also, a single agent instance can monitor multiple targets within a host. For instance, if an agent is deployed on a host comprising an application server and a database, the agent instance is capable of monitoring the corresponding host, application server, and the deployed applications, as well as database targets.
As discussed previously, the Oracle Management Server (OMS) of an OEM instance supports multiple agents monitoring multiple targets. The agents support both local and remote monitoring. During local monitoring, the agent needs to be in the same machine as that of the target. For example, the host targets are always locally monitored and require the agent instance to be deployed in the same host. However, some targets can be monitored remotely by having an agent in a separate machine from that of the target itself. So, remote monitoring does not require the agent and the target to be within the same host boundary. Remote monitoring is very useful in reducing the management overhead on the target server. However, the ability to perform remote monitoring depends on the target type as well as the performance attributes that are to be monitored. Targets such as Oracle WebLogic managed server targets can be monitored remotely using JMX fetchlets.
Certain targets represent logical or functional entities. Composite targets such as groups, system and service targets represent various traits of a business function. As these business functions are not readily available to be monitored as a physical entity, such targets cannot be monitored using Oracle Management Agents. These targets need to be defined within the Oracle Management Server (OMS) and do not require any agents to be assigned for monitoring. Such targets that are defined in the OMS repository and are not monitored directly using an agent are called repository targets. Composite targets within OEM Grid Control are defined as repository targets and do not require any agent for directly monitoring them. However, composite targets comprise other targets, which may include agent-monitored targets.
In general, physical components that participate in a business function are discovered and monitored as agent-monitored targets within OEM Grid Control. These targets are then related together within the OMS and a composition of many such targets is modeled as a repository target to represent a higher level business or logical function.
One of the primary motives for an administrator to deploy a systems management solution in the enterprise is to determine if the components in the data center are up and running. This state of the component determines if it is accessible by other components and is an indicator of the health of the target. This monitor-able state that represents the health of the target is called its availability. Availability is a measure of the reliability and resilience of the component. For instance, if a database is down and inaccessible, this could impact the business functions that use the database and may cause service disruptions. Hence, it is critical for any target administrator to monitor its availability.
In OEM, most of the targets are associated with an availability status that represents the current health. The possible availability states in OEM include:
- UP: It indicates that the target is accessible and is healthy.
- DOWN: It indicates that the target is inaccessible and could cause possible service disruptions.
- BLACK OUT: It indicates that the target is currently in a scheduled maintenance window.
- METRIC COLLECTION ERROR: It indicates that the status of the target cannot be computed due to errors in executing fetchlets by the Oracle Management Agent.
- AGENT UNREACHABLE: It indicates that the status of the target cannot be ascertained by the OEM due to a failure in the communication channel between Oracle Management Agent and the Oracle Management Server (OMS).
- UNKNOWN: It indicates that the status of the target is yet to be ascertained by the OEM. This is used in repository targets.
The target specific favors of the OEM, such as OEM DB Control and OEM FMW Control, display only the latest availability state, that is, the current health of the target. In the OEM Grid Control favor, the availability states of the target are persisted in the OMS repository. This enables the administrator to view the historical state of the target. Within OEM Grid Control, the availability information is usually represented as a combination of the current state of the target followed by the time period for which the target is in the current state.
In addition to the current state of the target, OEM Grid Control also computes availability percentage (%) that indicates the historical health of the target. Availability percentage is defined as the ratio of the total UP time to total monitoring time, that is, sum of UP time, DOWN time and agent DOWN time.
The OEM Grid Control also provides a view that indicates the availability states of a target for a given period of time, that is, last 24 hours, last 7 days, or last 31 days. This displays the historical states of the component. This data acts as an indicator to the stability and reliability of the target.
The following image is a screenshot from OEM Grid Control that indicates the availability history of an Oracle WebLogic server. This specific page is known as availability status history page for the target.
As can be seen in the previous image, the cigar chart displays the historical availability states of the Oracle WebLogic server target for the last 24 hours. It provides the details of the total time during which the target was in various states and indicates the state changes during the last 24 hours. It also displays the calculated availability percentage as defined earlier.
The user can navigate to the Availability Status History page by clicking on the hyperlinks on the status of each target in the All Targets page.
Each component exhibits key performance attributes that indicate its performance and responsiveness. Such attributes are referred to as performance metrics. While it is important for the administrator to know if a component is up and running, it is also equally significant to know how responsive the component is. The availability of the target indicates only its current state and if it is running. There are other vital statistics of the target that provide invaluable information about the different performance traits. For instance, a host target may be up and accessible, however due to high CPU utilization, it may be totally unresponsive to user input. Such a target also needs attention from the system administrator. Hence, it is important to monitor these key performance indicators of the target in addition to the availability. These key indicators are referred to as metrics.
Metrics form the building blocks of performance management of any target with OEM. The performance characteristics of a target are collected by the Oracle Management Agent using different executable modules called fetchlets. The agent supports a collection of different kinds of metrics using various protocols. In the target-specific favors such as OEM DB Control and OEM FMW Control, these metrics are directly displayed to the end user. In this case, as with the availability measure, only the current or live metrics can be viewed. However, in the case of OEM Grid Control, these metrics are uploaded by the agent into the Oracle Management Server repository and the user requests are serviced by the OEM Grid Control console application directly from the repository. Hence, in the case of the OEM Grid Control, the historical metrics can also be viewed.
A target exposes multiple traits, each of which is an indicator of the performance of a specific aspect. For instance, the host target exhibits, in addition to the CPU utilization metric, other key performance indicators such as free disk space, memory utilization, load, and so on. The OEM Grid Control allows the collection each of these metrics to be enabled or disabled from the respective agent. It also supports customization of the metric collection interval—the time period between two subsequent metric uploads from the agent.
Alertsare situations where the OEM has detected that a specific performance metric from a target has deviated from an expected level. Alert indicates degradation in performance of the related target and makes the administrator aware of the possible imminent service disruption. Alerts are available only within the OEM Grid Control favors. They are generated whenever there is a deviant pattern observed in availability or in performance metrics.
As part of the metric collection configuration, the OEM Grid Control also provides an option to specify two thresholds—critical and warning thresholds. These thresholds indicate the expected levels of the metrics during healthy and normal conditions. Whenever the value of the metric collected crosses any of these thresholds, an alert is generated with the corresponding severity—critical or warning—and is stored in the repository. These alerts can be configured to provide different kinds of notification such as e-mail, sms, pager alert, and so on.
The following image shows a screenshot of a page from the OEM Grid Control 11g. This page is known as the Warning Alerts console. The user can navigate to this page by clicking on the Alerts link in the main tab and the Warning link in the subtab.
As can be seen in the previous image, the Alerts console within OEM Grid Control displays the various alerts based on severity. It also indicates the target name and type against which the alerts are generated, the time of alert generation, a short description of the alert, and the metric value that caused the alert generation.
The OEM Grid Control provides quick filters to view Alerts for specific targets. These quick filters can be applied by clicking on the Alerts hyperlink for the respective alert in the All Targets page.
Target home page
Each target has a summary page in OEM Grid Control that gives summary information of all the performance characteristics of the target. This view that provides the key performance details of specific target is called the target home page. The information displayed in the target home page depends on the type of the target that is selected. The targets belonging to the same target type have a similar target home page.
The following image is a screenshot from OEM Grid Control 11g that displays the target home page of the database instance named bsm. The home page for all database targets look similar to the image shown below, albeit the performance characteristics displayed in the target home page varies based on the target, its version, and its state.
Most of the target home pages show some common monitoring information. All the target home pages are composed of the following:
- General Section: This displays the current state of the target and shows the latest availability information. This section indicates the current version of the target and the host on which this target is running. This also provides the user with options that perform key process control operations such as start, shut down, or Black out to perform maintenance operations.
- Performance Metric Charts: This section displays the key performance indicators of the target displayed in a graphical format. These metrics are displayed in a chart for the selected time period.
- Alerts: This section displays any alerts for the selected target for the given time period. It provides a brief summary of the alert generated and the time at which the alert was generated. This section also displays the severity of the alert indicating if it is critical or warning.
- Policy Violations: This section provides a compliance score of the target with respect to the predefined target policies. It also indicates the number of the policy violations as well as the severity of the policy violations.
- configuration Section: This section provides links to edit the configuration of the target. These include changing the metrics to be collected, the collection frequency, specifying the metric thresholds for alert generation, and so on.
In addition, each target home page provides links for retrieving specific information such as availability, performance metrics, charts, and so on in detail.
Throughout the OEM Grid Control console pages, the target names are hyperlinked. Clicking on these links navigate the user to the respective target home page.
Passive and active monitoring
There are multiple paradigms of modeling and monitoring various components within the enterprise. Passive monitoring involves periodic measurement of various performance metrics as exposed by the component. This does not involve injecting any new load within or interfering with the regular load of the component. Passive monitoring helps in identifying the performance degradation of the system. Active monitoring involves running certain key steps or tests from different geographical locations periodically. These involve synthetic transactions that inject specific load into the component for monitoring purposes. This load is synthetic and is in addition to the regular load. Though active monitoring adds new load into the component, they help in measuring the real end user experience periodically. This aids in proactively detecting possible service disruptions.
OEM Grid Control supports both passive and active monitoring paradigms. Passive monitoring is supported through the regular agent-monitored targets and by collecting the different metrics within a target using the agent fetchlets. Active monitoring is supported through the Beacons and Service Tests framework. The Oracle Management Agent supports a separate execution module called the beacon that is capable of executing predetermined steps periodically. These beacons can be deployed in different geographical locations to periodically execute synthetic transactions. These synthetic transactions are configured as Service Tests within OEM Grid Control. These Service Tests define the regular steps that are to be executed periodically in order to perform active monitoring on a target.
|A Hands-on guide to modeling and managing business services using Oracle Enterprise Manager 11g R1 using this Oracle book and eBook|
eBook Price: £22.99
Book Price: £36.99
|Read more about this book|
(For more resources on this subject, see here.)
Different perspectives are required to have a holistic view of the enterprise IT infrastructure. These perspectives are known as composite targets and are created by relating individual target models. These include different models such as groups and system targets as well as service targets. Groups and system targets provide the mapping between the business goals and the underlying IT infrastructure. The service targets help in visualizing and monitoring the availability, performance, and service levels of various business functions provided within an enterprise. While group targets are homogeneous collections of targets that are logically related, system targets are heterogeneous in nature. OEM 11g provides support for all these modeling paradigms. As is evident, such composite modeling paradigms are applicable only in a wider context within an enterprise. These models are not meant to be applied at an individual target level.
To elaborate further with an example, the database administrator of the travel portal would be required to keep an eye on all the targets that collaborate with each other to provide the business functions. In this scenario, while the administrator requires a view that allows specific focus on the database, he also needs to have a composite view of the travel portal to get a holistic perspective. It is therefore apparent that there are two distinct sets of responsibilities to be supported by OEM:
- Target focus: This provides a highly specialized set of views exclusive for a specific target. These views are served primarily by the relevant favour of the target-specific control. In the case of the database example in the travel portal mentioned above, the database administrator will use the OEM Database Control for regular operations such as configuration changes, tuning, and so on. These are supplemented by the corresponding database target pages in OEM Grid Control. These target pages provide both process control functions and detailed information on the various performance metrics collected over a period of time. Such a view is highly useful for IT staff such as database administrators who need a specialized focus on database related metrics and operations.
- Business focus: This provides a holistic view that dwells on different targets within an enterprise and their interactions with each other to achieve a business objective. In the travel portal example, as illustrated before, this boils down to various views within the OEM Grid Control that depict composite models. These views help in mapping the business functions to the underlying IT infrastructure.
Composite targets, as described above, provide the business focus to the IT staff by aggregating various logically related targets together. This implies that the composite target perspectives are a step above the specifics of individual targets. Therefore, these composite targets are available only in the OEM Grid Control mode. This is because the other favors of OEM, that is, target-specific controls such as OEM Database Control, focus exclusively on individual targets and are not aware of the existence of other targets within the enterprise. Even though such a separation is highly useful in managing a specific target, it falls short while dealing with wider issues across the enterprise. To bridge this gap, OEM Grid Control provides various target models such as group, system, and services.
The following sections provide the various monitoring and modeling capabilities of each of these target types.
Group targets within OEM Grid Control is a collection of homogenous and related targets, that is, targets that are logically related and are of the same target type. For instance, in a travel portal, the database administrator will need to group all the database instances that store the various catalogues within the portal. By creating a Group target Catalogue-DB-Group that consists of all the Oracle database instances which store catalogue information, the database administrator can effectively manage all of these instances together. Similarly, all the Oracle WebLogic servers that are clustered to provide the fight search business function are related together to create a WLS-Cluster-Group. Hence, there will be multiple group targets within an enterprise that relate different sets of similar targets within an enterprise.
The following image is a screenshot of OEM Grid Control and shows a listing of all the group targets that are modeled. This specific page is referred to as All Group Targets page.
The user can navigate to this page by first clicking on the Targets link in the global tab followed by clicking on the Groups link in the subtab. The All Group Targets page displays all the group targets that have been created such as Catalogue-DB-Group, WLS-Cluster-Group, and so on within the enterprise. This page also provides summary information such as the member target types that comprise each of these group targets. This is supplemented by the count of alerts as well as the policy violations for each of these group targets. In short, this page provides a quick view of all the group targets along with their key details.
The All Group Targets page is a launch pad into each of the group targets. Clicking on any of the group targets navigates the user to the home page of the corresponding group target. The creation, configuration, and monitoring capabilities of various kinds of group targets is out of the scope of this article.
A system target is an aggregation of logically related targets that need not be of the same type. In general, a system target is a heterogeneous collection of targets that collaborate together to provide a specific business function. While group targets are usually created to monitor a cluster of similar targets providing failover or load balancing, system targets are created to model the IT infrastructure that provides a business function. Such a system provides visualization of the IT infrastructure providing a business function as single logical entity.
A system target can also be modeled based on the geographical location of the member targets. All the targets providing a business function from a specific location can be related to create a system target. Such a system target aids in getting a snapshot view of the targets from a specific location, and provides a direct mapping of the IT infrastructure to a specific set of end users.
Continuing with the travel portal example introduced in the previous article, all the targets providing a car rental business function such as Oracle database, Oracle WebLogic server, and the applications deployed, as well as the underlying host targets, are combined together into the TravelPortal-CarRental-System. Similarly, the various targets that provide the Flight Search business functions to the North America-based customers as well as APAC customers are aggregated into the FlightSearch-NAM-System and FlightSearch-APAC-System respectively.
The following image is a screenshot of OEM Grid Control and shows a listing of all the system targets that are modeled. This specific page is known as All System Targets page.
The user can navigate to this page by first clicking on the Targets link in the global tab followed by clicking on the Groups link in the subtab. The All System Targets page displays all the system targets that have been created such as TravelPortal-CarRental-System, FlightSearch-NAM-System, FlightSearch-APAC-System, and so on within the enterprise. This page also provides summary information such as the member target types that comprise each of these system targets. This page also displays the count of alerts as well as the policy violations for each of these system targets. To summarize, this page provides a quick view of all the system targets along with their key details.
The All System Targets page provides a drill down into each of the system targets. Clicking on any of the system targets navigates the user to the home page of the corresponding system target.
Service targets in OEM Grid Control are a class of targets that provide a functional perspective of the IT infrastructure with a business-centric focus. A service model allows the administrator to manage the IT infrastructure viewed through a business service dimension. It also provides vital information related to the various business functions such as availability, performance, and service levels.
The service targets can be configured based on two different paradigms of the same business function:
- Services Based on System: These are service targets that provide a direct mapping of business functions to the underlying IT infrastructure. These give the administrators a perspective of how the various targets influence the normal functioning and the service levels of a business function. These services rely on the passive monitoring capabilities within OEM Grid Control.
- Services Based on Service Test: These are service targets that are modeled based on an end user's perspective of the various business functions provided by an enterprise. These service targets are configured levering active monitoring paradigm using various service tests that execute the different synthetic transactions from modules in different locations known as beacons. These beacons run from the relevant geographical locations. This provides a black box view of the business service and its performance characteristics as perceived by the real end users.
The travel portal provides various business services such as fight search, car rental services, and so on to the end users. It also consumes the payment gateway services from various business partners. The IT staff requires both a customer view as well as infrastructure-oriented view of the business function. In the case of the fight search, the business function is modeled as a service target named FlightSearchWebSite, that is, based on the end user's perspective. Hence, this service is configured, based on service tests that run various synthetic, but relevant web transactions running from various beacons. These beacons are deployed in different locations such as New York, Singapore, and Tokyo representing the geographical locations of the key customer base. The car rental business flows are modeled as a service named CarRentalService and provide the mapping of business function with the IT infrastructure. So, this is configured as service target based on the underlying system—travel portal car rental system. To recall, the travel portal car rental system was created as a system comprising the heterogeneous targets that provide the car rental business functions.
The OEM Grid Control provides out-of-the-box models for four different types of service targets. These models represent the most frequently used paradigms across different enterprises in the visualization of various business functions. The four service target types supported out-of-the-box in OEM Grid Control are:
- Web Application: These are service target types that model the business services provided by various web applications.
- Forms Application: These are target types that model the various business functions provided by an Oracle Forms application.
- Generic Service: These are service target types that allow the administrator to model any standard business service within an enterprise.
- Aggregate Service: These are composite service target types that are defined by combining logically related business services together.
The following image is a screenshot of OEM Grid Control and shows a listing of all the service targets that are modeled. This specific page is known as All Service Targets page.
The user can navigate to this page by first clicking on the Targets link in the global tab followed by clicking on the Services link in the subtab. The All Service Targets page displays all the service targets that have been created within OEM Grid Control. This shows the service targets as well the corresponding target types. For service targets that are modeled based on system targets, the corresponding system target is displayed. It also indicates the summary information of the member targets within the system and their alerts. For the service targets defined using service tests, this page displays the summary information of the service tests and the alerts as well as the beacons executing these synthetic transactions.
A key difference between the service targets and the group/system targets is that the former represents a business function, while the latter is a logical collection. In OEM Grid Control service, targets have characteristics such as availability, performance, and usage metrics, while system and group targets are modeled as a collection of targets.
In the travel portal illustration, this page shows the different service targets configured such as:
- CarRentalService: It is modeled as a Generic Service target based on the TravelPortal-CarRental-System
- FlightSearchWebSite: It is modeled as a Web Application service based on Service Test from two different beacons
- PaymentGatewayService: It is modeled as a Forms Application based on the PaymentGatewaySystem
- TravelPortalSearchServices: It is modeled as an Aggregate Service comprising the CarRentalService and FlightSearchWebSite service targets
The All Service Targets page provides a drill down into each of the respective service targets. Clicking on any of the service targets navigates the user to the home page of the corresponding service target.
The All Service Targets page has a search feature that helps to filter the targets displayed based on target name. In addition, the OEM Grid Control also provides quick filters based on the key service target type—Web Application. This quick filter can be viewed by clicking on the Targets link in the main tab and then clicking on the Web Application link within the subtab.
Service level management
All business services in an enterprise come with an assurance from the provider and an expectation of the consumer. A key requirement of any BSM tool is the ability to track these assurances from the providers that match those expectations of the consumers. These assurances and expectations are defined on different attributes of a business service such as availability, performance, usage levels, support, and so on. The mutual consonance between the provider and the consumer on the above traits over a period of time is known as a Service Level Agreement (SLA)
OEM Grid Control provides capabilities of defining and tracking SLAs of different business functions. In order to track these service levels, it is imperative that the administrator models the business function as a service target within OEM Grid Control. The configuration and monitoring of service levels with OEM Grid Control takes into account the following parameters:
- Expected service level
- Performance and usage characteristics
- Planned downtime, if any
Product and management focus areas in OEM 11gR1
The previous sections introduced the concepts of OEM. We looked at managing individual entities of the IT infrastructure. However, OEM also provides out-of-the-box solutions for managing some of the key products and focus areas. These management solutions focus on certain products and provide models for managing the base targets, and the management of the business functions provided by these products. These models are built into the Grid Control product and come into effect post discovery of the corresponding product suite. Let's look at the list of key products and areas that are the focus of management in OEM 11gR1.
The following image illustrates the various focus areas in OEM Grid Control 11gR1:
The support for these focus areas are provided out-of-the-box with OEM Grid Control 11gR1. However, these options are licensed individually and are sold as OEM management packs. As an example, let's consider the Applications Management Product Focus Area. Some of the licensable management packs under this focus area are as follows:
- Application Management Pack for Oracle E-Business Suite
- Application Management Pack for Peoplesoft
- Application Management Pack for Siebel
- Application Management Pack for JD Edwards Enterprise One
In this article, we introduced the OEM product family as a tool that is a pre-requisite to effectively monitor and manage the IT infrastructure grid within the enterprise. This was followed by a brief overview of the Database Control, Fusion Middleware Control, and Grid Control favors of the OEM. We saw that Grid Control is a step above the other two favors and provides the wider enterprise view on a single canvas. We also covered the high level architecture and the main components of the OEM Grid Control.
This article also covered key terminologies relevant in the context of OEM Grid Control such as target models, availability, performance metrics, and alerts. We then moved to the composite target models that are supported exclusively by the Grid Control favor of OEM. This article also provided a brief overview of various composite targets such as groups, systems, and service targets. We also saw the active and passive modeling capabilities within the service targets. A subsequent discussion on the various service target models and the service level management features followed.
- Oracle Enterprise Manager 11g R1: An Overview of Business Service Management [Article]
- Business Process Modeling [Article]
- Business Rules Management, BPM, and SOA [Article]
- Introduction to Oracle Service Bus & Oracle Service Registry [Article]
- Using Oracle Service Bus Console [Article]
About the Author :
Ashwin Kumar Karkala a Software Development Manager is based out of Bangalore and is part of the Enterprise Manager Product group at Oracle. He has around 12 years of experience in the IT industry and has developed a wide range of enterprise solutions for various industries. At Oracle, he has worked on multiple versions of the Enterprise Manager Grid Control product and is responsible for developing solutions in multiple areas some of which include business services management , middleware diagnostics, cloud management and identity management. His other areas of interest include Service Oriented Architecture and Web 2.0 technologies.
Govinda Raj Sambamurthy is a Principal Member Technical Staff in the content management space in the Oracle Fusion Middleware team at Bangalore and is responsible for building highly available and highly scalable enterprise middleware products. He has around 9 years of experience in the IT industry and has played the role of developer, consultant, and technical lead in developing software for banking & financial, retail, and telecom verticals as well as product development, building enterprise solutions that are deployed in high-availability architectures. He was part of the Service Level Management pack development team in Oracle Enteprise Manager Grid Control 10g and 11gR1. His areas of interest include business services management, middleware diagnostics, service level management, cloud computing, enterprise 2.0 and semantic web.