Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

WebLogic

The WebLogic monitor collects data that enables you to determine whether there is a performance problem or a failure on a WebLogic application server. Using the data that the WebLogic monitor collects, you can determine the root cause of the issue by generating a report (see Reports for J2EE Applications for more information).

The WebLogic monitor collects the following metrics from a WebLogic server:

VariablesMetrics
Connection Pools
FailuresToReconnectCount

The number of times that the connection pool failed to reconnect to a data store.

ConnectionDelayTime

The average time that was required to connect to a connection pool.

ActiveConnectionsCurrentCount

The current number of active connections in a JDBC connection pool.

ActiveConnectionsHighCount

The highest number of active connections in a JDBC connection pool.

LeakedConnectionsCount

The total number of connections that are checked out of, but not returned to, the connection pool.

CurrCapacity

The current number of database connections in the JDBC connection pool.

NumAvailable

The number of available sessions in the session pool that are not currently used.

WaitingForConnectionCurrentCount

The current number of requests that are waiting for a connection to the connection pool.

Per EJB
AccessTotalCount

The total number of times an attempt was made to get an EJB instance from the free pool.

BeansInCurrentUseCount

The number of EJB instances in the free pool which are currently in use.

CachedBeansCurrentCount

The total number of EJBs that are in the execution cache.

ActivationCount

The number of EJBs that are activated.

Other
HeapSizeCurrent

The amount of memory, in bytes, that is in the WebLogic server’s JVM heap.

HeapFreeCurrent

The current amount of free memory, in bytes, that is in the WebLogic server’s JVM heap.

OpenSocketsCurrentCount

The current number sockets on the server that are open and receiving requests.

AcceptBacklog

The number of requests that are waiting for a TCP connection.

ExecuteThreadCurrentIdleCount

The number of threads in the server’s execution queue that are idle or which are not used to process data.

PendingRequestCurrentCount

The number of pending requests that are in the server’s execution queue.

TransactionCommittedTotalCount

The total number of transactions that are processed by the WebLogic server.

TransactionRolledBackTotalCount

The total number of transactions that are rolled back.

InvocationTotalCount

The total number of times that a servlet running on the WebLogic server was invoked.

Before you can use the WebLogic monitors, you must perform additional steps outside of Uptime Infrastructure Monitor. The steps performed depend on the version of your WebLogic server: WebLogic monitoring requires that you enable the Internet Inter-Orb Protocol (IIOP) on your WebLogic server.

Monitoring WebLogic

In order for Uptime Infrastructure Monitor to collect information from a WebLogic server, the the Internet Inter-Orb Protocol (IIOP) must be enabled on your WebLogic server.

To enable prepare your WebLogic server for monitoring, do the following:

  1. Open your WebLogic server in the administration console. 
  2. In the settings for the server, flick the Protocols tab, then the IIOP tab.
  3. Enable IIOP on your server.
  4. Enter a Default IIOP Username.
  5. Enter and confirm a Default IIOP Password for the user.

    Info

    The user name and password created here are used when configuring a WebLogic service monitor in Uptime Infrastructure Monitor.


  6. If possible, restart the WebLogic server.

Configuring WebLogic Monitors

To configure monitors for WebLogic, do the following:

  1. In the WebLogic monitor template, complete the monitor information fields.
    To learn how to configure monitor information fields, see Monitor Identification.
  2. Complete the following fields:
    • Username
      The IIOP user name you created when you first enabled IIOP on the WebLogic server.
    • Password
      The IIOP password you created when you first enabled IIOP on the WebLogic server.
    • WebLogic Port
      The number of the port number on which the WebLogic server is listening. The default is 7001.
  3. Limit the returned results of a specific resource type by completing some of the following fields:
    • Number of Results
      A limit on the number of matching application resources, whose metrics are collected.
    • EJB Name Regex Filter
      A regular expression used to limit metrics collection to a specific EJB or set of EJBs.
    • Servlet Name Regex Filter
      A regular expression used to limit metrics collection to a specific servlet.
    • JDBC Resource Name Regex Filter
      A regular expression used to limit metrics collection to a specific JDBC resource.
  4. Specify a warning and critical threshold for the following:
    • the appropriate WebLogic metrics
      For more information about each metric, see Connection Pools.
    • Response Time
      This is the length of time a service check takes to complete.
    For more information on using thresholds to set alerts, see Configuring Warning and Critical Thresholds.
  5. To save the data from the thresholds for graphing or reporting, click the Save for Graphing checkbox beside each of the metrics that you selected in the previous step.
  6. Complete the following settings:
  7. Click Finish.

Using WebLogic Monitors when SSL is Enabled (Linux)

To use WebLogic Monitors when SSL is enabled on a Linux machine, do the following:

  1. Download the WebLogic certificate. Use the following steps to download the certificate from your WebLogic server or you can use any other method, such as downloading the certificate with the help of any Web browser.
    1. Open the terminal, and then change the directory and run following command:
      openssl s_client -host <hostname or IP> -port <SSL enabled port number>
      For example: openssl s_client -host 10.1.40.55 -port 7002
    2. Into a new file, copy the output text from "-----BEGIN CERTIFICATE-----" to "-----END CERTIFICATE-----" and then save it.
  2. Import the certificate into Java truststore.
    1. Open a terminal and change the directory to <Uptime Installation Directory>jre//lib/security
      For example: cd  /usr/local/uptime/jre/lib/security
    2. Run the following command:
      keytool -keystore cacerts -importcert -alias <alias name> -file <certificate file full path>
      For example: keytool -keystore cacerts -importcert -alias weblogic -file  /root/Desktop/certs/newroot.cer
  3. Restart the uptime_core service.
    • Open the terminal and run following command:
      service uptime_core restart
  4. Configure the WebLogic Service Monitor.
    • While configuring the WebLogic Service Monitor, check the Use SSL checkbox and provide the SSL-enabled port number in the Port field.

Using WebLogic Monitors when SSL is Enabled (Windows)

To use WebLogic Monitors when SSL is enabled on a Windows machine, do the following:

  1. Download the WebLogic certificate. Use the following steps to download the certificate from your WebLogic server or you can use any other method, such as downloading the certificate with the help of any Web browser.
    1. Download OpenSSL. For Windows, use the following link: http://gnuwin32.sourceforge.net/packages/openssl.htm
    2. Install OpenSSL.
    3. Open a command prompt run as administrator, and change the directory to the bin location where you installed OpenSSL.
    4. Run following command: openssl s_client -host <hostname or IP> -port <SSL enabled port number>
      For example: openssl s_client -host 10.1.40.55 -port 7002
    5. Copy the output text from "-----BEGIN CERTIFICATE-----" to "-----END CERTIFICATE-----" in a new text file and save it.
  2. Import the certificate into Java truststore.
    1. Open Command prompt (Run as administrator) and change directory to <Uptime Installation Directory>/jre/lib/security
      For example: cd C:\Program Files\uptimesoftware\uptime\jre7\lib\security
    2. Run the following command:
      keytool -keystore cacerts -importcert -alias <alias name> -file <certifcate file full path>
      For example: keytool -keystore cacerts -importcert -alias weblogic -file C:\certs\newroot.cer
  3. Restart Uptime services.
    1. Open services.msc.
    2. Restart the following services: Uptime Controller, Uptime Data Collector and Uptime Web Browser.
  4. Configure the WebLogic Service Monitor.
    • While configuring WebLogic Service Monitor, check the Use SSL checkbox and provide the SSL-enabled port number in the Port field.

WebSphere

WebSphere is a software platform that provides firms with an environment for developing and deploying Web services and E-Commerce applications. Because WebSphere is large and complex, it can be difficult to pinpoint the source of a problem, especially when that problem is intermittent.

The Uptime Infrastructure Monitor WebSphere monitor collects data that you can use to generate a report, which gives you a historical view of problems that occur on a WebSphere server. For more information about viewing WebSphere issues, see See WebSphere Report.

The WebSphere monitor enables you to collect data so that you can:

  • determine whether the server can cope with its load
  • determine the cause of problems with the server
  • collect and retain data for later graphing and reporting

The following table lists the counters the WebSphere monitor collects from a WebSphere Application Server.

Variable

Counters

Connection pools

PoolSize

The size of the connection pool to the data source.

FreePoolSize

The number of free connections in the pool.

PercentUsed

The percentage of the connection pool that is currently in use.

WaitTime

The average time, in milliseconds, that a connection is used. The average time is the difference between the time at which the connection is allocated and the time at which it is returned.


CreateCount

The total number of connections that were created.

CloseCount

The total number of connections that were closed.

WaitingThreadCount

The number of threads that are currently waiting for a connection.

UseTime

The average time, in milliseconds, that a connection is used. The average use time is the difference between the time at which the connection is allocated and that time at which it is returned.

Per EJB

CreateCount

The number of times that the Enterprise JavaBeans that are running on the server were created.

RemoveCount

The number of times that the EJBs were removed.

PassivateCount

The number of times that EJBs were removed from the cache. Note that passivation preserves the state of the EJBs on the disk

MethodCallCount

The total number of method calls that were made to the EJBs.

MethodResponseTime

The average response time, in milliseconds, on the bean methods.

Java Virtual Machine

cpuUsage

The percent of CPU resources that were used since the last query.

HeapSize

The total amount of memory that is available for the JVM.

UsedMemory

The amount of memory that is used by the JVM.

Other

ActiveCount

The number of global transactions which are concurrently active.

CommittedCount

The total number of global transactions that are committed.

RolledBackCount

The total number of global transactions that were rolled back.

LiveCount

The number of servlet sessions that are currently cached in memory.

PoolSize

The average number of threads in the servlet connection thread pool.

TimeSinceLastActivated

The difference, in milliseconds, between the previous and current access time stamps of a servlet session. This counter does not include session time out values.

Before Uptime Infrastructure Monitor can start collecting performance data from a WebSphere server, you must deploy the WebSphere performance servlet.

Deploying the WebSphere Performance Servlet

The WebSphere performance servlet uses WebSphere’s Performance Monitor Interface (PMI) infrastructure to retrieve performance information from a WebSphere Application Server. The information that the servlet collects is saved to an XML file.

By default, the PMI is enabled on the WebSphere server and is set to collect the performance metrics that Uptime Infrastructure Monitor supports. Before Uptime Infrastructure Monitor can begin collecting information from a WebSphere server, you must deploy the performance servlet in the WebSphere directory that contains your Web application.

Info
The following steps must be completed for each Web application server that you want to monitor with Uptime Infrastructure Monitor.

To deploy the performance servlet do the following:

  1. On the WebSphere server, locate the following file:
    install_root/perfServletApp.ear
    Where install_root is the directory under which WebSphere is installed.
  2. Copy the file perfServletApp.ear to the directory in which your Web application is installed. For example:
    install_root/installedApps/<cell_name>/DefaultApplication.ear/DefaultApplication.war/WEB-INF/classes
    Where:
    •  install_root is the directory under which WebSphere is installed.
    •  <cell_name> is the name of the WebSphere node under which your Web application is installed.
Deploying the Performance Servlet on WebSphere 

If you are using WebSphere Application Server, you must change two settings in the WebSphere management console to avoid an Access Denied error when Uptime Infrastructure Monitor attempts to connect to the performance servlet to collect metrics.

To make the changes, do the following:

  1. In the WebSphere management console, modify the following settings:
  2. Under Security - Secure administration, applications, and infrastructure, enable the Application Security option.
  3. Under Enterprise Applications - perfServletApp - Security role to user/group mapping, disable the Everyone option, and enable the All authenticated option.
  4. Restart the server. Uptime Infrastructure Monitor should now be able to connect to the servlet and gather performance metrics.

Configuring WebSphere Monitors

To configure a WebSphere monitor, do the following:

  1. On the WebSphere monitor template, complete the monitor information fields.
    To learn how to configure monitor information fields, see Monitor Identification.
  2. Complete the following fields:
    • WebSphere Port
      The number of the port number on which WebSphere is listening. The default is 9080.
    • Response Time
      Enter the Warning and Critical Response Time thresholds. For more information, see Configuring Warning and Critical Thresholds.
  3. Optionally, click the Save for Graphing checkbox beside the Response Time option to save the data for a metric to the DataStore, which can be used to generate a report or graph.
  4. Complete the following settings:
  5. Click Finish.

Web Application Transactions

Info

Web Application Transaction Monitor is Java-based and does NOT work with modern browsers. Legacy customers with older setups may use this feature, however creating new monitors is disabled. This monitor works only if your UIM installation already has previously-captured Web Application Transaction monitor Monitor recordings. This does not affect previously-configured Web Application Transaction Monitorsmonitors.

A Web transaction is a series of Web pages that together fulfill a specific function for end users. A common Web transaction example is the checkout process on an e-commerce site, during which end users select a shipping option, pay for their items, and have their credit card verified. During this transaction, many calls are made to the application and data layers as the end-user provides, and the servers process, information.

Although the type of Web application that is monitored by Uptime Infrastructure Monitor users is typically different (e.g., intranet applications), the structure of the transaction is the same: an end user steps through a sequence of Web pages that take inputted information and initiate appropriate actions with application or database servers.

The Uptime Infrastructure Monitor Web Application Transaction monitor tests the speed and availability of an end-user Web transaction. Specifically, the Web Application Transaction monitor performs two roles:

  • it confirms the general availability of an end-user Web transaction by executing a previously recorded script then reporting whether all pages that make up the web transaction were successfully processed
  • it reports on the speed of the Web transaction both as a whole, and broken down by previously defined stages

Both the availability and speed of Web transactions can be used in reports and as triggers for alerts.

Using the Web Application Transaction Monitor

Use the Web Application Transaction monitor to record a series of URLs that together make up a transaction. This recording should be of a transaction that acts as a suitable test of your Web application delivery infrastructure.

During the recording process, declare checkpoints that demarcate significant stages in the Web transaction. Isolating the different stages in an end-user transaction allows you to view stage-specific speed tests in reports, which ultimately helps you identify where problem areas exist.

For example, if a transaction relies on processing on the application layer, makes multiple calls to the data layer, and is accessible worldwide, creating checkpoints during the recording phase helps you ascertain whether the application server, database management server, or network may be the reason behind a poorly performing transaction.

The following sample checkpoints could be created for an e-commerce transaction:

  • Browse Catalog
  • Add to Shopping Cart
  • Checkout
  • Credit Card Validation

The following sample checkpoints could be created for an internal office transaction:

  • Login
  • Browse Orders
  • View Order Details

Configuring Web Application Transaction Monitors

You can define Web application transactions by manually stepping through one and declaring checkpoints at key stages:

  1. Open a Web browser, and configure its proxy settings so that you can record a transaction:
    • Open the dialog where network and connection settings are made.
    • Configure the browser’s proxy to “localhost” on port 8001.
    • Ensure these settings also are applied to SSL or secure communications.
    • Set the proxy to bypass the Monitoring Station.
      This step requires you to select an option such as “no proxy” or “bypass proxy server,” and may also require you to manually enter your Monitoring Station URL or IP address.
    Using the monitor as a proxy allows it to intercept Web traffic as you generate it.
  2. In the browser, navigate to the starting point of the Web application whose performance you are monitoring.
  3. In the Uptime Infrastructure Monitor Add Service window, select the Web Application Transaction monitor, then click Continue.
    The Web Application Transaction Recorder is displayed, and the monitor is now listening on port 8001 for traffic.

    Info

    Ensure your browser's Java plugin is updated to the latest, most secure version.


  4. Begin stepping through the Web transaction as an end user, providing the required data or actions.
    Every URL visited during the transaction is logged and displayed in the recorder.

    Info
    The Web Application Transaction monitor records all data inputted during recording: this includes any login information. It is recommended that you use a test account for the Web application, otherwise any user data is visible in the recorded script.


  5. At each major step in the Web transaction that signals a new analysis point, enter a checkpoint name in the text box at the top of the window, then click Mark Checkpoint.
    For example, create a checkpoint at a transaction step where the application takes user-inputted data and makes database calls.

    Info
    You can later set Warning and Critical thresholds that apply to every segment declared in your recording. It is recommended that the divisions between your checkpoint intervals are reasonably consistent.


  6. Continue to repeat steps 4 and 5 until you have completed enough of the Web transaction to test it, then click Next.
  7. Complete the monitor information fields.
    To learn how to configure monitor information fields, see Monitor Identification.

    Info
    Even though the Web application performance is not directly tied to an Element’s performance, making this selection is still required: the service based on this monitor needs to be associated with an Element in order to be viewed in areas such as Global Scan or Infrastructure.


  8. Configure the Web Application Transaction Settings:
    • Script to play back
      If desired, optimize the playback script (e.g., remove extraneous URLs such as image downloads).
    • Text that must appear
      Enter a text string that can be used to confirm the script playback was successful (e.g., a phrase that appears on the final page of the application). If the monitor does not find this text, its status changes to Critical. By providing mandatory text, you can ensure an alert is triggered in cases where a Web application is malfunctioning, but checkpoint-to-checkpoint times are fast enough to fulfill response time requirements.
    • Text that must not appear
      Enter a text string that should not appear at any point during the script playback (e.g., a client- or server-error HTTP status code). If the monitor finds this text, its status changes to Critical. Use this feature, as you would use mandatory text, to ensure a malfunctioning application triggers an alert.
    • User Agent String
      Select the Web browser and version used to record the script. This selection determines the user agent string used in the HTTP requests to the application server, and should be provided in case the application blocks access by scripts.
    • Checkpoint Times
      Enter the Warning and Critical Checkpoint Time thresholds. An alert is generated with these thresholds if any of the recorded Web transaction’s checkpoint times exceeds the supplied values.
    • Response Time
      Enter the Warning and Critical Response Time thresholds. An alert is generated with this threshold if the entire transaction playback time exceeds the supplied values. For more information, see See Configuring Warning and Critical Thresholds .
  9. Enter Warning- and Critical-level thresholds for the overall response time of the monitor.
    Most of the monitor’s Response Time is comprised of the Delivery Time and the Retrieve Time. Ensure the values provided for the Response Time thresholds roughly correspond with those provided for the other thresholds. For more information, see Configuring Warning and Critical Thresholds.
  10. Complete the following settings:
  11. Click Finish.

Viewing and Diagnosing Web Transaction Performance

To view Web transaction performance via playback, create a Service Metrics graph for the Web Application Transaction monitor’s system. To generate a Service Metrics graph, either select the system to which the Web Application Transaction monitor is associated in Infrastructure, or the monitor itself in the main Services panel. Click the Graphics tab, then click Service Metrics.

The Service Metrics graph shows how long each transaction segment took to complete during playback, and in doing so, provides an end-to-end performance snapshot of the components of your infrastructure that deliver applications to users. For example, the following metrics graph shows that the execution of the comments found in checkpoint3 took excessively long to complete:


Because other checkpoints performed well, the poor performance of a single checkpoint indicates possible issues with a particular server, and not the network infrastructure. This theory can be further investigated by looking at the performance metrics for the server in question.

Use the Web Application Transaction monitor’s playback script to verify which servers are used during a problem checkpoint. In the Service Instances panel, click the monitor to view the script, then locate the system that is accessed (e.g., with GET and POST commands). Use this as an investigative starting point: although an application or Web server is often referenced in the script, the problem may be found deeper in the application stack (e.g., a database server to which the referenced Web server makes calls during the checkpoint).

Using Web Transaction Performance in SLA Reports

Your Web applications typically call on systems on the application and database tiers, as well as make use of internal- and external-facing network devices. Because the Web Application Transaction monitor directly reports on the performance of a Web transaction, it in effect indirectly reports on the health of your IT infrastructure as a whole.

This broad reporting coverage makes the Web Application Transaction monitor an ideal monitor to include in service level agreement reports.

For more information on SLA reports, see Reports for Service Level Agreements.

...

Live Splunk Listener

Live Splunks are scheduled searches of Splunk queries that are saved on the Splunk server. A Live Splunk automatically runs a search, can initiate an alert, and can perform actions based on that alert. You can, for example, set up a Live Splunk to search for all critical error conditions.

The Live Splunk Listener monitor enables you to capture the information generated by a Live Splunk (from Splunk 4.x only). This monitor is very similar to the External Check monitor, and uses scripts that are bundled with Uptime Infrastructure Monitor (found in the /scripts subdirectory) to return Live Splunk information to the Monitoring Station.

To use this monitor, you must first modify the two Splunk scripts that are included with Uptime Infrastructure Monitor:

  • alertUptimeStatusHandler.sh
  • alertUptime.py

This pair of scripts take the following options:

  • --message
    A message that is returned to the Uptime Infrastructure Monitor Monitoring Station. For example, if the Live Splunk is configured to search for warning conditions, you can enter the message “Changed to WARN” .
  •  --status
    The script can return the following status codes:
    •  0 - OK
      The services are functioning properly.
    •  1 - Warning
      There is a potential problem with one of more of the monitored services.
    •  2 - Critical
      There is a critical problem with one or more of the monitored services.
    •  3 - Unknown
      There is an error in the configuration of the monitor itself, or Uptime Infrastructure Monitor cannot execute the service check.
  •  --monitor
    The name of the Uptime Infrastructure Monitor monitor to which the information from the Live Splunk is directed.

The following is an example of the script with all of its options specified:

No Format
nopaneltrue
alertUptimeStatusHandler.sh --message="sendmail has some traffic going through new command!"
                            --status=2 --monitorName="Live Splunk"

Uptime Infrastructure Monitor captures the output from the script, which appears in the service status section of the Global Scan dashboard (see Understanding the Status of Services). The Uptime Infrastructure Monitor monitoring framework picks up any error codes and triggers the appropriate monitoring action.

Before You Begin

Before you can monitor Live Splunks generated on a Splunk server, you must do the following:

  1. Edit the alertUptime.py script to point to the Uptime Infrastructure Monitor Monitoring Station:
    • Navigate to the /scripts directory on the Monitoring Station.
    • Open the file alertUptime.py in a text editor.
    • Find the following entry in the file:

      No Format
      nopaneltrue
      host = "uptime-host"
      port = "9996"


    • Change the values for host and port to the host name and port of the Monitoring Station.
    • Save and close the file.
  2. Edit the alertUptimeStatusHandler.sh script to configure how the Live Splunk is reported on the Monitoring Station:
    • Open alertUptimeStatusHandler.sh in a text editor (found in the /scripts directory on the Monitoring Station).
    • For the message option, enter a diagnostic message that accompanies a Live Splunk captured by the Uptime Infrastructure Monitor service monitor.
    • For the status option, enter the status of the monitored service.
    • For the monitorName option, enter the name of the service monitor that is listening to the Live Splunk.
    • Save and close the file.
  3. Copy the alertUptimeStatusHandler.sh and alertUptime.py scripts from the Monitoring Station’s /scripts directory to the
    /data/splunk/bin/scripts directory on the Splunk server.
  4. Configure a Live Splunk. For information on configuring Live Splunks, see the Splunk user manual.
    When setting up your Live Splunk, select the Run the shell script option on the configuration page. Then, enter the path to alertUptimeStatusHandler.sh in the field.

Configuring the Live Splunk Listener Monitor

To configure a Live Splunk Listener monitor, do the following:

  1. Complete the monitor information fields.
    To learn how to configure monitor information fields, see Monitor Identification.
  2. Complete the following settings:
  3. Click Finish.

Save

Save