| Oracle® Enterprise Manager Concepts 10g Release 5 (10.2.0.5) Part Number B31949-10 |
|
|
PDF · Mobi · ePub |
| Oracle® Enterprise Manager Concepts 10g Release 5 (10.2.0.5) Part Number B31949-10 |
|
|
PDF · Mobi · ePub |
This chapter describes how you can use Enterprise Manager to manage middleware targets such as Oracle WebLogic Server, Oracle Application Server, Oracle BPEL Process Manager, and so on.
This chapter covers the following:
Middleware essentially refers to the middle tier of your architecture that provides the runtime infrastructure for Web applications. Middleware consists of targets such as Oracle WebLogic Server, Oracle Application Server, Oracle BPEL Process Manager, Oracle BI Suite Enterprise Edition, and so on. While each middleware target has its own console to help you monitor that particular target, Grid Control offers a single-window solution wherein you can discover and centrally monitor many instances of a middleware target and also many middleware targets in one console.
For example, an Oracle Application Server can be managed using a standalone Application Server Control that comes with every Oracle Application Server. Alternatively, it can be managed using Grid Control along with other Oracle Application Servers and a host of other middleware targets.
This section introduces you to Application Server Control and Grid Control, and explains under what circumstances they come into use.
Every Oracle Application Server instance is installed with an Application Server Control to help you manage that particular application server instance. Application Server Control provides Web-based management features designed to monitor and administer application server instances, farms, and clusters. You can also deploy applications, monitor real-time performance, manage security, and configure the application server components.
Application Server Control relies heavily on various underlying technologies to discover, monitor, and administer the application servers in an environment. It consists of the Application Server Control console and its underlying technologies:
A local version of the Oracle Management Agent specifically designed to gather monitoring data
However, you can manage only one application server at a time using Application Server Control. Typically, you have multiple application servers in your enterprise configuration, and managing all these instances using individual Application Server Controls becomes very difficult.
For centralized management and additional management functionality (for example, application service level management, deployments, historical data collections for performance trending alerts, and so on), you can use Grid Control.
While Application Server Control provides standalone management for a single application server instance and its components, Grid Control provides centralized management of multiple application servers in your environment.
For example, if you have 10 application servers installed on ten different hosts, then you can manage all these ten application servers and hosts through a single window using Grid Control. With the help of Management Agents deployed on each host, Grid Control automatically discovers the application servers on these hosts and begins monitoring them using default monitoring levels, notification rules, and other default settings. Similarly, if you have multiple logical entities such as Oracle WebLogic Server Domains across your network, you can discover all of them in Grid Control and monitor them using a single console.
Grid Control provides its own application server home page that provides easy access to key information required by the administrators. Grid Control also provides a separate home page for logical entities such as Oracle WebLogic Server Domains and Oracle WebLogic Server Cluster.
At a high level, the home page in Grid Control (Figure 8-1) provides:
Application server status, responsiveness, and performance data
Resource usage for the application server and its components
Functionality to start, stop, and restart any of those core components
Alerts and diagnostic drill-downs so you can identify and resolve problems quickly
Metrics for more detailed information about the health of the application server
Links to other pages in Grid Control that might be helpful in accomplishing your given task
The following is the Oracle WebLogic Managed Server Home page:
Grid Control provides a comprehensive set of features for monitoring middleware targets in your environment. You can view a summary of the most critical information pertaining to your middleware targets. You can also monitor their performance, view the alerts and policy violations that were generated, track the configuration changes that were made over a period of time, and perform other administrative tasks on them.
Grid Control helps you monitor the following middleware targets:
Table 8-1 Middleware Targets Monitored
| Monitored Target | Services Offered by Grid Control | Related Links |
|---|---|---|
|
Oracle WebLogic Server Domain, Oracle WebLogic Server Cluster, and Oracle WebLogic Managed Server |
|
|
|
Oracle Application Server |
|
Creating Services from J2EE or Web Applications Diagnosing Performance Issues with Top Reports Managing Backup and Recovery of the Application Server Environment |
|
Oracle HTTP Server |
|
|
|
OC4J |
|
|
|
OracleAS Web Cache |
|
|
|
Oracle BPEL Process Managers |
Business Process Execution Language (BPEL) is an XML-based language for enabling task sharing across multiple enterprises using a combination of Web services. Oracle BPEL Process Manager provides a framework for easily designing, deploying, monitoring, and administering processes based on BPEL standards. |
|
|
Oracle Application Server Farm |
An OracleAS Farm is a collection of OracleAS DCM Managed Clusters and Oracle Application Server instances that share the same Farm Repository. |
|
|
Oracle Application Server DCM Managed Cluster and Oracle Application Server Clusters |
An OracleAS DCM Managed Cluster is a collection of release 9.0.4 to release 10.1.2 Oracle Application Server instances with identical configuration and application deployment characteristics. An OracleAS Cluster is a collection of release 10.1.3 or higher versions of Oracle Application Server instances. |
|
|
Oracle BI Suite Enterprise Edition (Oracle BI Suite EE) |
Oracle BI Suite EE is an integrated suite of products that offers a comprehensive and integrated set of business intelligence tools that help you collect information from a variety of sources, analyze it, and share it with the broadest audiences of users. It is a logical, composite target and its components are Oracle BI Presentation Server, Oracle BI Cluster Controller, Oracle BI Analytics Server, and Oracle BI Scheduler. Additionally, you can monitor DAC Server. |
|
|
Oracle Service Bus |
|
|
|
Third-Party Application Server |
Helps you manually discover the following third-party application servers, and monitor their status:
Also helps you view the applications deployed on these third-party application servers, and perform enterprise configuration management tasks like viewing, comparing, and searching configuration information. Helps you view the members within a domain, cluster, or cell. |
Chapter 15: Host and Third-Party Target Management |
|
Third-Party Plug-In |
Helps you manually discover the following third-party plug-ins and monitor their health:
|
Chapter 15: Host and Third-Party Target Management |
Note:
For more information about monitoring third-party targets, see Chapter 15: Host and Third-Party Target Management.Important:
Enterprise Manager 10.2 release supported only release 9.0.4 to release 10.1.2 application server targets, and for that release, OracleAS DCM Managed Cluster was actually called "OracleAS Cluster". However, now that Enterprise Manager 10.2.0.2 release has additional support for 10.1.3 application server targets, for the purpose of clarity, the terminologies have been amended to distinguish the ones managed by DCM and the ones that relate to release 10.1.3 application server targets.This section describes how you can use Grid Control to view critical information pertaining to middleware targets.
Grid Control provides general information about the targets including their status and availability. This helps you understand how the target is performing, where it is deployed, what is its version, where is its home directory, and so on. If the target is a logical target that groups its inherent members, then details about the membership are also provided.
Grid Control shows the number of critical, warning, and error alerts generated for the past 24 hours. These alerts indicate that a particular metric condition has been encountered. For example, an alert is triggered when a metric threshold is reached. Using these details, you can drill down to investigate the target and the problem that triggered the alert. For more information about alerts, see Automated Monitoring and Alerts in this chapter.
Grid Control also shows the number of informational, warning, and critical policy rules violated for the application server target. You can see the roll up of individual policy compliance scores for that target. Compliance scores provide a quick way to determine the health of the your middleware target. You can also see the policy trend overview for the last 24 hours, for the last week, for the last month, or for a user-define time period, and determine your course of action in solving the policy violations.
Grid Control also shows the time when security policy rules were last evaluated, and shows the roll up of individual policy compliance scores for that target.
Grid Control provides details about the J2EE applications deployed on the application server instances. You can quickly assess which applications are most active and which are using the most system resources.
Grid Control gives you the flexibility to update the information about applications based on current, real-time application performance, or based on historical data from the Management Repository. For example, you can see which applications were the most active over the past 24 hours, over the past week, or over the past month.
For logical, composite targets such as Oracle WebLogic Server Domains, OracleAS Farms and Clusters, and so on, Grid Control provides rolled-up information on the member targets that make up the group. It provides a "Members" tab that helps you view the members associated with that particular composite target; check their status; and start, stop, or restart each of them.
Grid Control also helps you study the High Availability (HA) grouping done for the members of an OracleAS DCM Managed Cluster. A High Availability Group is a group composed of similar individual components of application server instances clustered together in a DCM managed cluster. For example, an OC4J High Availability Group has a group of OC4J instances in an OracleAS Cluster.
This section describes the features offered by Grid Control that help you monitor the performance of middleware targets.
Grid Control provides a set of predefined performance metrics for every middleware target. By selecting a metric, you can determine whether the thresholds have been defined for a particular metric. Grid Control uses thresholds defined within metrics as a mechanism to generate alerts. These alerts in turn are used to notify you whether a target is up or down, a disk on the target is near full, and so on. Thus, you can monitor their overall performance.
The performance metrics provide details about the metric as a current real time value (30 seconds, 1 minute, or 5 minutes) or a previous value (past 24 hours, 7 days, or 31 days). The historical information is displayed as graphs and a table. By using graphs, you can easily watch for trends, and by using tables, you can examine details of past metric severity history.
Grid Control provides a comprehensive set of features that facilitates automated monitoring and generation of alerts. Oracle Management Agent on a host automatically discovers the middleware targets on that host, and helps Grid Control perform unattended monitoring of their status, health, and performance.
Grid Control gathers and evaluates diagnostic information from these targets distributed across the enterprise, and an extensive array of middleware performance metrics are automatically monitored against predefined thresholds.
For example, Grid Control can automatically monitor:
The CPU or memory consumption of the application server, including detailed monitoring of individual Java Virtual Machines (JVMs) being run by the server's Oracle Application Server Containers for J2EE (OC4J) instances
J2EE application responsiveness from the application down through individual servlets and Enterprise JavaBeans (EJBs)
HTTP Server session volumes, connection duration, and error rates
Top servlets based on number of requests, maximum processing time, and highest average processing time
If an Oracle Application Server or any of its core components go down, or if a performance metric crosses a warning or critical threshold, then an alert is generated by Grid Control and a notification is sent to you. Grid Control supports notifications via e-mail (including e-mail-to-page systems), SNMP traps, and/or by running custom scripts.
When you receive an alert notification, Grid Control makes it easy for you to investigate the problem and take corrective actions wherever required. For example, notification of excessive CPU consumption by OC4J may lead to investigation of the applications running in that container. By using the Top J2EE Applications tab of the Application Server Home page (Figure 8-7) in Grid Control, you can quickly identify the highest volume or least responsive application. You can then drill down and diagnose application's servlets, Java Server Pages (JSPs), or EJBs to identify the bottleneck.
You can set up corrective actions to automatically resolve an alert condition. These corrective actions ensure that routine responses to alerts are automatically executed, thereby saving you time and ensuring that problems are dealt with before they noticeably impact the users.
You can also use monitoring templates to simplify the task of standardizing monitoring settings across your enterprise. You can specify the monitoring settings once and apply them to all Oracle Application Server targets. A Monitoring template defines all Grid Control parameters you would normally set to monitor an Oracle Application Server target, such as:
Target type to which the template applies
Metrics (including user-defined metrics), thresholds, metric collection schedules, and corrective actions
When a change is made to a template, you can reapply the template across affected Oracle Application Server targets in order to propagate the new changes. You can reapply monitoring templates as often as needed.
Besides the monitoring features provided for Oracle Application Servers, OracleAS Farms, and OracleAS DCM Managed Clusters, Grid Control also provides a topology view for these targets. You can view their topology to understand what application servers and components are running on which hosts, how these components are related to each other, and how requests are routed through different layers of the deployment. This kind of visualization of the data center enterprise topology helps administrators effectively monitor, manage, and validate the enterprise architecture.
Grid Control provides three different views of topology. Each view provides the overlay of some key metrics of components including current status, number of alerts and policy violations, and CPU/memory utilization performance metrics.
Host View shows the physical view of deployment and visually shows the relationship between hosts and various components and instances hosted by them.
Routing Overview shows the routing view of topology and provides an end-to-end view of wired component and application flow through them. The routing includes routing from OracleAS Web Cache to Oracle HTTP Server to OC4J to DB instances.
Routing Details also shows the protocol and port used by various components to route requests to other components in the topology.
These routing views enable you to fix various topology configuration problems immediately. For example, if an OC4J instance is not accepting any user requests, the routing details view confirms if the front-ending Oracle HTTP Server instances are configured correctly to route user requests to that OC4J instance. OracleAS Web Caches, Oracle HTTP Server, or OC4J components are displayed in the same box, if they provide redundancy for each other.
For example, a set of OracleAS Web Caches are combined in the same box if all of them are routing to the same set of Oracle HTTP Server instances. Similarly, a set of OC4J instances are combined in the same box if they are routed by the same set of Oracle HTTP Server instances, and are also hosting the same set of J2EE applications. As the like-components are grouped together, the topology visual representation in routing overview or routing details view provides instant Root Cause Analysis for the service availability problems.
Grid Control also provides access to Oracle System Monitoring Dashboard that helps you monitor the health of a target. However, this feature is provided only for OracleAS Farms, OracleAS DCM Managed Clusters, Oracle Application Servers, OC4J High Availability Groups, and HTTP Server High Availability Groups.
Oracle System Monitoring Dashboard presents information using intuitive icons and graphics that let you spot recent changes and quickly identify and respond to problems. You can customize the display attributes to match information requirements of managed targets, monitor status indicators for recent problems, and see new alerts that have been triggered since the dashboard was last viewed.
Grid Control provides features for performing administrative tasks on middleware targets. It provides Web-based interfaces for performing operations such as:
Starting, stopping, or restarting middleware targets.
Performing configuration management tasks, such as viewing and comparing configuration information. Refer to "Managing Configurations" in this chapter for more information.
Accessing a list of predefined search queries to search and retrieve configuration information. Refer to "Managing Configurations" in this chapter for more information.
Integrating application instrumentation in Enterprise Manager's event monitoring infrastructure. Refer to "Extensible Monitoring" in this chapter for more information.
Staging or applying an interim patch or patch set, and/or cloning an application server's Oracle home to one or more hosts. Refer to "Cloning and Patching the Middleware Environment" in this chapter for more information.
Performing scheduled backup and recovery. Refer to "Managing Backup and Recovery of the Application Server Environment" in this chapter for more information.
Creating blackouts to perform scheduled maintenance.
Viewing the number of scheduled, running, suspended, and problem (stopped/failed) executions for all Grid Control jobs submitted on the application server.
Creating Application Server Farms and managing their components.
Grid Control comes with a bundle of performance and health metrics that enable automated monitoring of application targets in your environment. When a metric reaches the predefined warning or critical threshold, Grid Control generates an alert and notifies the administrators.
However, there are occasions when you want to perform maintenance work on your middleware targets, and not want any alerts to be generated while you are bringing them down. In this case, you can schedule a blackout and suspend monitoring of the middleware targets.
Blackouts allow you to suspend any data collection activity on one or more monitored targets, thus allowing you to perform scheduled maintenance on targets. If you continue monitoring during these periods, the collected data will show trends and other monitoring information that are not the result of normal day-to-day operations. To get a more accurate, long-term picture of a target's performance, you can use blackouts to exclude these special-case situations from data analysis.
Grid Control allows you to define new blackouts; view the status of existing blackouts; and edit, stop, and delete blackouts that are not required. You will find the Black Out option in the General section on the home page of any application server target. For composite targets like OracleAS Farms, you will find this option in the Administration tab.
For OracleAS Farms, OracleAS DCM Managed Clusters, OracleAS Clusters, Oracle WebLogic Server Domains, and Oracle WebLogic Server Clusters, Grid Control provides a job system that allows you to create jobs. For example, for an Oracle WebLogic Server Domain, you can create a job to automatically start, stop, or restart that server. You can also view details about the jobs that are scheduled, running, suspended, or the ones that have a problem. You can schedule a job directly from these composite targets to run an OS command on the members or start, stop, or restart any OPMN component.
Grid Control allows you to create services directly from a J2EE or Web application to help you track their availability and performance. Understandably, the business applications running on an application server simply reflect the quality of service rendered by an organization. Considering their criticality and complexity, it becomes imperative for any organization to ensure that they are always available and capable of servicing the requests within an acceptable turnaround time.
By creating services from a J2EE or Web application, you can group your applications as an entity that provides a useful function to its users. This helps you monitor the overall performance of the service that represents a function offered to the users, and also monitor the infrastructure components upon which the service depends. You can also receive alerts when there is a problem, identify common issues within the system, diagnose causes of failures, and resolve them.
Every time you create a service for J2EE or Web application, Grid Control creates a service dependency to identify the components on which the selected application depends. Here, the components refer to infrastructure components like hosts, databases, application servers, and so on that work together to host your J2EE or Web applications. After identifying the components required for that application, Grid Control creates a system with those components, and then creates a service and associates it with that application.
So, every time you create a service, Grid Control checks to see if a dependency mapping is already available for the selected application. If it is available, then a service is created using that existing system rather than creating another system with exactly the same members.
According to the availability of this dependency mapping for an application, you can either create a new service with a new system, create a new service with an existing system, or refresh a service.
Grid Control allows you to create infrastructure services for middleware targets such as Oracle BPEL Process Manager targets and Oracle Service Bus targets.
Note:
"Middleware targets" in this section refer to Oracle BPEL Process Manager targets and Oracle Service Bus targets only.An infrastructure service is a dependency service that is created to identify the infrastructure components on which the middleware target depends. Here, the infrastructure components refer to hosts, databases, application servers, and so on that work together to host the middleware target.
You can either create an infrastructure service with a new system or an existing system, or simply refresh an existing infrastructure service, if there is already one existing. By creating infrastructure services and systems, you can better manage your middleware targets and also the components on which the middleware targets depend.
For example, once you create an infrastructure service for an Oracle BPEL Process Manager target, Grid Control allows you to create an aggregate service for every process within that Oracle BPEL target. An aggregate service is a logical grouping of services, in this case, infrastructure services and availability services. An availability service is a service that is created when a SOAP (Simple Object Access Protocol) test is added for the first time to the partner links associated with the selected Oracle BPEL processes. Aggregate Services give you a bird's-eye view of the services that have been created for the Oracle BPEL target and helps you monitor their availability, performance, and usage.
Grid Control allows you to add SOAP tests for partner links associated with a selected Oracle BPEL process in order to test their availability.
SOAP is an XML-based message protocol used by Web Services of these partner links. Each SOAP message consists of a single SOAP envelope. An envelope defines how to process the message, who should process the message, and whether processing is optional or mandatory.
Grid Control allows you to select a particular method specific to a port type exposed by the Web service, and provide values for the input parameters that it should use. The SOAP test invokes the selected method and checks if the Web service is up. This way, you can track the performance of the partner links and know when they are down.
Grid Control allows you to create a SOAP test for either a proxy service or an end point associated with the business service of an Oracle Service Bus. The SOAP tests that are added help in monitoring the availability and response time of the Web service used by these partner business services.
When a SOAP test is added for the first time, an availability service for it is created automatically. This availability service gets added as a child service of the aggregate service. Every other SOAP test that is added gets included in the same availability service.
Grid Control allows you to create SOAP tests for web services of applications deployed to Oracle WebLogic Manager Servers. When a SOAP test is added for the first time, a generic service for it is created automatically. The generic service is created to monitor the availability of the web services in the application. By default, the generic service that is created has the format <appname>_webservices_availability. The next time you create a SOAP test, Grid Control associates the new SOAP test with the existing service.
Grid Control provides deployment procedures for provisioning BPEL processes on selected BPEL Process Managers. The BPEL Process Provisioning deployment procedure comes with the following predefined phases:
Stage Setup: This phase sets up the BPEL processes and other dependencies. Essentially, it sets up the BPEL suitcase files, stages them to a temporary location for deployment, and stages the deploy.jar on the target hosts.
Deploy: This phase deploys the BPEL processes on the selected target BPEL Process Managers.
Clean Setup: This phase cleans up the files and folders staged on the individual hosts.
The BPEL process suitcase files have to be placed as generic components in Oracle Software Library, and once it is available for deployment, the deployment procedure can be run to deploy the processes on BPEL Process Managers.
Grid Control provides deployment procedures for deploying exported Oracle Service Bus resources to a target Oracle Service Bus domain, and move your configuration from one environment to another.
Oracle Service Bus resources can be organized into individual projects. Projects are non-hierarchical, disjointed, top-level grouping constructs. All resources (such as business services, proxy services, WS-Policies, WSDLs, schemas, XQuery transformations, JARs, and so on) reside in exactly one non-overlapping project. Resources can be created directly under a project or be further organized into folders. Folders may be created inside projects or inside other folders, and the folders are similar to directories in a file system, with the project level being the root directory.
Using the Oracle Service Bus Resource Provisioning deployment procedure, you can select the projects of an Oracle Service Bus domain that you want to export, and deploy the resources of that project to another Oracle Service Bus domain. You can export the resources at a project level or resource level. Either way, technically, the resources are exported as a JAR file, and the JAR file is deployed to the target Oracle Service Bus domain. If you already have the resources exported as a JAR file from an Oracle Service Bus domain, then you can upload the file to Oracle Software Library (software library) and use the deployment procedure to deploy it from the software library.
The Oracle Service Bus Resource Provisioning deployment procedure offers the following predefined phases:
Export Resources: Exports all the resources from the source Oracle Service Bus domain.
Save Exported JAR File: Saves the exported JAR file as a generic component in Oracle Software Library (Software Library).
Transfer Exported JAR File for Deployment: Transfers the JAR file from source host to the destination for deployment.
Stage Selected Software Library Components for Deployment: Copies the selected Software Library components to the host of the Oracle Service Bus domain where they have to be deployed.
Deploy Resources and Customize: Deploys resources and customizes on the selected target.
You can also use a customization file to modify the environment values and references within resources to suit the changed environment. Customization files can include customizations for all the environment values found in the selected resources. In addition, it can also include changes to the reference customization type for changing references inside resources with dependencies. You can create these customization files using the Oracle Service Bus console.
Note:
Oracle Service Bus provisioning is not supported if Oracle WebLogic Server Domain is discovered using a remote Management Agent. For example, if you use the Management Agent running on host2 to discover Oracle WebLogic Server Domain and Oracle Service Bus running on host1, and then if you try provisioning Oracle Service Bus resources, you will see errors.Oracle Application Server components generate log files containing messages that record all types of events, including startup and shutdown information, errors, warning messages, access information on HTTP requests, and additional information.
However, the information recorded in log files is voluminous, thus making it difficult to track what update was made at what time. Also because of the huge quantity of information updated periodically, the log files grow in size and occupy more space on the system over a period of time. The only way to manage these log files is to manually archive the contents to another file and store them in a different location.
Considering these impediments, Grid Control has been enhanced with a log rotation feature that helps you manage the logs of Oracle Application Server components more effectively. In particular, you can use Grid Control to:
Schedule a job that automatically rotates a log at the scheduled date and time
Manage space on your system by storing the rotated log files in a different directory
Grid Control allows you to view the logs of a particular Oracle Application Server component type and select the ones that need to be rotated. Note that a log rotation job can also be part of a multi-task job.
When a log rotation job is executed, Grid Control automatically stops the component whose logs have to be rotated. After it is stopped, the content from its existing log file is moved to another file that is distinguished with the timestamp when it was actually rotated. The original log file is kept empty for new log details to be populated. Once this is done, Grid Control restarts the component.
Grid Control provides a suite of configuration management functions that can be performed on middleware targets.
Oracle Management Agent collects configuration information about Oracle Application Server targets from their respective configuration files, and communicates this information over HTTP/HTTPS to Oracle Management Service, which stores it in the Management Repository. This information is periodically collected and updated while maintaining the audit of changes. Enterprise Manager's configuration management capabilities efficiently guide the users to desired configuration data in a particular component.
See Also:
"Hardware and Software Configurations" in Chapter 4, "Enterprise Configuration Management"You can compare these configuration details and view the differences and similarities between the two instances of a middleware target. You have the flexibility to compare two last collected configurations or two saved configuration files. You can also compare one configuration with multiple configurations or one configuration in the Management Repository with a saved configuration file.
Using Grid Control, you can search configurations across middleware targets and find configuration anomalies - whether they are a mismatch of an install/patch version of Oracle Application Server software, or they are a mismatch of software configuration data for the core components of Oracle Application Server. You can perform more intelligent searches to identify all the components hosting a particular application or other resources.
For example, the Administration page in Grid Control provided for Oracle Application Server targets allows you to search one or more:
Origin servers
Application servers with particular installation settings
Data sources used by the applications deployed across your enterprise configuration
J2EE applications deployed in a particular OC4J instance, application server instance, or host
Modules of J2EE applications deployed across your enterprise configuration
Application server ports across your enterprise topology
In addition, for BPEL Process Manager targets, you can view the BPEL Processes, its different versions, and the suitcase files associated with each version. You can also compare the BPEL Process suitcase files of different versions and track the changes that were made to a version. shows you how the versions can be selected and compared. This allows you to identify the cause for improved or deteriorated performance due to a change in the BPEL Process suitcase file.
Many administrators often require custom logic to be written to check for conditions specific to their application environments. Grid Control allows integration of application instrumentation in Grid Control's event monitoring infrastructure. If application developers expose application instrumentation using standards like JMX or Web Services operations, then you can build management plug-ins for the instrumentation using easy-to-use command line tools, and leverage Grid Control's event monitoring system to monitor it. You do not have to edit any XM files or write any integration code to integrate such instrumentation in Grid Control. Follow these procedures to integrate application-defined instrumentation in Grid Control:
Use Command Line Interfaces that analyze MBean interfaces for JMX and WSDL for Web Services and create management plug-ins
Import Management Plug-in Archive in Grid Control
Deploy Management Plug-in to Management Agents
Create Target-type instances for the target types defined in Management Plug-in Archive
Leverage Grid Control's event monitoring system including monitoring templates, corrective actions, historical and real time metric views, alerts, customization of notification rules, and methods on events generated from application instrumentation metrics
When you are troubleshooting performance problems, it can be helpful to know which servlets or JSPs are the most active. By using the Top Servlets or Top JSPs performance links of the Application Server Performance page (Figure 8-14 and Figure 8-15) in Grid Control, you can identify the top Java servlets or JSPs running on the application server instance. You can then sort them to identify the servlets and JSPs by number of requests, maximum processing time, or highest average processing time.
As with all Grid Control diagnostics, the application server diagnostic reports can be based on current or historical data. Application server metrics are collected and stored in the Management Repository, so you can analyze the data well after the situation has changed. For example, you can use historical data and diagnostic reports to research an application performance problem that occurred days or even weeks ago.
You can even provide a customized time period for which the data should be retrieved from the Management Repository. You can customize the time period for:
Pre-defined range of the last 24 hours, last 7 days, or last 31 days
Customized range of any number of days, weeks, months, or years
Any start date and end date (such that the duration is not greater than 99 years)
This section describes the features offered by Grid Control that help you maintain middleware targets.
Backup and recovery refers to the various strategies and procedures involved in guarding against hardware failures and data loss, and reconstructing data should there be a loss. A comprehensive backup strategy should involve a coordinated approach to backing up your entire application server environment, including the middle tiers and the Application Server Infrastructure Oracle homes.
Grid Control helps you manage the backup and recovery of a single application server or a group of application servers.
Using Grid Control, you can:
Schedule backups
Restore application server backups for recovery
Display the status of backup jobs
Display the status of recovery jobs
Configure the required settings for backup
For more information on the types of backups and recommended strategy for performing backup and recovery, see the Oracle Application Server Administrator's Guide.
Using Grid Control's automated provisioning tools, you can ensure standardization in your data center and also significantly reduce the time spent on these tasks. To consistently maintain standardization in the topology, it is recommended that the new instances be added through “cloning” rather than “install and configure”.
Cloning ensures that the new instance is installed and configured exactly like other instances in the enterprise topology. Cloning is the process of copying an existing installation to a different location while preserving its configuration and deployments. Grid Control's cloning wizard automates the duplication of application server About Access and Identity Management installations; specifically, the directories where the Oracle homes reside. Its "multicasting" capability also helps you create multiple clones on multiple target hosts in a single operation.
Using a direct link to My Oracle Support, Grid Control proactively and regularly retrieves the list of critical patches that have to be applied on Oracle Application Server installations. Grid Control also analyzes the data center environment and notifies you of patches that are applicable to their application server instances. All other patches can also be manually found in the context of a specific target. You can also automate the application of patches using robust job system infrastructure. You can apply the patches instantly or schedule the application in the maintenance window while backing out Oracle Application Server instances in the maintenance window.
See Also:
"Cloning" and "Patching" in Chapter 13, "Lifecycle Management"This section describes how you can use Grid Control to manage your Identity Management targets. It describes the following:
Using Grid Control for Monitoring Identity Management Targets
Diagnosing Identity Management Performance and Availability Problems
Access management is the means for controlling user access to enterprise resources. Access management products provide centralized, fine-grained access management for heterogeneous application environments, as well as out-of-the-box integration with Oracle products such as Oracle Portal, Oracle Collaboration Suite, and Oracle E-Business Suite. Oracle Identity Management is a product set that allows enterprises to manage the end-to-end life cycle of user identities across all enterprise resources both within and beyond the firewall.Automating user identity provisioning can reduce IT administration costs and improve security. Provisioning also plays an important role in regulatory compliance. Compliance initiatives focus on the enforcement of corporate policies as well as the demonstration of compliance with these standards. An enterprise identity management solution can provide a mechanism for implementing the user management aspects of a corporate policy, as well as a means to audit users and their access privileges.
Oracle Identity management products include the following:
Access Manager
Access Server
Identity Server
Oracle Access Manager, formerly known as Oracle COREid Access and Identity, provides Web-based identity administration and access control to Web applications and resources running in a heterogeneous environments. It provides the user and group management, delegated administration, password management and self-service functions necessary to manage large user populations in complex, directory-centric environments.
Access Manager supports all popular authentication methods including browser forms, digital certificates, and smart cards, and integrates seamlessly with most application servers and portals, including OracleAS 10g, Oracle WebLogic, IBM WebSphere, Vignette and others. User identities and credentials can be accessed from a number of repositories including Oracle Internet Directory, Microsoft Active Directory, and Sun Java System Directory. With Access Manager, user access policies can be defined and enforced with a high degree of granularity through centralized management.
The Access Server enables you to protect resources such as URLs and legacy, non-HTTP applications. It provides authentication and authorization services to enterprise applications. It uses the information stored by the Identity Server to control which users, groups, and organizations can access a resource. It stores information about configuration settings and security policies that control access to resources in a directory server that uses Oracle Access Manager-specific object classes. You can use the same directory to store the Access Server configuration settings, access policy data, and user data, or you can store this data on separate directory servers.
The Identity Server is a set of applications that provide delegated administration, user self-service, and real-time change management. The Identity Server stores information about users, groups, and organizations. For example, you can create, manage, and delete groups in the directory server. You can define a subscription policy for a group, including self-service with no approval needed, subscription with approvals, rule-based subscription, and no subscription allowed.
The Oracle Identity Manager platform automates user identity provisioning and deprovisioning and allows enterprises to manage the end-to-end lifecycle of user identities across all enterprise resources, both within and beyond the firewall. It provides an identity management platform that automates user provisioning, identity administration, and password management, wrapped in a comprehensive workflow engine.
Automating user identity provisioning can reduce IT administration costs and improve security. Provisioning also plays an important role in regulatory compliance. Key features of Oracle Identity Manager include password management, workflow and policy management, identity reconciliation, reporting and auditing, and extensibility through adapters.
Oracle Identity Manager also provides attestation support. Attestation is the process of having users or system managers confirm people's access rights on a periodic basis. Existing Sarbanes-Oxley requirements demand enterprises to perform attestation for all financially significant systems every three to six months. Identity Manager includes a highly flexible attestation solution to help enterprise customers meet these regulatory requirements in a cost-effective and timely manner. By setting up attestation processes in Identity Manager, enterprise customers can automate the process of generation, delivery, review, sign-off, delegation, tracking, and archiving of user access rights reports for reviewers on a scheduled or ad-hoc basis.
As more companies move their business processes to the Web, many organizations have a greater need to extend the boundaries of their enterprise to include partner applications. Federated identity management allows companies to operate independently and cooperate for business purposes by enabling cross-domain single sign-on and allowing companies to manage user identities and vouch for them as they access resources managed by another domain.
Oracle Identity Federation, formerly known as COREid Federation, provides a self-contained federation solution that combines the ease of use and portability of a standalone application with a scalable, standards-based proven interoperable architecture. It helps corporations securely link their business partners into a corporate portal or extranet while also increasing their compliance with privacy and security regulations. Identity Federation enables companies to manage multiple partners and choose from industry standard federated protocols. Identity Federation provides built-in integration with customer's identity management infrastructure (Oracle and non-Oracle) to deliver an end-to-end user experience, addressing scenarios like automatic registration, identity mapping, seamless access control navigation, and others.
Enterprise Manager helps you monitor the availability and diagnose the health of Access, Identity, Identity Federation, and Identity Manager servers within your enterprise configuration. By deploying a Management Agent on each host, you can use Enterprise Manager to discover the Identity Management components on these hosts, and automatically begin monitoring them using default monitoring levels, notification rules, and so on.
All Identity Management targets, whether Access, Identity, Identity Federation, and Identity Manager have their own server home pages that provide easy access to key information required by the administrators. Each Identity Management Server home page provides the following information:
Server status, responsiveness, and performance data
Alerts and diagnostic drill-downs so you can identify and resolve problems quickly
Resource usage for the server and its components
Functionality to start, stop, and restart components in the case of locally-monitored Access and Identity servers
Configuration parameters for Access and Identity servers
Figure 8-16 shows the Access Manager - Access Server home page.
Figure 8-16 Access Manager - Access Server Home Page
Identity Management services run on Identity Management systems defined in Grid Control. The system includes the software infrastructure components that the Identity services rely on. The system includes components such as databases, HTTP servers, OC4Js, and other servers.
The system is a collection of server targets that are grouped together in Grid Control to give you a view of the "data-center" components that comprise your Identity Management deployment. Identity Management Systems are created when Identity suite components are discovered using Grid Control. Grid Control also monitors the performance and availability of these components and provides a System Dashboard to view the health of the Identity Management system in a single window.
Figure 8-17 shows an Access Manager-Identity System home page:
An Identity Management service is a logical target configured by Grid Control. You use Grid Control to step you through the process of configuring a web application service for your Identity component instances. After you configure a service, that service is displayed on the Services page.
Critical application functions are defined and monitored as services in Grid Control. Each service is monitored by Grid Control beacons, which run service tests that simulate real user access to the service. Service availability and performance are monitored automatically, and problems are immediately reported to the administrator. By monitoring availability and performance of Identity Management services, you can identify and resolve user-visible problems more quickly and thus minimize the impact on users.
An access service allows you to perform service-level monitoring. If authentication or authorization services are not available, then the administrator should be notified about the service failures. Administrators will then be able to diagnose the cause of the problem using Root Cause Analysis.
Discover the Access Server target in Grid Control. For information about discovering this target, see the Grid Control online help. This will create the associated system.
In Grid Control, in the Services tab, select Add Generic Service and click Go.
The Create Generic Service wizard is displayed.
In the Create Generic Service: General page, provide a name for the service and associate the Access system. Click Next.
In the Create Generic Service: Availability page, select Define availability based on Service Test. This allows you to create a web transaction. Click Next.
In the Create Generic Service: Service Test page, provide a name for the web transaction, select Record a Transaction and click Go.
In the Create Service Test page, in the Steps section, click Record.
In the Record Web Transaction page, click Start. A new browser window is displayed.
In the browser, enter the URL that is protected by the Access Server. In the Single Sign-On login page displayed, enter the username and password.
In the Record Web Transaction page, click Stop and then click Continue. The Create Web Applications: Service Test page is displayed again. Click Continue.
In the Create Generic Service: Beacons page, add a beacon to execute the web transaction you created. Click Next.
In the Create Generic Service: Performance Metrics page, click Next.
In the Create Generic Service: Usage Metrics page, click Next.
In the Create Generic Service: Review page, click Finish to create the Access service that will be monitored by the beacon test.
Identity service allows the administrator to perform service-level monitoring of Access Manager Identity. If user management or group management services are not available, then the administrator should be notified about the service failures. Administrators will then be able to diagnose the cause of the problem using Root Cause Analysis.
Discover the Identity Server target in Grid Control. For information about discovering this target, see the Grid Control online help. This will create the associated system.
In Grid Control, in the Services tab, select Add Generic Service and click Go.
The Create Generic Service wizard is displayed.
In the Create Generic Service: General page, provide a name for the service and associate the Identity system. Click Next.
In the Create Generic Service: Availability page, select Define availability based on Service Test. This allows you to create a web transaction. Click Next.
In the Create Generic Service: Service Test page, provide a name for the web transaction, select Record a Transaction and click Go.
In the Create Service Test page, in the Steps section, click Record.
In the Record Web Transaction page, click Start. A new browser window is displayed.
In the browser, enter the URL of the Identity system (<host:port/identity/oblix>) and then click the Identity System Console link. The login page is displayed.
In the Record Web Transaction page, click Stop and then click Continue. The Create Web Applications: Service Test page is displayed again. Click Continue.
In the Create Generic Service: Beacons page, add a beacon to execute the web transaction you created. Click Next.
In the Create Generic Service: Performance Metrics page, click Next.
In the Create Generic Service: Usage Metrics page, click Next.
In the Create Generic Service: Review page, click Finish to create the Identity service that will be monitored by the beacon test.
For information about creating a web application service for Identity Manager, see the "Creating Web Applications for Identity Manager" topic in online help.
You can create an Identity Federation service for service-level monitoring of Identity Federation. The procedure to create an Identity Federation service is similar to the procedure to create an Access or Identity service.
Grid Control enables you to monitor all of your Identity Management services. Each service is monitored for performance, usage, and availability.
Each service has its own home page. The Service Home pages in Grid Control provide:
Status, responsiveness, and performance data
Resource usage data for the service
Summary information such as status, performance alerts, usage alerts, and policy violations for the service's subcomponents, including other services and associated systems
Links to home pages for the service's subcomponents
Alerts and diagnostic drill-downs so that you can identify and resolve problems quickly
Services Dashboard
The Services Dashboard provides a high-level view of the status, performance, and usage of each Identity Management target. Service-level compliance for various time periods are also included for each service on the dashboard. You can launch the dashboard directly from Identity system target home page. You can also publish the Services Dashboard so that it can be viewed by non-Enterprise Manager users. This allows you to provide a self-service status web page to your end users.
Related Links to do the following:
View metrics for the service
View client configurations
Edit the service
View the service target's properties
Manage blackouts
View and manage metric thresholds and policies
See Also:
Chapter 6, "Service Management"Individual services in Identity Management are associated with critical system components. This allows Enterprise Manager to perform Root Cause Analysis down to the system level whenever a service outage is detected. When you are configuring an Identity Management service in Grid Control, you also mention the critical system components of this service. When an Identity Management service goes down, Enterprise Manager automatically performs a root cause analysis to determine which critical system component is responsible for this.
Enterprise Manager automatically gathers and evaluates diagnostic information from Identity Management targets distributed across the enterprise. As with all targets managed by Enterprise Manager, an extensive number of Identity Management performance metrics are automatically monitored against predefined thresholds. Alerts are generated in Grid Control when metrics exceed these thresholds.
You can use Grid Control to diagnose performance and availability problems with your Identity Management services. For example, if a service outage occurs, Root Cause Analysis will determine if the primary cause is an outage of a critical service or system component. If a service performance issue is found, an administrator can examine detailed metrics over time related to that service and any of the service or system components used by that service. When you suspect there is a problem with one or more server components in the Identity Management system, the system home pages provide metrics and charts for diagnosing the issue.
Grid Control includes many general features that are useful to an Identity Management administrator, including:
Job Automation: You can use the Grid Control job system to schedule tasks you want to automate.
Policies: You can utilize the policy framework to ensure your Identity Management infrastructure adheres to your site-specific standards.
Database and Application Server Management: Using the single Grid Control console, you can also manage the specific databases and application servers in your Identity Management deployment if needed.
Extensions: Grid Control also includes monitoring of key network components that may be part of your Identity Management deployment. You can also extend Grid Control to monitor other components that are not recognized out-of-box by Enterprise Manager.
|
 Copyright © 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
