The Open-Xchange JMX offers the ability to fetch runtime information of the Java virtual machine, and about the Open-Xchange Groupware backend. This article will give you information about the most common items from a monitoring perspective, and possible alarm trigger values.
The following items seem to be the most important ones for monitoring the application. Of course there are several others available as well, and those might also be used if you require additional information about the runtime. Please use the common interfaces to fetch these information from the application (JMX, showruntimestats).
Total number of active Open-Xchange sessions on this virtual machine. Depending on the session timeout sessions will be removed after it has timed out, or if they have been killed by the client (clicks Logout), meaning: Not all of those sessions might be active, some of them are just pending. Monitor breakouts to determine if you have enough memory available (1MB per OX session is at least required per VM)
Maximum number of file handles that can be taken by the Java virtual machine.
Number of all file handles taken by the Java virtual machine currently. This includes all created sockets and virtual machine resources, too. Example notification value: (MaxFileDescriptorCount - OpenFileDescriptorCount) < 100. Monitor to determine if the number of open files that can be opened by the vm is sufficient.
Total number of currently open database connections. This includes database connections to all database machines in the cluster (ConfigDB, User-DB). Example notification value: The number of database connections raises to the number of Grizzly sockets or even beyond that. This means that the response of the database is to slow and needs to be monitored.
Total number of currently opened connections to the mail servers. This are connections using the IMAP protocol. Monitor breakouts to determine if the IMAP servers are able to handle the number of requests.
Number of total threads running inside the Java virtual machine. This includes the number of threads from the thread pool mentioned next. Some components of Open-Xchange and the Java virtual machine create their threads on their own without using the thread pool.
Number of threads created from the internal thread pool. The thread pool efficiently deals with creating and destroying threads and keeps the fork rate as low as possible. All essential components in Open-Xchange create their threads using this thread pool.
Total number of tasks to be executed submitted to the thread pool. The graph should show he difference between the current value and the last value. Example notification value: The number of newly submitted tasks raises extraordinary.
The total number of tasks executed by the thread pool. The graph should show the difference between the current value and the last value.
Every increase of one of this numbers is an indicator that fetching data from one of the backend systems did not work as expected.
Number of IMAP connections that got into a timeout.
Number of IMAP login attempts that failed.
Number of IMAP data fetches that failed somehow.
Number of connections to the config database slave that encountered a problem.
Number of connections to the config database master that encountered a problem.
Number of connections to the user database master that encountered a problem. Get the identifier of this database server from the listdatabase command.
Number of connections to the user database slave that encountered a problem. Get the identifier of this database server from the listdatabase command.
Get the identifier of this database server from the listdatabase command.
Current number of used connections to this database. These connections sent a SQL command to the database server or data from the database is read.
Current number of established but not used connections to this database.
Number of threads waiting for a database connection if the maximum configured number of database connections is already opened. As early as threads need to wait for database connections the performance will degrade extraordinary.
Sum of active and idle connections to the database.
Average time a thread occupies a database connection to fetch some data. This average is calculated from the last 1000 use times. A raise in the average use time indicates that the database servers are becoming slower and overall performance may degrade.
Number of fetches of connections to the master database. Compared to the number of fetches of connections to the slave database this indicates the ratio of writes to reads on the database.
Number of fetches of connections to the slave database. Every time data needs to be read a connection to the slave is fetched.
Open-Xchange monitors the replication from master to slave for every context/tenant. If data is just written to the master and it is detected that the slave does not have this information yet, a connection to the master is used instead a connection to the slave to read most actual data. If you encounter a raise in this number it is an indicator that the replication on the database servers becomes more slow. A drawback of that is that the master server faces more load.
In total those three memory spaces reflect the total usage of non application memory usage for the Java virtual machine. Eden is used for new objects with the youngest lifetime, Survivor for older objects, and Old Gen for the oldest objects. In total this gives you the information how much memory is used for all your sessions. Divided through the number of sessions it gives you the indication of how much memory is used per session.