<div dir="ltr">Hello Andrew,<div><br></div><div>You are right about our motivation for not keeping the history of SQL statements that are executed. We never wanted to create a historic repository of the metrics, but rather wanted to have a means to take snapshots of the current state without adding an additional burden on the runtime code. At least, that&#39;s what the current implementation of the monitor does. </div>

<div><br></div><div>We had assumed that users would like to get the data out of there anyways, and post-process and aggregate it in some other platform that&#39;s specialized for this. (In our internal testing, we used Splunk)</div>

<div><br></div><div>Another way to implement the monitoring could be sending messages to a message queue somewhere. That&#39;d also be feasible.</div><div class="gmail_extra"><br></div><div class="gmail_extra">About tying SQL to MDX queries. After reviewing our code, I think that your requirement isn&#39;t currently covered by the way that we have structured the *Info objects. Please create a jira ticket for the feature and add as much details as you can. Things like: &quot;I&#39;d like the object X to have method Y which returns Z objects&quot; are what we need to know about.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">Luc</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 29, 2014 at 12:26 PM, Yim, Andrew <span dir="ltr">&lt;<a href="mailto:andrew.yim@truvenhealth.com" target="_blank">andrew.yim@truvenhealth.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Matt,<br>
<br>
This is great and we&#39;ll definitely look into utilizing this feature as we&#39;re headed towards using JMX as a monitoring tool for all our applications.<br>
<br>
However, you have a question below that we&#39;re definitely interested in, specifically &quot;What MDX query generated what SQL queries?&quot;.  We attempted to do this by hooking Mondrian with SLF4j/Logback and setting the MDC parameter with each request.  We were hoping when we logged MDX and SQL queries we could capture the MDC parameter we set (which is thread-safe), but since the MDX &amp; SQL is executed in a separate thread pool this is not working as we expected.<br>


<br>
There are a few methods that we also tried using programmatically in the MondrianServer monitor, specifically &quot;getSqlStatements()&quot;, but whenever we called this the Map was already cleared.  It seems after each SQL query executes, it immediately clears itself from the Map.  I assume that this is done on purpose to manage memory consumption.<br>


<br>
If there could be a vote for getting this type of enhancement added to the monitor sooner, we would definitely be in favor!<br>
<br>
Have you heard of any implementation ideas on this or if something is in the works?<br>
<br>
<br>
<br>
Andrew Yim   |   Truven Health Analytics   |   O: <a href="tel:734.913.3174" value="+17349133174">734.913.3174</a>   |    M: <a href="tel:734.347.8669" value="+17343478669">734.347.8669</a><br>
<div class="HOEnZb"><div class="h5"><br>
<br>
-----Original Message-----<br>
From: <a href="mailto:mondrian-bounces@pentaho.org">mondrian-bounces@pentaho.org</a> [mailto:<a href="mailto:mondrian-bounces@pentaho.org">mondrian-bounces@pentaho.org</a>] On Behalf Of Matt Campbell<br>
Sent: Tuesday, April 15, 2014 5:06 PM<br>
To: <a href="mailto:mondrian@pentaho.org">mondrian@pentaho.org</a><br>
Subject: [Mondrian] Mondrian system metrics via JMX<br>
<br>
<br>
I&#39;ve recently committed support for accessing Mondrian&#39;s monitor via JMX in both lagunitas and master branch.  Details of how to setup connections and what metrics are available are at <a href="http://wiki.pentaho.com/display/analysis/Monitoring+Mondrian+System+Metrics+with+Java+Management+Extensions+%28JMX%29" target="_blank">http://wiki.pentaho.com/display/analysis/Monitoring+Mondrian+System+Metrics+with+Java+Management+Extensions+%28JMX%29</a>.<br>


<br>
There have been minor renames of some methods in the various *Info classes for consistency with JMX expectations.  For example, ServerInfo.cellCacheMissCount() has become .getCellCacheMissCount().  So if you were formerly accessing this information programmatically, you may need to update these references.<br>


<br>
I&#39;ll be interested to see whether having easier access to this information increases usage of the monitoring stats.  Putting on an administrator&#39;s hat, I think there is a fair amount of information that seems interesting and valuable:  cache hit/miss counts, sql counts, # statements currently executing.  There are also a lot of questions an administrator might ask that cannot be answered yet:<br>


<br>
1)  How many MDX queries have failed?  How many have been cancelled?  That&#39;s the sort of information that would be great to tie to an alerting threshold in a tool like Nagios.<br>
2)  Are there any &quot;hung&quot; queries (i.e. running for longer than N)?<br>
3)  What&#39;s the breakdown of time spent executing SQL versus Mondrian execution time?<br>
4)  What MDX query generated what SQL queries?<br>
5)  What is the aggregate time spent in statement execution?<br>
<br>
I can also imagine an admin would want the ability to reset running totals via JMX.<br>
<br>
I&#39;d love to see more use cases identified and entered as Jira tickets.<br>
_______________________________________________<br>
Mondrian mailing list<br>
<a href="mailto:Mondrian@pentaho.org">Mondrian@pentaho.org</a><br>
<a href="http://lists.pentaho.org/mailman/listinfo/mondrian" target="_blank">http://lists.pentaho.org/mailman/listinfo/mondrian</a><br>
_______________________________________________<br>
Mondrian mailing list<br>
<a href="mailto:Mondrian@pentaho.org">Mondrian@pentaho.org</a><br>
<a href="http://lists.pentaho.org/mailman/listinfo/mondrian" target="_blank">http://lists.pentaho.org/mailman/listinfo/mondrian</a><br>
</div></div></blockquote></div><br></div></div>