About log collection: the upstream plugin uses self.files (which points to the logs). In the RHEL6 branch this class attribute is overriden by an instance [empty] deque attribute in PluginBase's init.

This should fix it for RHEL6:

diff --git a/sos/plugins/activemq.py b/sos/plugins/activemq.py
index f3bb63f..1c2c850 100644
--- a/sos/plugins/activemq.py
+++ b/sos/plugins/activemq.py
@@ -23,5 +23,5 @@ class activemq(sos.plugintools.PluginBase):
     files = ('/var/log/activemq',)
 
     def setup(self):
-        self.addCopySpecs(list(self.files))
+        self.addCopySpec('/var/log/activemq')
 

About configuration files: the upstream plugin is not collecting them. Submitted https://github.com/sosreport/sos/pull/457

Can we get a more restrictive path or glob than "/var/log/activemq"?

We're trying hard to avoid collecting whole directories from /var since it often ends badly (e.g. when very large new directories are added as has happened with RHEV and Gluster).

(In reply to Bryn M. Reeves from comment #3)
> Can we get a more restrictive path or glob than "/var/log/activemq"?
> 
> We're trying hard to avoid collecting whole directories from /var since it
> often ends badly (e.g. when very large new directories are added as has
> happened with RHEV and Gluster).

The directory contains, only the logs for activemq, and you end up looking at something like 11 files (give or take a few based on configuration), totaling roughly 112 MB (for the default configuration). 

activemq.log     activemq.log.1   activemq.log.10  activemq.log.2   activemq.log.3   activemq.log.4   activemq.log.5   activemq.log.6   activemq.log.7   activemq.log.8   activemq.log.9   wrapper.log

The server (service) defines the log location and the rolling configuration as the following (by default): 

# File appender
log4j.appender.logfile=org.apache.log4j.RollingFileAppender
log4j.appender.logfile.file=${activemq.base}/log/activemq.log
log4j.appender.logfile.maxFileSize=10240KB
log4j.appender.logfile.maxBackupIndex=10
log4j.appender.logfile.append=true
log4j.appender.logfile.layout=org.apache.log4j.PatternLayout
log4j.appender.logfile.layout.ConversionPattern=%d | %-5p | %m | %c | %t%n

So depending on how this is set by a user, or how its defined you could better restrict the logs that are collected however I fell that would require that you read /etc/activemq/log4j.properties and get the location, and look a the maxBackupIndex to determin the proper regex to terminate the collection on.

- Note: ACTIVEMQ_BASE from /usr/share/activemq would also have to be read as the wrapper (start up script) is what defines, ${activemq.base} in the configuration above. 

/etc/activemq/wrapper.conf:wrapper.java.additional.2=-Dactivemq.base=%ACTIVEMQ_BASE%
/etc/activemq/wrapper.conf:wrapper.logfile=%ACTIVEMQ_BASE%/log/wrapper.log

> So depending on how this is set by a user,

That falls under the same rules as syslog/rsyslog configuration: we collect the default for the active policy and (optionally) provide a switch to enable parsing of the log configuration to collect additional/renamed logs.

(In reply to Bryn M. Reeves from comment #5)
> > So depending on how this is set by a user,
> 
> That falls under the same rules as syslog/rsyslog configuration: we collect
> the default for the active policy and (optionally) provide a switch to
> enable parsing of the log configuration to collect additional/renamed logs.

That's fine, my main point for point out the configuration and the files above was to give you the information you need, to limit the file collection as well as provide the optionally switch to read the configuration (should we choose), and get all the files.

(In reply to Bryn M. Reeves from comment #3)
> Can we get a more restrictive path or glob than "/var/log/activemq"?
> 
> We're trying hard to avoid collecting whole directories from /var since it
> often ends badly (e.g. when very large new directories are added as has
> happened with RHEV and Gluster).

Right. As the patch in comment #2 was meant to just fix the log collection in the rhel6 branch it didn't do anything around restricting the files to collect, just keeping what upstream and the current version of the plugin had.

I've amended upstream PR 457 to use the all_logs option as per comment #5. I didn't implement the improvements suggested in comment #4 though, just kept the default hardcoded.

Can someone post the relevant part of /usr/share/activemq/examples/conf/activemq-security.xml?

The activemq sos plugin was created as a spin-off of the openshift plugin and so far it's capturing/processing data from activemq used from an openshift perspective.

Unfortunately I'm not familiar enough with "standalone" activemq and its usage outside of the context of openshift to suggest additional data to collect and process.

A 'grep -i password' in the examples/conf dir shows various ways to specify passords via attributes:

       password="password"
       trustStorePassword="password"
       zkPassword="password"
       keyStorePassword="password"
       <property name="password" value="activemq"/>

Openshift installations only use the first one in /etc/activemq/activemq.xml, which is the (only) file that the plugin currently collects, and the plugin obfuscates that (i.e. the authenticationUser tags).

Here's the parof the installer script that creates that file:

  https://github.com/openshift/openshift-extras/blob/enterprise-2.2/enterprise/install-scripts/generic/openshift.sh#L2687

it doesn't set any property with passwords.

Probably worth opening separate bug(s) to collect and process additional files used in general activemq usage, but for the openshift use case it should be fine with the fix so far.

These attributes are easy enough to create substitution rules for. Given our main use is currently OpenShift I am not that concerned about this however it is something that we need to address when possible as users may be deploying ActiveMQ on their RHEL hosts for their own purposes.

Thanks guys for the clarification. I don't think we are shipping activemq outside openshift so I think it is safe to leave this as is for now.

I believe it is also available via some middleware products so it is certainly something we need to address.

cf. https://access.redhat.com/articles/310613

OK: I've spoken to our JBoss support team and I think we can go ahead as-is for 6.7.

The reason for this is that JBoss-AMQ and the ActiveMQ packages for JBoss customers are deployed as a ZIP archive. This means that they will not meet the trigger for the current sos activemq plugin (requires RPM packages named 'activemq' or 'activemq-core').

Since we do not use the activemq security attributes in OpenShift and since JBoss deployments of AMQ will not use RPM packaging we are safe to ship 6.7 without a postproc method for these patterns.

We should obviously still follow up with this upstream and in future updates but for now there appears to be very limited risk for the current approach.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-1323.html