• Check out the jmxterm repository
• Download jmxterm from https://docs.cyclopsgroup.org/jmxterm

See also docs.

To help future Googlers… with the Confluent docker images for Kafka, KSQL, Kafka Connect, etc, if you want to access JMX metrics from within, you just need to pass two environment variables: <x>_JMX_HOSTNAME and <x>_JMX_PORT, prefixed by a component name.

• <x>_JMX_HOSTNAME - the hostname/IP of the JMX host machine, as accessible from the JMX Client.

  This is used by the JMX client to connect back into JMX, so must be accessible from the host machine running the JMX client.

It struck me today when I was writing my most recent blog over at Rittman Mead that I’ve been playing with visualising OBIEE metrics for years now.

• Back in 2009 I wrote about using something called JManage to pull metrics out of OBIEE 10g via JMX:

  

• Still with OBIEE 10g in 2011, I was using rrdtool and some horrible-looking tcl hacking to get the metrics out through jmx :

  

• 2014 brought with it DMS and my first forays with Graphite for storing & visualising data:

Over the last few months I’ve been doing a lot of exploring of OBIEE Systems Management data, covered in a mini-series of blog posts, Collecting OBIEE systems management data.

There are a vast number of counters exposed, ranging from the very interesting (Active Sessions, Cache Hits, etc) to the less so (Total Query Piggybacks, although for some seriously hardcore performance tuning even this may be of interest).

This short blog post is about a couple of counters which I’ve been monitoring but which looks to not be entirely reliable. Both are in the Oracle BI DB Connection Pool, and are:

I’ve added two new toys to my geek arsenal today. First is one with which I’ve dabbled before, but struggled to master. The second is a revelation to me and which I discovered courtesy of twitter.

rrdtool

rrdtool is a data collection and graphing tool which I’ve been aware of for a while. I wanted to use it when I wrote about Collecting OBIEE systems management data with JMX, but couldn’t get it to work. I’ll not lie to you - it is a bitch to work with at first. Or put a more polite way, it has a steep learning curve. But when you reach the top of the curve and realise its potential…wow. You’ll soon understand why it is so widely used. I plan to write this up soon, but it let me draw nice graphs like this:

Introduction

This is the third part of three detailed articles making up a mini-series about OBIEE monitoring. It demonstrates how to capture OBIEE performance information, and optionally graph it out and serve it through an auto-updating webpage.

This final article describes how to bolt on to OAS a simple web page hosting the graphs that you created in part 2, plotting data from OBIEE collected in part 1.

The webpage

This is just an old-school basic HTML page, with a meta-refresh tag (which note that Chrome doesn’t work with) and img tags:

Introduction

This is the second part of three detailed articles making up a mini-series about OBIEE monitoring. It demonstrates how to capture OBIEE performance information, and optionally graph it out and serve it through an auto-updating webpage.

This article takes data that part one showed you how to collect into a tab-separated file that looks something like this:

[sourcecode] 2010-11-29-14:48:18 1 0 11 0 3 2 1 676 340 0 53 1 0 41 0 3 0 2010-11-29-14:49:18 1 0 11 0 3 2 1 676 0 0 0 1 0 0 0 3 0 2010-11-29-14:50:18 2 0 16 1 4 3 1 679 0 0 0 1 0 0 0 4 0 2010-11-29-14:51:18 2 2 19 1 4 3 1 679 32 0 53 1 0 58 0 4 0 2010-11-29-14:52:18 2 1 19 1 4 3 4 682 0 0 0 1 0 0 0 4 0 2010-11-29-14:53:18 2 1 19 1 4 3 4 682 0 0 0 1 0 0 0 4 0 2010-11-29-14:54:18 2 0 19 1 4 3 1 682 0 0 0 1 0 0 0 4 0 [/sourcecode]

Introduction

This is the first part of three detailed articles making up a mini-series about OBIEE monitoring. It demonstrates how to capture OBIEE performance information, and optionally graph it out and serve it through an auto-updating webpage.

For some background on OBIEE’s Systems Management component, along with JMX and MBeans, see here and here. The following assumes you know your mbeans from coffee beans and jmx from a bmx.

The metric collection is built around the jmxsh tool. This is similar to jmxterm and both provide command-line access to jmx. Once it’s commandline, it’s scriptable :)

Those of you who read my blog regularly may have noticed I have a slight obsession with the OBIEE systems management capability which is exposed through JMX. Venkat has blogged this week about JMX in OBI11g, and it’s clearly a technology worth understanding properly. I’ve recently been tinkering with how to make use of it for monitoring purposes, most recently using JConsole and discussed here. What follows is an extension of this idea, cobbled together with a bit of shell scripting, awk, gnuplot, and sticky backed plastic. It’s built on OBIEE 10g - for OBI11g it may differ (although I understand that Performance MBeans still exist).

Folk from Yorkshire are tight, so the stereotype goes. So here’s a cheap-ass way to monitor OBIEE 10g using nothing but the OBIEE built-in systemsmanagement component, the jmx agent, and jconsole (which is part of the standard Java distribution):

From here you can also export to CSV the various counters, and then store history, plot it out with gnuplot or Excel, etc.

If anyone’s interested let me know and I’ll document a bit more about how I did this, but it’s basically building on previous work I’ve documented around jmx and OBIEE.

JMX

OBIEE’s Systems Management functionality exposes performance counters and the application’s configuration options through Java MBeans and optionally a protocol called JMX.

It’s extremely useful, and is documented pretty widely :

• JConsole / JMX
• JConsole / JMX – followup
• Oracle BI Management / Systems Management MBeans
• PerfMon
• OBIEE MBeans and OC4J
• OBIEE performance monitoring and alerting with jManage

In this article I’m going to discuss the use of JMX to access these counters remotely, and a possible security issue that’s present in the BI Management Pack manual. The BI Management Pack is an add-on to Oracle’s Enterprise Manager / Grid Control for managing OBIEE, see Mark Rittman’s excellent guide on Oracle’s website.

OBIEE’s Systems Management component exposes configuration and performance data through Java MBeans. As discussed in other posts these can be be accessed through several different ways:

• JConsole (see also here)
• oc4j
• Windows PerfMon (although I guess this isn’t actually using MBeans/JMX?)
• saw.dll?perfmon
• BI Management Pack

Since it’s a standard java technology being used we can in theory use anything that is designed for monitoring mbeans via jmx. Doing some Googling I discovered jManage.

Part of looking at the various gubbins inside OBIEE led me to realise that the Oracle BI Management application drives quite a few things. It exposes MBeans (Management Beans, a java term), accessible through jmx. In the installation of OBIEE this component is referred to as “Systems Management”.

The MBeans give us real-time performance information, along with access to all the configuration options that are normally done through config files (instanceconfig.xml etc). Bear in mind if using it for updating configuration instead of through the files you don’t get any backup created, so for that reason alone I would suggest it should only be used for reading current values.

A few points to add to my previous posting on JConsole:

• As well as performance data, you have access to configuration data. Be aware that it is read-write! So whilst it might be a nice alternative to digging around for your instanceconfig.xml etc, you should be careful
• If you have your BI Server and Presentation Services deployed on separate servers then you will only get MBeans for the relevant service:

[edit] See this post too [/edit] On an OBIEE server run [sourcecode language=“bash”] nohup obiee/systemsmanagement/runagent.sh & [/sourcecode] and then run jconsole (make sure you’ve set the DISPLAY first if you’re running it from UNIX). NB: if you don’t have jconsole in your path you can search for it: [sourcecode language=“bash”] $whereis jconsole jconsole: /opt/java1.5/bin/jconsole /opt/java6/bin/jconsole</span> [/sourcecode] You should find it under your java/bin directory

You should get this kind of connection dialog: Click connect, and the console will launch. From here click on the MBeans tab, where you’ve got access to performance and configuration data