<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'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'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'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'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: "I'd like the object X to have method Y which returns Z objects" 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"><<a href="mailto:andrew.yim@truvenhealth.com" target="_blank">andrew.yim@truvenhealth.com</a>></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'll definitely look into utilizing this feature as we're headed towards using JMX as a monitoring tool for all our applications.<br>
<br>
However, you have a question below that we're definitely interested in, specifically "What MDX query generated what SQL queries?". 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 & 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 "getSqlStatements()", 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've recently committed support for accessing Mondrian'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'll be interested to see whether having easier access to this information increases usage of the monitoring stats. Putting on an administrator'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'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 "hung" queries (i.e. running for longer than N)?<br>
3) What'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'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>