Skip to main content

ActiveMQ - OpenTelemetry Collector

icon

The ActiveMQ app is a unified logs and metrics app that helps you monitor the availability, performance, health, and resource utilization of your ActiveMQ messaging clusters. Preconfigured dashboards provide insight into cluster status, nodes, producers, consumers, destinations, resource utilization, message rates, and error logs.

We use the OpenTelemetry collector for ActiveMQ metrics and logs collection.

The diagram below illustrates the components of the ActiveMQ collection for each ActiveMQ broker node. OpenTelemetry collector runs on the same host as ActiveMQ broker, and uses the JMX Receiver to obtain ActiveMQ metrics, and the Sumo Logic OpenTelemetry Exporter to send the metrics to Sumo Logic. ActiveMQ logs are sent to Sumo Logic through a filelog receiver.

ActiveMQ OTel Collection architecture

This app has been tested with following ActiveMQ versions:

  • 5.17.4
  • 5.18.2

Log and metrics types

The Sumo Logic App for ActiveMQ assumes:

  • ActiveMQ app supports the below log format in the log4j2.properties file.

    • Audit Logs: Every management action made through JMX or Web Console management interface is logged in audit log files.

      appender.auditlog.layout.pattern=%d | %-5p | %m | %t%n

    • ActiveMQ Logs:

      appender.logfile.layout.pattern=%d | %-5p | %m | %c | %t%n%throwable{full}

  • For a list of metrics that are collected and used by the app, see ActiveMQ Metrics.

Fields creation in Sumo Logic for ActiveMQ

Following are the fields which will be created as part of ActiveMQ App install if not already present.

  • messaging.cluster.name. User configured. Enter a name to uniquely identify your ActiveMQ cluster. This cluster name will be shown in the Sumo Logic dashboards.
  • messaging.node.name. Has value of host name.
  • messaging.system. Has fixed value of activemq.
  • sumo.datasource. Has fixed value of activemq.

If process metrics are enabled it will also create fields for JMX metrics.

Prerequisites

Configure logging in ActiveMQ:

  1. By default, ActiveMQ logs (audit.log and activemq.log) are stored in the directory called ${ACTIVEMQ_HOME}/data/activemq.log. Make a note of this logs directory.
  2. Enable auditing if not enabled by default. ACTIVEMQ_OPTS="$ACTIVEMQ_OPTS -Dorg.apache.activemq.audit=true"
  3. Ensure that below log formats are present in logging configuration. Also make sure appropriate log level is set.
  • Audit Logs: appender.auditlog.layout.pattern=%d | %-5p | %m | %t%n
  • ActiveMQ Logs: appender.logfile.layout.pattern=%d | %-5p | %m | %c | %t%n%throwable{full}

For Linux systems with ACL Support, the otelcol install process should have created the ACL grants necessary for the otelcol system user to access default log locations. You can verify the active ACL grants using the getfacl command. Install the ACL in your Linux environment, if not installed.

The required ACL may not be supported for some rare cases, for example, Linux OS Distro, which is officially not supported by Sumo Logic. In this case, you can run the following command to explicitly grant the permissions.

sudo setfacl -R -m d:u:otelcol-sumo:r-x,d:g:otelcol-sumo:r-x,u:otelcol-sumo:r-x,g:otelcol-sumo:r-x <PATH_TO_LOG_FILE>

Run the above command for all the log files in the directory that need to be ingested, which are not residing in the default location.

If Linux ACL Support is not available, traditional Unix-styled user and group permission must be modified. It should be sufficient to add the otelcol system user to the specific group that has access to the log files.

For Windows systems, log files which are collected should be accessible by the SYSTEM group. Use the following set of PowerShell commands if the SYSTEM group does not have access.

$NewAcl = Get-Acl -Path "<PATH_TO_LOG_FILE>"
# Set properties
$identity = "NT AUTHORITY\SYSTEM"
$fileSystemRights = "ReadAndExecute"
$type = "Allow"
# Create new rule
$fileSystemAccessRuleArgumentList = $identity, $fileSystemRights, $type
$fileSystemAccessRule = New-Object -TypeName System.Security.AccessControl.FileSystemAccessRule -ArgumentList $fileSystemAccessRuleArgumentList
# Apply new rule
$NewAcl.SetAccessRule($fileSystemAccessRule)
Set-Acl -Path "<PATH_TO_LOG_FILE>" -AclObject $NewAcl

Configure metrics in ActiveMQ

  1. Follow the instructions in JMX - OpenTelemetry's prerequisites section to download the JMX Metric Gatherer used by the JMX Receiver.
  2. Enable reads metrics from ActiveMQ servers via the JMX MBeans by setting useJmx="true" in file config ActiveMQ.xml
        <broker useJmx="true" brokerName="BROKER1">
    ...
    </broker>
  3. Set the JMX port by changing the ACTIVEMQ_SUNJMX_START parameter. Usually it is set in /opt/activemq/bin/env or C:\Program Files\apache-activemq\bin\activemq.bat file.
    ACTIVEMQ_SUNJMX_START="$ACTIVEMQ_SUNJMX_START -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=11099 -Dcom.sun.management.jmxremote.ssl=false  -Dcom.sun.management.jmxremote.password.file=${ACTIVEMQ_CONF_DIR}/jmx.password -Dcom.sun.management.jmxremote.access.file=${ACTIVEMQ_CONF_DIR}/jmx.access"

Collection configuration and app installation

As part of data collection setup and app installation, you can select the App from App Catalog and click on Install App. Follow the steps below.

Step 1: Set up OpenTelemetry Collector

note

If you want to use an existing OpenTelemetry Collector, you can skip this step by selecting the Use an existing Collector option.

To create a new Collector:

  1. Select the Add a new Collector option.
  2. Select the platform where you want to install the Sumo Logic OpenTelemetry Collector.

This will generate a command that you can execute in the machine environment you need to monitor. Once executed, it will install the Sumo Logic OpenTelemetry Collector.

Collector

Step 2: Configure integration

In this step we will be configuring the YAML required for ActiveMQ Collection.

Below is the input required:

  • ActiveMQ Server logs file path. Enter the path to the ActiveMQ log file for your ActiveMQ instance.
  • ActiveMQ Audit logs file path. Enter the path to the Audit log file for your ActiveMQ instance.
  • JMX Endpoint. Enter the value in host:port form which will be used to construct the Service URL, the Metric Gatherer's JMX client should use.
  • JMX Gatherer file path. Enter the path to the OpenTelemetry JMX Metric Gatherer file configured in the prerequisites section.
  • Enable password authentication. Toggle this if you are using password based jmx authentication.
  • UserName. Username for JMX authentication, if applicable.
  • Password. Password for JMX authentication, if applicable.
  • Enable ActiveMQ process metrics. Toggle this to collect ActiveMQ Process metrics. Disable this if you are already collecting process metrics from the host.
  • ActiveMQ process name. Enter the ActiveMQ process name.It will be used for filtering process metrics based on process name.
  • Fields. messaging.cluster.name User configured. Enter a name to identify this ActiveMQ cluster. This cluster name will be shown in the Sumo Logic dashboards.

Click on the Download YAML File button to get the YAML file.

YAML

Step 3: Send logs and metrics to Sumo

Once you have downloaded the yaml file as described in the previous step, follow the below steps based on your platform.

  1. Copy the YAML file to /etc/otelcol-sumo/conf.d/ folder in the ActiveMQ instance that needs to be monitored.
  2. Restart the collector using:
sudo systemctl restart otelcol-sumo

After successfully executing the above command, Sumo Logic will start receiving data from your host machine.

Click Next. This will install the app (dashboards and monitors) to your Sumo Logic Org.

Dashboard panels will start to fill automatically. It's important to note that each panel fills with data matching the time range query and received since the panel was created. Results won't immediately be available, but within 20 minutes, you'll see full graphs and maps.

Sample log messages

activemq.log

2021-06-22 15:00:41,922 | DEBUG | Stopping transport tcp:///192.168.100.8:36302@61616 | org.apache.activemq.transport.tcp.TcpTransport | ActiveMQ BrokerService[localhost] Task-15300

audit.log

2010-12-22 12:12:07,225 | INFO  | admin requested /admin/createDestination.action [JMSDestination='test' JMSDestinationType='queue' secret='4eb0bc3e-9d7a-4256-844c-24f40fda98f1' ] from 127.0.0.1 | qtp12205619-39
2010-12-22 12:12:14,512 | INFO | admin requested /admin/purgeDestination.action [JMSDestination='test' JMSDestinationType='queue' secret='eff6a932-1b58-45da-a64a-1b30b246cfc9' ] from 127.0.0.1 | qtp12205619-36
2010-12-22 12:12:17,802 | INFO | admin requested /admin/sendMessage.action [JMSTimeToLive='' JMSXGroupSeq='' AMQ_SCHEDULED_DELAY='' JMSType='' JMSMessageCountHeader='JMSXMessageCounter' JMSXGroupID='' JMSReplyTo='' JMSDestination='test' AMQ_SCHEDULED_PERIOD='' JMSText='Enter some text
here for the message body...' JMSDestinationType='queue' AMQ_SCHEDULED_CRON='' JMSCorrelationID='' AMQ_SCHEDULED_REPEAT='' JMSMessageCount='1' secret='a0e1df62-14d6-4425-82a2-17aa01a16e7d' JMSPriority='' ] from 127.0.0.1 | qtp12205619-37

Sample queries

Log query

This sample Query is from the Events by Severity panel of the ActiveMQ - Logs dashboard.

sumo.datasource=activemq deployment.environment={{deployment.environment}} messaging.cluster.name={{messaging.cluster.name}} messaging.node.name={{messaging.node.name}}
| json auto maxdepth 1 nodrop
| if (isEmpty(log), _raw, log) as raw_log_message
| parse field=raw_log_message "*|*|*|*|*" as timedate,severity,msg,class,address |trim(severity) as severity | count by severity

Metrics query

Sample query from Average Enqueue Latency panel in ActiveMQ - Destinations dashboard.

sumo.datasource=activemq deployment.environment={{deployment.environment}} messaging.cluster.name={{messaging.cluster.name}} messaging.node.name={{messaging.node.name}} destination={{destination}} !(destination=activemq.*)  metric=activemq.message.wait_time.avg | avg by destination,messaging.cluster.name

Sample metrics

"Query","metric","deployment.environment","host.name","messaging.cluster.name","messaging.node.name","messaging.system","os.type","sumo.datasource","broker","destination","unit","latest"
"#A","activemq.message.wait_time.avg","testprod","ip-10-0-10-92","activemq_cluster","ip-10-0-10-92","activemq","linux","activemq","localhost","testtopic","ms","254.4"

Viewing the ActiveMQ dashboards

Dashboard filters with template variables

Template variables provide dynamic dashboards that rescope data on the fly. As you apply variables to troubleshoot through your dashboard, you can view dynamic changes to the data for a fast resolution to the root cause. For more information, see the Filter with template variables help page.

Overview

The ActiveMQ - Overview dashboard gives you an at-a-glance view of your ActiveMQ deployment across brokers, queues, topics, and messages.

Use this dashboard to:

  • Analyze memory, errors and connections.
  • Gain insights into Enqueue messages for your ActiveMQ server and compare it with last week's trend.
  • Gain insights into Dequeue messages for your ActiveMQ server and compare it with last week's trend.
  • Determine queues/topics with no producers and consumers.
  • Determine queues/topics with expired messages.
ActiveMQ dashboards

Brokers

The ActiveMQ - Brokers dashboard provides an at-a-glance view of the state of your brokers in the ActiveMQ cluster.

Use this dashboard to:

  • Gain insights into the storage and temp storage for your ActiveMQ brokers.
  • Gain insights into enqueue rate, dequeue rate for your ActiveMQ brokers.
  • Determine the amount of current connections, producers, and consumers for your ActiveMQ brokers.
ActiveMQ dashboards

Destinations

The ActiveMQ - Destinations dashboard provides an at-a-glance view of the state of your topics/queues in ActiveMQ clusters.

Use this dashboard to:

  • Monitor enqueue latency across topics/queues.
  • Gain insights into enqueue rate, dequeue rate across topics/queues.
  • Monitor producers, consumers and expired messages on topics/queues.
  • Determine the number of topics/queues.
ActiveMQ dashboards

Resource utilization

The ActiveMQ - Resource Utilization dashboard provides an at-a-glance view of the state of system loads in clusters: Virtual memory usage, physical memory usage, CPU utilization, disk operations, disk writes, and I/O wait.

Use this dashboard to:

  • Analyze memory and CPU utilization of activemq process.
  • Gain insights into disk write operations and disk write bytes of activemq process.
  • Gain insights into memory utilization by topics/queues.
ActiveMQ dashboards

Logs

The ActiveMQ - Logs dashboard helps you quickly analyze your ActiveMQ error logs across all clusters.

Use this dashboard to:

  • Identify critical events in your ActiveMQ cluster.
  • Examine trends to detect spikes in error or fatal events
  • Monitor Broker added/started and shutdown events in your cluster.
  • Quickly determine patterns across all error logs in a given ActiveMQ cluster.
ActiveMQ dashboards

Audit

This ActiveMQ - Audit dashboard helps you quickly analyze your ActiveMQ audit logs across all clusters.

Use this dashboard to:

  • Identify locations of users performing management action.
  • Track username, operation, and IP address for each management level event.
  • Monitor create and delete activity in your cluster.
  • Quickly determine patterns across all audit logs in a given ActiveMQ cluster.
ActiveMQ dashboards
Legal
Privacy Statement
Terms of Use

Copyright © 2024 by Sumo Logic, Inc.