Network Deployment (Distributed operating systems), v8.0 > Reference > Administrator best practices
PMI data organization
Use this page as a general overview of monitoring, data collection, and counters using Performance Monitoring Infrastructure (PMI) and Tivoli Performance Viewer.
Performance Monitoring Infrastructure (PMI) provides server-side monitoring and a client-side API to retrieve performance data. PMI maintains statistical data within the entire WAS domain, including multiple nodes and servers. Each node can contain one or more WAS. Each server organizes PMI data into modules and submodules.
Tivoli Performance Viewer, formerly Resource Analyzer, organizes performance data in a centralized hierarchy of the following objects:
- Node. A node represents a physical machine in the WAS administrative domain.
- Server. A server is a functional unit that provides services to clients over a network. No performance data is collected for the server itself.
- Module.
A module represents one of the resource categories for which collected data is reported to the performance viewer. Each module has at least one configuration file in XML format. These files determine organization and lists a unique identifier for each performance data in the module. Modules include enterprise beans, JDBC connection pools, J2C connection pool, JVM run time (including Java Virtual Machine Tool Interface (JVMTI)), servlet session manager, thread pools, transaction manager, web applications, ORB, Workload Management (WLM), web services gateway (WSGW), and dynamic cache.
- Submodule. A submodule represents a fine granularity of a resource category under the module. For example, ORB thread pool is a submodule of the thread pool category. Submodules can contain other submodules.
- Counter. A counter is a data type used to hold performance information for analysis. Each resource category (module) has an associated set of counters. The data points within a module are queried and distinguished by the MBean ObjectNames or PerfDescriptors. Examples of counters include the number of active enterprise beans, the time spent responding to a servlet request and the number of kilobytes of available memory.
Tivoli Performance Viewer is a thin client integrated into the WAS administrative console. It provides a simple viewer for the performance data provided by Performance Monitoring Infrastructure (PMI), and allows users to view and manipulate the data for counters. A particular counter type can appear in several modules. For example, both the servlet and enterprise bean modules have a response time counter. In addition, a counter type can have multiple instances within a module. In the figure above, both the Enterprise beans module and Bean1 have an Avg Method RT counter.
Counters are enabled at the module level and can be enabled or disabled for elements within the module. For example, in the figure, if the enterprise beans module is enabled, its Avg Method RT counter is enabled by default. However, you can then disable the Avg Method RT counter even when the rest of the module counters are enabled. We can also, if desired, disable the Avg Method RT counter for Bean1, but the aggregate response time reported for the whole module no longer includes Bean1 data.
As part of a fine-grained control feature, WAS provides statistic sets which are pre-defined, fixed server-side sets, based on the PMI statistic usage scenarios. The PMI specification levels include: none, basic, extended, all, or custom. If you choose none, all PMI modules are disabled. Choosing basic provides the J2EE and the essential set of statistics to give you a basic level of monitoring. Selecting extended gives you the basic level of monitoring plus Work Load Monitor, Performance Advisor, and Tivoli resource models for a more robust monitoring set. Choosing all enables all statistics. Choosing custom gives you fine-grained control to enable or disable statistics individually.
There are only two states for a statistic: enabled or disabled.
To provide an option to enable synchronized updates, WAS, provides a configuration parameter, synchronizedUpdate, at the PMI service level. When this attribute is true, all the statistic updates are synchronized. By default, the synchronizedUpdate parameter is set to false. We can select the Use sequential counter updates check box in the administrative console to enable synchronized updates.
Data collection can affect performance of the application server. The impact depends on the number of counters enabled, the type of counters enabled and the monitoring level set for the counters.
The following PMI modules are available to provide statistical data:
We can access PMI data through the getStatsObject and the getStatsArray method in the PerfMBean. You need to pass the MBean ObjectName(s) to the PerfMBean.
Use the following MBean types to get PMI data in the related categories:
- DynaCache: dynamic cache PMI data
- EJBModule*: EJB module PMI data (BeanModule)
- EntityBean*: specific EJB PMI data (BeanModule)
- JDBCProvider*: JDBC connection pool PMI data
- J2CResourceAdapter*: Java 2 Connectivity (J2C) connection pool PMI data
- JVM: JVM PMI data
- MessageDrivenBean*: specific EJB PMI data (BeanModule)
- ORB: ORB PMI data
- Server: PMI data in the whole server, pass recursive=true to PerfMBean
- SessionManager*: HTTP Sessions PMI data
- StatefulSessionBean*: specific EJB PMI data (BeanModule)
- StatelessSessionBean*: specific EJB PMI data (BeanModule)
- SystemMetrics: system level PMI data
- ThreadPool*: thread pool PMI data
- TransactionService: JTA Transaction PMI data
- WebModule*: Web application PMI data
- Servlet*: servlet PMI data
- WLMAppServer: Workload Management PMI data
- WebServicesService: Web services PMI data
- WSGW*: Web services gateway PMI data
To use the AdminClient API to query the MBean ObjectName for each MBean type. We can either query all the MBeans and then match the MBean type or use the query String for the type only: String query = "WebSphere:type=mytype,node=mynode,server=myserver,*";
Set the mytype, mynode, and myserver values accordingly. You get a Set value when you call the AdminClient class to query MBean ObjectNames. This response means that you can get multiple ObjectNames.
In the previous example, the MBean types with a star (*) mean that there can be multiple ObjectNames in a server for the same MBean type. In this case, the ObjectNames can be identified by both type and name (but mbeanIdentifier is the real UID for MBeans). However, the MBean names are not predefined. They are decided at run time based on the applications and resources. When you get multiple ObjectNames, you can construct an array of ObjectNames that you are interested in. Then you can pass the ObjectNames to PerfMBean to get PMI data. You have the recursive and non-recursive options. The recursive option returns Stats and sub-stats objects in a tree structure while the non-recursive option returns a Stats object for that MBean only. More programming information can be found in Develop your own monitoring applications.
Related
Enterprise bean counters
JDBC connection pool counters
J2C connection pool counters
Java virtual machine counters
ORB counters
Servlet session counters
Transaction counters
Thread pool counters
Web application counters
Workload Management counters
System counters
Dynamic cache counters
MBean cache statistics
Web services counters
Alarm Manager counters
Object Pool counters
Scheduler counters
High availability manager counters
Distribution and consistency services (DCS) stack counters
PortletContainer PMI counters
Extension registry counters
Proxy counters
Service integration bus counters
SIP PMI counters
IBM Tivoli Composite Application Manager for WAS counters
Performance Monitoring Infrastructure (PMI)
Monitor overall system health
Enable PMI
Related
Web services gateway counters
Performance Monitoring Infrastructure settings
OSGi Applications PMI counters