Monitoring Mondrian System Metrics with Java Management Extensions (JMX)

Starting with Mondrian 3.7, you can monitor system metrics by using JMX. This allows accessing real time information about the queries currently being executed on the server. Aggregate metrics like cellCacheHitCount and sqlStatementExecuteNanos are also exposed for the server. See the table below for the complete list of metrics with their descriptions.

JMX Configuration

In order to access Mondrian metrics from a JMX client, you'll need to first configure the JVM process running biserver. For example, to set up unsecured remote JMX access on port 7199, add the following JVM parameters to the CATALINA_OPTS variable in start-pentaho.sh:

-Dcom.sun.management.jmxremote.port=7199
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false

After restarting biserver, you should be able to connect using a JMX client (e.g. JConsole, Nagios, Splunk) with the connection string service:jmx:rmi:///jndi/rmi://servername:7199/jmxrmi.

See http://docs.oracle.com/javase/7/docs/technotes/guides/management/agent.html for more information on JMX configuration.

The screenshot below shows the MXBeans that are available. Note that there are two separate namespaces for Mondrian metrics: mondrian.server and mondrian4.server. Separate namespaces allows metrics to be collected when both Mondrian 3.7 and 4.0 are running within the same container. If more than one instance of the same version of Mondrian is running within a container, each will be given a unique id (e.g. Server-1, Server-2, etc.).

Metrics

The following table lists the metrics available, along with a brief description. Within the "Server" attribute these metrics are aggregated across the whole server. Similarly, each Connection, Statement and SqlStatement object within their respective arrays have metrics aggregated at the appropriate level. For example, querying the sqlStatementExecuteCount value of a Statement object will retrieve the total time spent in SQL execution for that single MDX statement. Note that each of these attributes reflect the current state of the system. Statements and Connections will be removed from the monitor on completion, but their aggregate statistics will be persisted.

Name	Description
cellCacheHitCount	The count of cache hits.
cellCacheMissCount	The count of cache misses.
cellCachePendingCount	A count of requests for cells that are in the process of being loaded into the cache but are not yet ready
cellCacheRequestCount	The total number of requests made for cells from the cache.
cellCount	The number of cells currently in cache.
cellCoordinateCount	The sum of the dimensionality of every cells currently in cache. For example, each cell in the segment (State={CA, TX} * Year={2011}) has two coordinates. From this, we can compute the average dimensionality of segments in cache, weighted by the number of cells. It gives an idea of the memory overhead for segment axes.
connectionCurrentlyOpenCount	The number of connections currently open. Should equal (connectionStartCount - connectionEndCount)
connectionEndCount	The number of completed connections.
connectionStartCount	The number of started connections.
executeEndCount	A count of MDX statements that have finished execution.
executeStartCount	A count of MDX statements that have started execution.
segmentCount	The number of segments currently in cache.
segmentCreateCount	The number of segments currently in cache. This should be equal to (segmentCreateViaExternalCount+segmentCreateViaRollupCount+ segmentCreateViaSqlCount)
segmentCreateViaExternalCount	The number of segments placed into the cache by an external cache. For example, if a segment is resolved on a peer node in a cluster and propogated to this node.
segmentCreateViaRollupCount	The number of segments created by rolling up already loaded segments. For example, if the [Unit Sales] value for each of the children [Product].[Drink] is present in 2 or more separate segments, Mondrian may be able to roll up the values to avoid an unnecessary SQL query.
segmentCreateViaSqlCount	The number of segments created by issuing SQL.
segmentDeleteViaExternalCount	The number of segments deleted from an external cache.
sqlStatementCellRequestCount	Total, over all SQL statements that are fetching cells into cache, of the number of requested cells that will be satisfied by those SQL statements. Note that a given SQL statement may round out the predicates and bring back a few more cells than it was asked for.
sqlStatementCurrentlyOpenCount	number of SQL statements currently executing. (sqlStatementStartCount - sqlStatementEndCount)
sqlStatementEndCount	number of SQL statements finished execution. Incremented when the sql statement is closed.
sqlStatementExecuteCount	The total number of SQL statements that have execution. Incremented after the SQL query has executed.
sqlStatementExecuteNanos	The total nanoseconds elapsed during SQL execution.
sqlStatementRowFetchCount	Total number of rows fetched.
sqlStatementStartCount	The total number of SQL statements started. Incremented immediately before execution.
statementCurrentlyExecutingCount	The number of statements currently executing. In some cases (e.g. when using a PreparedOlapStatement) it's possible to execute the same statement more than once.
statementCurrentlyOpenCount	The number of statements currently open. A statement may have been opened but not yet begun execution. This value should equal (statementStartCount - statementEndCount)
statementEndCount	The total number of completed statements.
statementStartCount	The total number of statements started. This number is incremented when the statement is opened, before execution begins.