bwcole

10.5.2 sp1 - Environment Performance Agent (epagent)

Blog Post created by bwcole on Sep 18, 2017

So it has been quite a few years since we implemented the epagent and with that, we used the out of the box EPACtrl.sh file as a base, but we added a few elements in order to have OS and custom configuration files.

 

We have a logic block that reads 'uname' and then if/then/else for AIX, SLES and RHEL.  Depending on the version the property file has a post-fix

   IntroscopeEPAgent.properties.aix

   IntroscopeEPAgent.properties.sles

   IntroscopeEPAgent.properties.rhel

 

The second logic structure is a custom properties file located in the /syshome/apmadmin/config directory.  If there is a IntroscopeEPAgent.properties file present there, use it and bypass the OS properties file.

 

Now with 10.5.2 there is the "Tanuki" wrapper.  It looks like a Java program managing the epagent.  The problem with this, is that the IntroscopeEPAgent.properties is within the <agent>/config/EPAgent.conf file.

wrapper.java.additional.1=-Dcom.wily.introscope.epagent.properties="../IntroscopeEPAgent.properties"

 

In this context there appears to be no way to add logic to the configuration file.  So here are a few thoughts on how to get around this.

 

Option 1:

Don't use the out of the box EPACtrl.sh script.  The agent is pretty simple at the core.  The EPAgent.jar and then the IntroscopeEPAgent.properties file are the base then any plugin JAR files.  The rest seems to be basic Java command line options for memory, heap, and if you use it, the

   -Dintroscope.agent.enterprisemanager.transport.tcp.host.DEFAULT=$CAAPM_MOM

 

Yes, this precludes any of the additional options of the Tanuki wrapper, but in our current script we have the child process stateful plugin management, and it's been working.

 

Option 2:

   Change the location of the IntroscopeEPAgent.properties file to the /syshome/apmadmin/config directory.  This would reduce the amount of selection logic.  Yes, this complicates the agent deploy a bit since with the host OS logic the properties files were located in the agent directory and all you had to do on a non-customized host is start the agent.  It was self contained.  With this option, every host would need to have a file deployed to it's home directory.

   This option, we would be modifying the <agent>/config/EPAgent.conf file to change the line

      wrapper.java.additional.1=-Dcom.wily.introscope.epagent.properties="../IntroscopeEPAgent.properties"

 

 

Option 3:

  We modify the EPACtrl.sh and the EPAgent.conf to contain the properties file selection.  We would need to know quite a bit more about the Tanuki wrapper to be able to effectively implement.

 

Option 4:

Make all of the plugins aware of the OS so they run only when on the right host.  Well we would need to alter a dozen or so Perl Scripts and then we are having to maintain each of those scripts when an OS change happens that messes with our OS selection logic or we need to add another OS.  So basically spread the logic across all the plugins or handle which plugins to run on the OS at the agent start up?  Hummm...contain the complexity in lowest number of source files, is the argument against this option.

 

 

So, which option?  Well, what does the Tanuki wrapper give us that we don't already have with our own EPACtrl.sh script?  Over the last seven years, we really have had very little trouble with the epagent.  We have about a dozen or so Perl plugins.  We also have three different platforms which are configured with a different set of plugins. 

 

I'm really thinking that option 1 is the way we will go.  It provides us the flexibility we already have and looking at the wrapper script, that it appears to be far more complex and really don't offer much in terms of benefits.  So, we would change out the epagent.jar.

Outcomes