Diagnostic Provider configuration dumps, state dumps, and self tests
The Diagnostic Provider (DP) infrastructure allows for a software component or stack product in the WebSphere Application Server space to expose key information about its configuration, current state, and current ability to perform operations.
The methods that expose this information might be driven as a result of a message put out by the component (by a logger which automatically includes the Diagnostic Provider ID in each message), or might be driven as a result of an overall system health-check when an administrator or automated tool is monitoring the system.
Configuration dumps
A Configuration dump is an operation we can perform on a Diagnostic Provider to list the startup or current values of the configuration attributes for the DP. The name for each data item in this dump should reflect its disposition. That is, each item should be called startup-xxx or current-xxx to show whether this is a startup or current value. The collection of attributes returned from this operation can be thought of as the payload of the configuration dump. More information about payloads can be found in Diagnostic Provider method implementation.
We can find several ways to filter the output of a configuration dump in Diagnostic Provider registered attributes and registered tests.
State dumps
A State dump is similar to a configuration dump, but it differs in two key areas. First, a state dump displays current information about the operation of a component. An example is a connection pool. A configuration dump can show DataSource name, the minConnections (configured or current), the maxConnections, the DataBase name, and so on. A state dump is more likely to show the current connections in use, the high concurrent use count, the number of times the pool has been expanded, the average time between requesting a connection and returning it, and so forth.
State dumps can be impacted by the values in the State Collection Specification. This is a dynamic specification that controls additional data collection the component can do at runtime. If additional data is being collected, then a State dump might display more information. The same filters and payload information that apply to Configuration dumps (see Diagnostic Provider registered attributes and registered tests) apply to State dumps.
Self Diagnostic tests
Self diagnostic tests are non-invasive operations that a Diagnostic Provider exposes. Non-invasive means that if they modify anything for the test, the conclusion of the test reverses the modification. These tests give an administrator the option to test simple functions of a component to see if it is able to perform them.
The filters for a self diagnostic test apply to the test itself, not to the output of the test. A typical use of Self Diagnostic tests could be for a pool manager of some sort to pull an object out of the pool and return it to the pool to verify that this operation can still be performed, and with acceptable performance.
Related concepts:
Diagnostic Provider registered attributes and registered tests
Diagnostic Provider method implementation
Related
View the run time configuration of a component using Diagnostic Providers
View the run time state data or configuring the state data collection specifications for a Diagnostic Provider
Run a self diagnostic on a Diagnostic Provider