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.
- Diagnostic Provider MBeans are Java™ Management Extensions (JMX) MBeans
- Diagnostic Provider MBeans all implement a DiagnosticProvider interface which includes methods for configuration dumps, state dumps, and self diagnostic tests
- Diagnostic Provider MBeans provide a way to expose information about running components so administrators can more easily debug problems related to those components. As with other MBeans running in WebSphere Application Server, they can be accessed from JMX client code, or through the wsadmin tool.
- 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, the wsadmin tool can be used directly with the Diagnostic Service MBean to get formatted results
- The Diagnostic Provider utility
- a set of panels included in the WebSphere Application Server 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.
- A log entry indicates that a particular component is experiencing a problem.
- The system administrator sees the log entry through the runtime messages panel.
- The system administrator cannot tell what is wrong, so calls IBM® support for assistance, with a potentially ill-defined problem.
- A log entry that contains a Diagnostic Provider ID (DPID) indicates that something has gone wrong in a specific component.
- The system administrator sees the log entry through the runtime messages panel.
- 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.
- From the self test, the administrator is warned that the component is configured in a way that could lead to poor performance or failures.
- A log entry which doesn’t contain a DPID indicates that something has gone wrong in a component.
- The system administrator sees the log entry through the runtime messages panel.
- The system administrator uses the administrative console to navigate through the available set of Diagnostic Providers and selects one that sounds appropriate.
- He runs a configuration dump, a state dump, or a self diagnostic test against the Diagnostic Provider to collect information about the component.
- From the state dump, the administrator is able to notice that the component state is not what would be expected for its workload.
- 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).