Serviceability and troubleshooting
The Liberty profile has several tools to help identify problems with the server and the applications that are deployed to it.
This chapter contains the following sections:
7.1 Logs and trace
The Liberty profile can produce various traces that enable you to debug issues with the server and your applications. By default, no tracing is enabled. However, you can enable tracing if required. In this section, we describe where to find the output and how to configure what trace data is collected.
7.1.1 Inspecting the output logs and trace
The Liberty profile server records limited information by default. This basic information is useful for debugging common configuration issues. You can view the output logs by opening the ${server.output.dir}/logs/messages.log file. Example 7-1 shows a sample output from a server start.
Example 7-1 Sample content of the message.log file
[5/19/15 14:22:41:589 EDT] 00000707 com.ibm.ws.app.manager.AppMessageHelper I CWWKZ0018I: Starting application ITSOWeb.
[5/19/15 14:22:41:691 EDT] 00000707 com.ibm.ws.webcontainer.osgi.webapp.WebGroup I SRVE0169I: Loading Web Module: ITSOWeb.
[5/19/15 14:22:41:692 EDT] 00000707 com.ibm.ws.webcontainer I SRVE0250I: Web Module ITSOWeb has been bound to default_host.
[5/19/15 14:22:41:692 EDT] 00000707 com.ibm.ws.http.internal.VirtualHostImpl A CWWKT0016I: Web application available (default_host): http://localhost:9087/ITSOWeb/
[5/19/15 14:22:41:694 EDT] 00000707 com.ibm.ws.app.manager.AppMessageHelper A CWWKZ0003I: The application ITSOWeb updated in 0.104 seconds.
[5/19/15 14:23:29:560 EDT] 00000705 com.ibm.ws.session.WASSessionCore I SESN0176I: A new session context will be created for application key default_host/ITSOWeb
[5/19/15 14:23:29:560 EDT] 00000705 com.ibm.ws.util I SESN0172I: The session manager is using the Java default SecureRandom implementation for session ID generation.
[5/19/15 14:23:29:568 EDT] 00000705 com.ibm.ws.jsp I JSPG8502I: The value of the JSP attribute jdkSourceLevel is "15".
[5/19/15 14:23:29:621 EDT] 00000705 org.apache.myfaces.config.DefaultFacesConfigurationProvider I Reading standard config META-INF/standard-faces-config.xml
[5/19/15 14:23:29:644 EDT] 00000705 org.apache.myfaces.config.DefaultFacesConfigurationProvider I Reading config /WEB-INF/faces-config.xml
[5/19/15 14:23:29:708 EDT] 00000705 org.apache.myfaces.application.ApplicationImpl I Couldn't discover the current project stage, using Production
[5/19/15 14:23:29:708 EDT] 00000705 org.apache.myfaces.config.FacesConfigurator I Serialization provider : class org.apache.myfaces.shared_impl.util.serial.DefaultSerialFactory
[5/19/15 14:23:29:708 EDT] 00000705 org.apache.myfaces.webapp.AbstractFacesInitializer I ServletContext 'C:IBMch3_ITSOWebITSOWebWebContent' initialized.
[5/19/15 14:23:29:708 EDT] 00000705 com.ibm.ws.webcontainer.servlet I SRVE0242I: [ITSOWeb] [/ITSOWeb] [Faces Servlet]: Initialization successful.
[5/19/15 14:23:29:724 EDT] 00000705 apache.wink.server.internal.application.ApplicationProcessor I The following JAX-RS application has been processed: com.ibm.ws.jaxrs.webcontainer.JAXRSDefaultApplicationSubclassProxy
[5/19/15 14:23:29:724 EDT] 00000705 org.apache.wink.server.internal.log.Resources I The server has registered the JAX-RS resource class com.itso.example.ITSOJaxrsExample with @Path(/example).
[5/19/15 14:23:29:724 EDT] 00000705 org.apache.wink.server.internal.log.Providers I There are no custom JAX-RS providers defined in the application.
[5/19/15 14:23:29:806 EDT] 00000705 com.ibm.ws.webcontainer.servlet I SRVE0242I: [ITSOWeb] [/ITSOWeb] [JAX-RS Servlet]: Initialization successful.
The log shows the server start procedure. First, the kernel starts. Then, the feature manager initializes and reads the configuration from the server.xml file. The server is configured to listen on a given port. Then, the ITSOWeb application is started and finally the server is ready to serve the application.
7.1.2 Configuration of an additional trace
A typical task when working with applications is to enable and configure the logging properties of the runtime server to inspect for problems. The Liberty profile server can be configured to gather debug information for both runtime issues and application code.
The Liberty profile server, when started, is configured to capture a minimal amount of trace information. You can modify this default by specifying properties in the server configuration file or bootstrap.properties file. Open Service Gateway initiative (OSGi) logging output is intercepted and delivered through the trace support. There is also interception of java.util.logging output.
To learn more about configuring the logging service, see the IBM Knowledge Center at the following website:
Configuring trace in the servers configuration
To configure an additional trace in the servers configuration, follow these steps:
1. Open the Servers view in your workbench and double-click Server Configuration for your server. This opens your server.xml file. Select the Design tab.
2. Under the Configuration Structure, select Server Configuration and click Add, as shown in Figure 7-1.
Figure 7-1 Adding the logging option to the server configuration
3. Select Logging and click OK.
4. Ensure that logging is selected under the Configuration Structure. You can now configure logging in the Logging details section, as shown in Figure 7-2.
Figure 7-2 Entering the trace details
The Logging details window allows you to configure many aspects of logging, including the location of the logs and where they are stored. The Trace Specification defines what information to capture in the logs. In our example, we capture information-level messages for all classes. In addition, we chose to capture all debug or higher-level messages for any
com.itso.example.* classes.
The trace.log file is located by default in the ${server.output.dir}/logs/ directory.
For information about how to add logging to your applications, see the following website:
Configuring trace using bootstrap.properties
Using the server configuration file to enable logging is an easy and efficient method. However, the following list notes some cases where you might want to put logging properties in to the bootstrap.properties file:
•When logging is required before the configuration processing occurs at server start (this might be required for IBM support for debugging a server start problem).
•When the server.xml configuration is shared by multiple server instances, and logging is only required on one server (then the bootstrap.properties file for that server can be modified).
Example 7-2 shows a sample bootstrap.properties file that enables tracing of any com.itso.example.* classes.
Example 7-2 A sample bootstrap.properties file
# New trace messages are written to the end of the file (true or false)
com.ibm.ws.logging.trace.append = "true"
# maximum size of e;ach trace file (in MB)
com.ibm.ws.logging.trace.max.file.size = 2
# maximum number of trace files
com.ibm.ws.logging.trace.max.files = 2
# Trace format (basic or advanced)
com.ibm.ws.logging.trace.format = "basic"
# Trace settings string - this string enables all trace
com.ibm.ws.logging.trace.specification = com.itso.example.*=debug
7.2 Server memory dump
To capture state information of a Liberty profile server, you can use the dump command. This can be useful for problem diagnosis of a Liberty profile server.
The directory of results that is generated by the dump command contains server configuration, log information, and details of the deployed applications in the workarea directory. The dump command can be used against a running or stopped server. If the server is running, the following additional information is gathered:
•State of each OSGi bundle in the server
•Wiring information for each OSGi bundle in the server
•Component list managed by the Service Component Runtime (SCR)
•Detailed information of each component from SCR
•The current state of all requests still running in the system (if the requestTiming-1.0 feature is enabled)
•The statistics about each of the JDBC requests the server has tracked (if timedOperations-1.0 feature is enabled)
The following syntax is an example of running the dump command:
server dump server1 --archive=c: mpserver1_dump.zip
You can also create a memory dump of the Liberty profile server by using the WebSphere developer tools. This is done by right-clicking the server in the Servers view and selecting Utilities → Generate Dump for Support. You have the option to generate a server or a JVM dump. The server dump can contain heap, system, or thread information. The JVM dump can contain heap or system information.
7.3 MBeans and JConsole
To monitor the Liberty profile server runtime characteristics, administrators and developers can use standard tools for Java runtimes, such as the JConsole.
The Liberty profile offers the monitor-1.0 feature. This feature allows users to track information about the Liberty profile server runtime, such as JVM, web applications, and the thread pool. To enable this monitoring, add the monitor-1.0 feature to the server.xml configuration so that the following MXBeans are available:
•WebSphere:type=JvmStats
•WebSphere:type=ServletStats,name=*
•WebSphere:type=ThreadPoolStats,name=Default Executor
•[8.5.5.0 or later]org.apache.cxf:type=WebServiceStats,service=*,port=*
•[8.5.5.0 or later]WebSphere:type=SessionStats,name=*
•[8.5.5.0 or later]WebSphere:type=ConnectionPool,name=*
For more information about monitoring the Liberty profile using MXBeans, see the following website:
JConsole is shipped as part of the Java Runtime package. To run JConsole against the Liberty profile, start it from the command line, as shown in the following syntax:
C:Javajdk1.7.0_67in>jconsole.exe
When JConsole launches, a welcome page opens. You must connect to the Java process that runs the Liberty profile. The connection is made by logging in. The JConsole process must run under the same operating system user ID and use the same Java runtime as the server. As illustrated in Figure 7-3, we used the local server for our example.
Figure 7-3 Establishing a connection using JConsole
The JConsole loads all runtime information into the tool. This includes information about the Java runtime, heap size, or processor usage, as illustrated in Figure 7-4.
Figure 7-4 Example of monitoring the output information using JConsole
Using the JConsole tool, you can also trigger MBean operations that are part of the Liberty profile. MBeans are available under the MBeans tab. Figure 7-5 shows an example of issuing a restart command on the ITSOWeb application.
Figure 7-5 Issuing a restart request for an application using MBeans
If you enabled the monitoring infrastructure in Liberty, you can also access additional MXBeans such as JvmStats, as illustrated in Figure 7-6.
Figure 7-6 Viewing JVMStats using JConsole
7.4 OSGi Debug console
The Liberty profile server provides the osgiConsole-1.0 feature that helps you administer the OSGi applications and features and also can be used for debugging. It can be used to display information about bundles, packages, and services that may be useful when developing your own features for product extensions.
To set the console, follow the steps in “OSGi console” on page 108.
After configuring the feature and restarting the server, you can access the OSGi console by issuing a telnet command to the console port as in Example 7-3.
Example 7-3  
C:>telnet localhost 5471
Connecting To localhost
osgi>
Type help to view a list of the options that are available in the OSGi console. For example, the ss command returns a summary status of all installed bundles.
7.5 Event logging feature
The new event logging feature helps you debug your Liberty profile applications by creating log entries for events such as JDBC, servlet, or HTTP requests. This feature enables logging events and their duration. You can control which event types are to be logged, the minimum duration to trigger the logging, the log mode, and the sample rate. This gives you the opportunity to debug slow running components of your applications and it can be a good starting point for tuning the applications and their runtime environment.
The eventLogging feature is not included in the runtime by default. To install the feature into your Liberty runtime, use the featureManager command as follows:
featureManager install eventLogging-1.0
To enable this feature, you need to add the eventLogging-1.0 feature to the featureManager section of your server.xml file. To configure this feature, you can set the following properties in the server.xml configuration file:
•eventTypes: This property lets you select which type of events are logged. You can log more than one type of event by including a comma-delimited list. By default, invocation of all types of events is logged.
•logMode: This property lets you select between entry, exit, or both entry and exit types of events to be logged. So, the available values for the logMode property can be entry, exit, or entryExit. To set this property, you need to include a line such as in Example 7-4 in the server.xml configuration file.
Example 7-4 The eventLogging logMode property
<eventLogging logMode="entryExit" />
•sampleRate: For example, to log the events from one of every five requests, you need to set a value of 5 for this property. The default value is 1, meaning that events from all requests are to be logged. To set this property, you need to include a line such as in Example 7-5.
Example 7-5 The eventLogging sampleRate property
<eventLogging sampleRate="2" />
•minDuration: This property lets you select the minimum duration of the events to be logged. The default value is 500 milliseconds. This means that by default, only exit events that are longer that 500 ms will be logged. To log all events, you need to set the value to 0. The value must contain a positive integer followed by a unit of time, which can be hours (h), minutes (m), seconds (s), or milliseconds (ms). If no unit of time is specified, it defaults to milliseconds. So, for a value of 1 second, the value can be 1000, 1 s, or 1000 ms. To set this property, you need to include a line such as in Example 7-6.
Example 7-6 The eventLogging minDuration property
<eventLogging minDuration="1000" />
•includeContextInfo: This property lets you decide whether or not to include context information in the log entries. The default value is true, but you can turn it off by setting the false value as in Example 7-7 on page 213. You can configure this property in the server.xml configuration file of the Liberty profile server.
Example 7-7 The eventLogging includeContextinfo property
<eventLogging includeContextInfo="false" />
7.6 Slow request detection and hung request detection capabilities
The requestTiming-1.0 feature provides detailed information about any servlet requests that take longer than a configurable amount of time to run. It also automatically collects java cores from the server when requests are detected to be hung to facilitate problem determination.
To enable this feature, you have to add the requestTiming-1.0 short name to the list of features in the server.xml configuration file of your Liberty profile server. To configure this feature, you can set values for the following parameters:
•slowRequestThreshold: The value that you set for this parameter is the amount of time a request can run before it is considered slow. You can specify an integer value followed by a unit of time, which can be hours (h), minutes (m), seconds (s), or milliseconds (ms). Combined units of time are allowed, for example 1m1s, which means 61 seconds. The default value is 10 seconds. If you need to disable slow request timing, set the value to 0. Example 7-8 shows an example of configuring this parameter for 300 milliseconds. A request duration higher than the value you set for this parameter triggers the logger to capture the details about the request and the events that made up the request.
Example 7-8 The requestTiming slowRequestThreshold property
<requestTiming slowRequestThreshold ="300ms" />
•hungRequestThreshold: The value that you can set for this parameter is the amount of time that a request can run before it is considered hung. You can specify an integer value followed by a unit of time, which can be hours (h), minutes (m), seconds (s), or milliseconds (ms). Combined units of time are allowed, for example 1m1s, which means 61 seconds. The default value is 10 minutes. If you need to disable hung request timing, set the value to 0. Example 7-9 shows an example of configuring this parameter for
1 minute. A request duration higher than the value you set for this parameter triggers a warning in the messages log and request details to be captured.
Example 7-9 The requestTiming hungRequestThreshold property
<requestTiming hungRequestThreshold ="1m" />
•sampleRate: This parameter is the sampling rate for the request timing only. The default value is 1. To sample all requests, you need to set the value to 1. To sample one out of 10 requests, you need to set the value to 10 as shown in Example 7-10.
Example 7-10 The requestTiming sampleRate property
<requestTiming sampleRate="10" />
•includeContextInfo: This property lets you decide whether or not to include context information in the log entries. The default value is true, but you can turn it off by setting the false value as in Example 7-11 on page 214. You can configure this property in the server.xml configuration file of the Liberty profile server.
Example 7-11 The requestTiming includeContextInfo property
< requestTiming includeContextInfo="false" />
7.7 Timed Operations feature
You have the option to detect operations in the application server that are running more slowly than expected by enabling the Timed Operations feature. This feature will log warnings about those operations and can use the information that is listed to decide if anything is running slower or faster than you expect.
To enable the Timed Operations feature, add the following element declaration inside the featureManager element in your server.xml file:
<feature>timedOperations-1.0</feature>
The following properties are available for configuring this feature:
•enableReport: This boolean property lets you choose whether or not to generate a report to the logs detailing the 10 longest timed operations, grouped by type, and sorted within each group by expected duration. The default value is true.
•maxNumberTimedOperations: A warning is logged when the total number of timed operations reaches the integer value of this property. The default value is 10000.
•reportFrequency: This property determines the frequency, in hours, of generating reports to the logs detailing the 10 longest timed operations, grouped by type, and sorted within each group by average of actual duration. You have to specify a positive integer followed by the unit of time (hours) as in Example 7-12. The default frequency value is 24 hours.
Example 7-12 Timed operations feature configuration
<timedOperations maxNumberTimedOperations="10" reportFrequency="1h"/>
 
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset