WAS v8.5 > Troubleshoot > Work with Diagnostic Providers

Diagnostic Providers

Diagnostic Providers are a quick method for viewing configuration and the current state of individual components within an application server environment.

WebSphere Application Server components can be considered as being divisible into diagnostic domains. A diagnostic domain refers to a set of classes within the component that share a set of diagnostics. Some larger components might have multiple diagnostic domains. For example, the Connection Manager logically consists of multiple data sources and connection factories that each have separate diagnostic domains.

A single diagnostic domain receives its diagnostic services from a Diagnostic Provider MBean. The Diagnostic Provider MBean enables you to query the startup configuration, current configuration, and current state of the diagnostic domain. In addition, Diagnostic Provider MBeans can also provide access to any self diagnostic tests available from the diagnostic domain. Some characteristics of Diagnostic Provider MBeans include:

Diagnostic Provider MBeans are efficient at delivering Java object representations of configuration, state, and self test information. This is good for when programs interact. For human users to access the information, WAS provides a set of facilities to extend the value of Diagnostic Provider MBeans.

The Diagnostic Service MBean

provides methods to convert Diagnostic Provider MBean output into human readable formats. The Diagnostic Service MBean also provides some methods to facilitate looking up the Diagnostic Provider MBeans on the same server as the Diagnostic Service MBean. For administrators that want to access diagnostic data from a command line, wsadmin can be used directly with the Diagnostic Service MBean to get formatted results

The Diagnostic Provider utility

a set of panels included in the WAS administration console through which administrators can interact with Diagnostic Provider MBeans. The Diagnostic Provider utility is a simple front end in the administration console that presents the available set of Diagnostic Provider MBeans present on each managed server, and provides a means to execute and view the results of configuration dumps, state dumps, and diagnostic self tests.
.


The purpose of Diagnostic Providers

Diagnostic Providers give you more information for quickly discovering and diagnosing system problems. The following scenario contrasts the experience of an administrator working with a component that does not have a Diagnostic Provider to one that does.

When the administrator works with a component that is without a Diagnostic Provider, the events are as follows:

  1. A log entry indicates that a particular component is experiencing a problem.
  2. The system administrator sees the log entry through the runtime messages panel.
  3. The system administrator cannot tell what is wrong, so calls IBM support for assistance, with a potentially ill-defined problem.

When the administrator works with a component with a Diagnostic Provider, and the Diagnostic Provider ID is registered with the component's logger, the situation changes as follows:

  1. A log entry containing a Diagnostic Provider ID (DPID) indicates that something has gone wrong in a specific component.
  2. The system administrator sees the log entry through the runtime messages panel.
  3. The administrator clicks a button on the runtime message panel to execute a state dump or a configuration dump, or to be taken to the list of component self tests.

  4. From the self test, the administrator is warned the component is configured in a way that could lead to poor performance or failures.

Furthermore, when the administrator works with a component with a Diagnostic Provider, and the Diagnostic Provider ID is not registered with the component's logger, the situation might unfold like this:

  1. A log entry which doesn’t contain a DPID indicates that something has gone wrong in a component.
  2. The system administrator sees the log entry through the runtime messages panel.
  3. The system administrator uses the dmgr console to navigate through the available set of Diagnostic Providers and selects one that sounds appropriate.
  4. He runs a configuration dump, a state dump, or a self diagnostic test against the Diagnostic Provider to collect information about the component.

  5. From the state dump, the administrator is able to notice the component state is not what would be expected for its workload.
  6. The administrator works with the test team to determine which of the flows is causing the state of the component to diverge from what is expected (as evidenced by repeated execution of the state dump).


Subtopics

  1. Diagnostic Provider IDs
  2. Diagnostic Provider configuration dumps, state dumps, and self tests
  3. Diagnostic Provider registered attributes and registered tests
  4. Diagnostic Provider names
  5. The simpler interfaces provided by the Diagnostic Service MBean
  6. Diagnostic Provider IDs
  7. Diagnostic Provider configuration dumps, state dumps, and self tests
  8. Diagnostic Provider registered attributes and registered tests
  9. Diagnostic Provider names
  10. The simpler interfaces provided by the Diagnostic Service MBean


Related

Work with Diagnostic Providers
wsadmin scripting tool


+

Search Tips   |   Advanced Search