Open the browser and enter the following URL:

http://<management service hostname>.<domain>:<port>/em/

The default port value on a clean machine is 7777. However, if there are other instances running on the machine, then the port may be different.

The login page will be displayed. Enter the User Name and Password, and then click the Login button.

Click the Targets tab.

Click the Application Servers subtab.

From the Application Servers page, click the BEA WebLogic Server Domain to go to its home page.

The BEA WebLogic Server Domain Home page shows a rollup of information for the domain and its members. You can view the number of members in the domain, summary of their status and potential problem areas surrounding alerts and policy violations.

If at any time new clusters are added or J2EE servers removed from this domain, you can easily refresh domain membership from this page so that Grid Control will start monitoring the newly added targets or stop monitoring no longer used targets.

Click the Administration property page.

From the Administration page you can view job activity or blackouts against the domain and its members. You can use the Job System within Grid Control to automate common administration tasks. For example, you can schedule an Operating System job that performs a weekly operation using the weblogic.Admin command line utility.

You can blackout the domain and/or its members if for example you have scheduled downtime to perform backup operations, and do not want Grid Control to continue to collect monitoring data during that planned downtime.

Click the Members property page.

The Members page shows just a subset of the application servers we already have seen on the Application Servers subtab. It is simply a filtered list containing just the members of this domain. Let's drilldown to some of the domain's members to gain additional information on them. Click the BEA WebLogic Server Cluster link.

The Home page for the cluster appears. This page and other pages accessible from here are very similar to the domain's pages but with a few differences such as:

• The cluster target has state, so we represent its state on the home page. If at least one J2EE server within the cluster is up then the cluster is considered up. Remember, that for the domain, its availability is a rollup of the availability for its members.
• There is a Metrics property page.
• There is a J2EE Applications property page.

Click the Metrics property page

The Metrics page displays predefined performance metrics for the cluster. You can scan these metrics to get a sense of how the different J2EE servers in the cluster are performing, for example, if one is incurring more load than another. Such information may lead you to investigate further and to then improve distribution of load through configuration changes. Click the J2EE Applications property page

From this page you can see all applications deployed to the J2EE servers in the cluster. You can view real-time performance data for these applications or you can choose to display a variety of historical views as well, such as Last 24 hours or Last 7 days. Click the Application Name table column header

If you click the Application Name you can sort the applications by name and be able to compare load and execution time for the applications from the different servers. In this case, you can see that one server in the cluster that is hosting the MedRec application is incurring more load than the other. You may then want to go to the BEA WebLogic Administration Console to perform direct configuration edits to the cluster and servers. You are able to do that by clicking on the Administer WebLogic Server Domain link.

Click the Managed Server link.

From the Managed Server home page you can see the status of the server, its version, response and load information, and alerts. Also from the Home page you can view alerts for the host on which the J2EE server resides, or you can drilldown to the host itself to obtain further detail on the host's availability and performance. Such integration enables you to easily and quickly correlate performance problems between middleware software and the operating system on which it runs. Click the All Metrics link in Related Links section.

You can see the various metric categories that Grid Control monitors - Active Applications, EJB Transaction Metrics, JMS Server Metrics, Jrockit VM Runtime Metrics, Response, and so on. Over 150 performance metrics are monitored and/or collected. Click the plus sign next to Active Applications to expand it.

Click Application - Active Sessions metric to understand the number of open sessions for this server.

Click the MedRecEAR application name.

From the metric details page you can see various statistics concerning this metric as well as a graphical view of its values in real-time, historical, or your own customized timeframe and how the values compare with defined thresholds. Alert history is also provided to track past problems and comments/details about them. Click the Managed Server locator link to return to the managed server home page.

Now let's look at only those applications deployed to this particular server. Click the Applications property page.

You see similar performance information as you saw in context of the cluster such as, the load and response times being incurred by this server. Click the Performance property page.

From the Performance page, you can gain additional performance details on this server and its deployed applications. For instance, you can see resource and JDBC usage charts, as well as Top Servlets/JSPs or EJB Transactions.

Click the EJB Transactions link under the Performance Links section.

Use this page to monitor the performance of your EJB transactions. You may use the View Data menu to update the table based on current, real-time application performance, or based on historical data from the Management Repository. For example, you can use the View Data menu to see which transactions were the most active over the past 24 hours, over the past week, or over the past month.

Now let's look how you can proactively monitor BEA WebLogic environments using the same powerful monitoring features available for Oracle products. Click the Groups subtab.

Click on the Plug-ins group, to go to its home page.

This group contains a number of different plug-ins, including BEA WebLogic. The group home page presents administrators with a summary of the status, alerts and policy violations across all of the members of the group. Click the Charts property page.

When defining groups, administrators have the ability to include summary charts, which allow them to analyze collective performance of the group members. Here we can see different charts, displaying highest average/ lowest average/or statistical information across targets in the group. As you can see, metrics presented here are from different target types, such as BEA WebLogic and Microsoft Active Directory. Click the Launch Dashboard button.

System Monitoring Dashboard provides administrators with a near real-time view of open alerts against members of the group. The color-coded interface highlights problems using universal colors of alarm - red for critical issues, yellow for warning alerts, and green for normal conditions. The System Monitoring Dashboard significantly reduces the complexity of monitoring groups of targets.

Here you looked at how Groups functionality can be applied to BEA WebLogic, just like to any other Enterprise Manager managed target.

Similarly, you can use familiar monitoring features, such as alerts, notifications, blackouts, and templates for BEA WebLogic monitoring.

Click the Group: Plug-ins link on the dashboard.

Click the Web Application subtab. Web Application is a type of Service that you can monitor using Grid Control.

Here you see a list of Web Applications managed by Grid Control. Click the MedRec Web application from the list.

This is the home page for the MedRec Web Application (Medical Records is a J2EE application deployed on the clustered servers). You can quickly see the expected Service Level and the actual service levels. You can drilldown to obtain additional details on the service levels. Click the link for the Actual Service Level (%).

You get to see information such as the business days and hours that you are expected to meet the SLA and any violations to the service level over a particular time period. Click the MedRec locator link to return to the home page.

On the right side of the Home page you can see the status of key tests or transactions that have been created and are being monitored. Grid Control provides a means to record transactions to your web application - simply a series of URLs - and then play these transactions at user-defined intervals from different geographic locations. You can also specify thresholds for the transactions' response times. Such tests simulate end users accessing the web application so you can proactively monitor their response times, and be notified of potential problems before your real end users are impacted.

If there are any outstanding alerts, you will see those in the All Service Alerts. These alerts can encompass usage metrics, performance metrics, system metrics, or transactions that have exceeded user-defined thresholds.

Click the Charts property page.

The Charts page is completely customizable. You can identify any performance related metric or test or usage related metric chart to be displayed here so you can easily analyze data over time and identify any trends. Click the Test Performance property page.

From the Test Performance page you can determine the response times for the various tests that have been recorded and are being played by the different Beacons located throughout the world. Scroll down and click Expand All in the All Tests section.

You can quickly see the different response times for the Austin Beacon versus Denver Beacon.

Now let's look at the topology of this service. Click the Topology property page.

Here you see all of the infrastructure components that the Medical Records Web Application relies upon - Apache HTTP Server, BEA WebLogic Cluster, Oracle Database, etc. Currently, this service and its components are available; however, if the service were down, we would see visual indication of the root cause of service failure. Obviously, this is a simple example. Real production deployments are more complex with many more components and/or subservices.

Click the Page Performance property page.

This page helps you to clearly understand how the Web application is performing from the end-user perspective. At the top of the page is the Page Watch List which measures the end-user response time of critical pages as identified by you. You may want to add pages to the watch list that are absolutely critical to your business but that may not surface as the slowest pages of your application (for example, your application's login page). By using the Watch List you can keep a close watch on such important pages.

The middle of the page displays the Slowest Response Times for the Medical Records Web application. Here you can see the worst performing pages across your entire application as experienced by all users. As with the Page Watch List, you can see the total response time for each page and then view how much time was spent in the server as opposed to time spent in the network. Incomplete page load time is also represented with a separate bar. By default the Slowest Response Times are displayed by URL. However you can change the view to by Domain, Region, Visitor, or Web Server. These various views help you to analyze and scope the impact of performance problems and to prioritize repairs for system problems. Select Visitor from the View By drop-down list.

You can see that the table now shows the slowest response times by actual visitors to the number of samples and affiliated response times obtained from each. By tracking the response time of visitors, this ensures that critical customers, executives, or any other VIP visitors experience a superior response time. Let's return to the URL view and drilldown into the slowest page. Select URL from View By dropdown list

Click the slowest page link in table.

This drilldown provides a combined chart that shows the response time history for all the samples and the samples distribution trends. Having such detailed information concerning the end-user experience as they enter and navigate your Web application enables you to better understand your end-user experience and to tackle potential issues before they seriously impact users.

Click the Reports tab.

Select BEA WebLogic Server Cluster from the Target Type drop-down list and click the Go button.

Click the Availability History (Target) report.

Click the flashlight icon to select the target.

Select BEA WebLogic Server Cluster from the Target Type drop-down list, select the BEA WebLogic Server Cluster target and click the Select button.

Click the Continue button.

This report presents information about the availability of the server cluster. Click Return to Report Definitions link at the bottom of the page.

Click the Application Server Clusters Configuration report.

This report provides an overview of the availability, alerts, policy violations, configuration information across all application server clusters in the enterprise - whether Oracle or non-Oracle.