What's Clobbering My Essbase Log?

Every now and then I need to educate a customer on how OPMN works.  Well, here's some knowledge I'm giving away for free.  (3 CEOs ago hated when I did this)

Here's the symptom of what's causing your on-premises Hyperion / Oracle EPM Essbase.log to keep growing 24x7, even when no end-users are logged in and no MaxL automation is running:

What's going on here?  Nobody is logged in but the log keeps getting updated once every 20 seconds or so.

This, dear reader, is OPMN.

Oracle Process Management Notification Service.

OPMN is responsible for managing active-passive Essbase clustering.  These "hits" you're seeing in the log is OPMN pinging Essbase to see if it is alive.

"But wait a moment, Dave!  I have just one Essbase server per environment and am definitely not doing Active-Passive Essbase clustering!!!  How do I turn these pings off???"

I'm glad you asked.  Let's investigate the OPMN config file, located here by default:

Make a backup copy of opmn.xml if you've never performed this exercise before!  OPMN is very particular about the XML file, and Essbase will fail to boot up if you commit a typo error in this file.

Now click Search->Find in your favorite text editor (cough cough Notepad++ cough cough) for the word "death".  It is present in the opmn.xml file exactly once:

I have comments to offer on the restart-on-death setting.  We'll get to that in a moment.  But for now, you want to insert a new line immediately after <restart retry="2" timeout="600"/>

Paste exactly this:

<ping timeout="20" interval="0"/>

Bounce the Essbase service (Windows) or use your stopEssbase.sh / startEssbase.sh scripts in Linux.  Done.  Your modified file should look like this:

The line you pasted disables the 20-second ping.  Obviously, if you ARE indeed running Essbase in an Active-Passive cluster configuration, then you need to IGNORE my advice in this case.  That 20-second ping is what allows OPMN to fail over Essbase to the Passive node, if your environment is correctly setup.

Now let's briefly touch upon the restart-on-death setting.

The setting defaults to "true", which I tend not to like.  Why?  Because I prefer to use MaxL to gracefully shutdown the Essbase Agent rather than stopping the service or running stopEssbase.sh.  Stopping the service brings down Essbase unconditionally. An ESSSVR process that's active - whether it is loading data, running a calc script, or restructuring - is now orphaned and cannot be restarted until the PID is killed.

How I bring down Essbase gracefully and send an alert to the system admins when it doesn't come down gracefully.... well, if you must know you may buy me off with a case of Guinness.

Happy Essbase'ing!