Otherwise for that you will need to use a log watching script or login to the CLI to see the processlist or analyze the slow logs. For specific query analysis I recommend you check out the Maatkit suite of scripts.

As Kontrollbase was designed for monitoring and automating the administration of hundreds to thousands of production servers it has not included the features you have listed because that is lower level data that is typically analyzed on a per-server basis if there are issues to troubleshoot; particularly the slow query and general query logs – I have those turned off those logs on most of my production servers because all development and query timing analysis is done in staging during load simulations pre-production as well as using production binary logs to replay incidents that cause alerts on the production server. If there are no staging server(s) available for this I consider it an infrastructure design flaw since all code should be tested on similar hardware with similar resources as the production server(s) before sending out code and queries into the wild. To maximize the speed of server response times and I/O performance it is my firm belief that the slow and general logs should be turned off in production unless specific troubleshooting and issue replay is needed.

In addition, from an application design standpoint – collecting all of the slow and general log traffic on a $n variable timing by kontrollbase and storing that in the centralized kontrollbase database for viewing on the webapp would instantly make most kontrollbase servers that monitor busy servers either grow massively very quickly or require constant data pruning, as well as increase network traffic across the board to get that slow/general log data moved from servers to kontrollbase. So you can see from a design standpoint why this feature is not included. It also does not record each client server’s connection user/host/pid/etc (show full processlist;) because it’s simply unnecessary to collect and store that data for overview and performance reporting. Of course we do collect the quantity of connections but do not record the specifics of each connection because at $n variable data collection timing there could be connections that have connected and run queries and disconnected in-between the collection timing, so you could potentially not get all of the data your were looking for in that case.

Think of kontrollbase as an analytics and analysis tool for performance metrics and historical data usage charting. It generates reports that recommend optimal settings for your servers. Those recommendations still require a DBA to understand and evaluate the recommendations based on his/her knowledge of the particular site(s) accessing the database server that is being addressed by the reports.

To understand more about the data collection and storage process of Kontrollbase please refer to this flowchart: http://kontrollsoft.com/kontrollbase/userguide/images/flowchart_webapp-serverloop-process.gif