This requirement is for identifying root cause correctly and proactively for complex WebSphere issues.
We need automatic collection of performance measurements indicator data 24x7. This is similar to how we have sar report for Linux. We do not want to probe via JMX every now and then. Following are some of the requirements we could think for the same.
Automatic collection of performance measurements indicator data to be done every 1 minute interval, just like sar in Linux.
Automatic collection of performance measurements indicator data to be done and stored in a single file on per day basis, just like sar in Linux.
We want this per day performance measurements indicator data per day file that is written, to be in binary format or any other standard compressed mechanism so as to avoid occupying much of disk space. Please note that, we have constraint on free disk space for this purpose.
Maximum number of days of storage of these files can be 7days
Location of the performance measurements indicator data file which needs to be written to disk, to be made configurable.
There should not be any performance degradation owing to this collection of the performance measurements indicator data periodically into a file. At max. we can sustain this performance drop by 2% to 3%
There should be a Viewer for viewing this binary/compressed file.
Command line tool to view this binary/compressed file is an absolute need, and a Graphical Tool to view is a welcome addition.
Starting and stopping of the performance measurements indicator data collection to be possible via command line and, via Graphical is a welcome addition.
We also need inbuilt performance advisors by the WAS which if provided/available will be helpful to monitor certain performance issues and periodically report tuning recommendations. Tuning the WebSphere Application Server should be dependent on performance measurements indicator data collection which we configure, so as to provide optimal server performance by way of monitoring performance behaviours/characteristics to provide configuration recommendations to improve the application server performance.
Following are the list of broader PMI areas which we are interested in, to be monitored by default:
1. Enterprise bean counters
2. JDBC connection pool counters
3. J2C connection pool counters
4. Java virtual machine counters
5. Object Request Broker counters
6. Servlet session counters
7. Service integration bus counters
8. Transaction counters
9. Thread pool counters
10. Web application counters
11. System counters
12. Web services counters
13. Scheduler counters
14. Security authentication counters
15. Security authorization counters
16. Monitoring overall system health
Thank you for the suggestion. The requirement does have merit, but looking at it with respect to our total backlog of requests we do not see sufficient interest in this enhancement to merit delivery any time in the foreseeable future. Given the unlikelihood that we would deliver this, we are declining the request rather than leaving it in an uncommitted state for an extended period of time. If you would like to discuss this decision further, please contact Graham Charters <charters@uk.ibm.com>.
What is being requested here is the kind of analysis that monitoring tools tend to be used for and our focus has been better integration with those tools. For example using the Metrics servlet recently released to feed this data into Prometheus and using our Graphana dashboard to visualize the data there.