How to Monitor IBM MQ with AppDynamics using LAMAXU

Defining the AppDynamics Agent

To integrate LAMAXU with AppDynamics, simply include the AppDynamics -javaagent option to the LAMAXU startup.sh script.

Please contact your AppDynamics administrators as they need to generate, and provide you with, a new client configuration bundle for every LAMAXU agent deployed.

The ./conf/controller-info.xml located in the AppDynamics agent’s directory contains information about the server LAMAXU will push JMX updates to.

Example; This example uses the following values to identify the LAMAXU agent.

./conf/controller-info.xml

Adding the AppDynamics Agent to the LAMAXU Start-up

Add the option in red below to the ${LAMAXU_HOME}/bin/startup.sh|startup.bat files.
nohup "$JAVA_HOME/bin/java" -javaagent:/app/AppServerAgent-4.0.6.0/ver4.0.6.0/javaagent.jar -DLOG_PATH=${LAMAXU_HOME}/logs -cp ${LAMAXU_CLASSPATH} com.qm.lamaxu.Main -config ${LAMAXU_HOME}/config/config.xml >nohup.out 2>&1 &

Testing AppDynamics works with LAMAXU

Once the LAMAXU agent has been started, open AppDynamics and navigate to the LAMAXU MQ Application on the menu.

Once in the LAMAXU MQ application, navigate to App Servers and select the node.

Testing AppDwithLamaxu

Navigate to ‘More/JMX’ and click on the ‘Refresh Domains’ button to view the monitored MQ queue manager MBeans, as show in screen shots below.

Testing AppDwithLamaxu1

Testing AppDwithLamaxu2

How to Monitor IBM MQ with Solarwinds and Queuemetrix Lamaxu

Queuemetrix Lamaxu extends the monitoring capability of solarwinds SAM by enabling the monitoring of IBM MQ message flows and metrics.

LAMAXU interfaces natively with solarwinds ® using standard Java JMX MBeans, making IBM MQ appear just like a Java Application Server.

SolarWindsSummaryPage

SolarWindsComponentStats

SETTING UP THE LAMAXU JMX GATEWAY

The JMX Gateway can be accessed using an RFC2609 compliant service url:

service:jmx:rmi://<TARGET_MACHINE>:<JMX_RMI_SERVER_PORT>/jndi/rmi://<TARGET_MACHINE>:<RMI_REGISTRY_PORT>/jmxrmi

Given the above and the following parameters:

TARGET_MACHINE = auprod1
JMX_RMI_SERVER_PORT = 3098
RMI_REGISTRY_PORT = 3099

We can derive the following functional URL:

service:jmx:rmi://auprod1:3098/jndi/rmi://auprod1:3099/jmxrmi

For convenience, this URL is also written to the LAMAXU log file at start-up:

2015-11-23 18:07:37,039 [main] JmxGateway remote url is: service:jmx:rmi://auprod1:3098/jndi/rmi://auprod1:3099/jmxrmi

You can now use the URL above to connect to the LAMAXU JMX gateway process.

JconsoleUrl

Locate and execute the JDK utility jconsole. On startup you will be prompted for a URL, username and password. You should be able to connect to LAMAXU successfully,  assuming authentication and SSL details have been defined correctly.

1. As illustrated in the screenshot below, the MQ queue manager information is displayed under the MBeans tab.
2. A successful connection via jconsole means you can now proceed to connecting Solarwinds using the same parameters.

SSL secured communications

A LAMAXU process secured by SSL can be accessed by specifying an appropriately configured JKS trust store.

The command below can be specified on the jconsole command line:

jconsole -J-Djavax.net.ssl.trustStore=/app/LAMAXU/keystore.jks -J-Djavax.net.ssl.trustStorePassword=changeit

Jconsole

QUEUE MANAGER STATUS

SolarWindsJMXmbeanSelect1

QUEUE STATUS

SolarWindsJMXmbeanQStatus

CHANNEL STATUS

SolarWindsJMXmbeanChStatus1

PUB/SUB STATUS

SolarWindsJMXmbeanPSStatus

Benefits of the LAMAXU JMX Architecture

LAMAXU JMX enables the monitoring of IBM MQ resources using standard Java JMX technology by instrumenting WMQ objects like queue managers, queue/subscriber and channel statuses etc, in the Java programming language. WMQ objects are exposed as MBeans in order to implement access to the objects’ instrumentation.

qm_jmx

The JMX technology integrates with existing monitoring/management solutions and emerging technologies. The JMX APIs are open interfaces that any management system vendor can implement. JMX solutions can use look-up and discovery services and protocols such as Jini network technology and the Service Location Protocol (SLP).

Architecture of the Java JMX Technology

The JMX architecture is divided into three levels:

  1. Instrumentation level
  2. JMX Agent level
  3. Remote management

Instrumentation Level

To manage resources using the JMX technology, you must first instrument the resources in the Java programming language. You use Java objects known as MBeans to implement the access to the resources’ instrumentation. MBeans must follow the design patterns and interfaces defined in the JMX specification. Doing so ensures that all MBeans provide managed resource instrumentation in a standardized way. In addition to standard MBeans, the JMX specification also defines a special type of MBean called an MXBean. An MXBean is an MBean that references only a pre-defined set of data types. Other types of MBean exist, but this trail will concentrate on standard MBeans and MXBeans.

Once a resource has been instrumented by MBeans, it can be managed through a JMX agent. MBeans do not require knowledge of the JMX agent with which they will operate.

MBeans are designed to be flexible, simple, and easy to implement. Developers of applications, systems, and networks can make their products manageable in a standard way without having to understand or invest in complex management systems. Existing resources can be made manageable with minimum effort.

In addition, the instrumentation level of the JMX specification provides a notification mechanism. This mechanism enables MBeans to generate and propagate notification events to components of the other levels.

JMX Agent

A JMX technology-based agent (JMX agent) is a standard management agent that directly controls resources and makes them available to remote management applications. JMX agents are usually located on the same machine as the resources they control, but this arrangement is not a requirement.

When you implement a JMX agent, you do not need to know the semantics or functions of the resources that it will manage. In fact, a JMX agent does not even need to know which resources it will serve because any resource instrumented in compliance with the JMX specification can use any JMX agent that offers the services that the resource requires. Similarly, the JMX agent does not need to know the functions of the management applications that will access it.

The core component of the LAMAXU JMX agent is the MBean server, a managed object server in which MBeans are registered. The LAMAXU JMX agent also includes a set of services to manage MBeans, and at least one communications adapter or connector to allow access by a management application.

Remote Management

JMX technology instrumentation can be accessed in many different ways, either through existing management protocols such as the Simple Network Management Protocol (SNMP) or through proprietary protocols. The MBean server relies on protocol adapters and connectors to make a JMX agent accessible from management applications outside the agent’s Java Virtual Machine (Java VM).

Each adapter provides a view through a specific protocol of all MBeans that are registered in the MBean server. For example, an HTML adapter could display an MBean in a browser.

Connectors provide a manager-side interface that handles the communication between manager and JMX agent. Each connector provides the same remote management interface through a different protocol. When a remote management application uses this interface, it can connect to a JMX agent transparently through the network, regardless of the protocol. The JMX technology provides a standard solution for exporting JMX technology instrumentation to remote applications based on Java Remote Method Invocation (Java RMI).

Identify and Resolve Issues with your Critical MQ Messaging Faster with Lamaxu

Banks and other financial institutions typically rely on IBM’s MQ messaging product to securely transfer high value payments or other critical messages.
MQ has been the de facto standard enterprise grade messaging product for over 15 years and is supported across 80+ platforms. It can be thought of as plumbing for your messaging.

Often financial organisations face very stiff consequences for failing to make payments on time. Missing payment cut-off deadlines by just a few hours can be very costly in both monetary terms and reputational damage. When the payments run into the hundreds of millions of dollars, overnight interest can cost the bank thousands of dollars.

Traditionally it has been difficult to monitor MQ and obtain detailed metrics from MQ around how the MQ infrastructure is performing – mainstream monitoring products provide little or no support for MQ objects.

Lamaxu solves these problems in a simple easy to use application that works in harmony with your existing monitoring setup.

Lamaxu’s wide support for the new breed of monitoring products such as Splunk, Solarwinds and AppDynamics means you can start monitoring MQ using your current monitoring setup without changing alerts, workflows, procedures or call-outs.

Lamaxu integrates with these products seamlessly and gives you dramatically better insight of what is going on within your MQ estate allowing MQ statistics and status information to be presented alongside your existing apps’ stats.

Lamaxu’s simple agentless deployment is supported across Linux, Windows and now mainframe — meaning that you can be rapidly up and running without installing any software on your MQ hosts – especially useful in sensitive production environments.

To explore how Lamaxu can benefit your organisation contact us at info@queuemetrix.com

How to Monitor IBM MQ with SPLUNK and LAMAXU

What is SPLUNK

Splunk (the product) captures, indexes and correlates real-time data in a searchable repository from which it can generate graphs, reports, alerts, dashboards and visualizations.
SPLUNK Web Site

Sample SPLUNK Dashboard

SPLUNK_dashboard

Using SPLUNK

Once you have added the LAMAXU logs data to SPLUNK the MQ metrics can be queried using SPLUNK search syntax.

UsingSplunk

Graphing the Current Queue Depth

source=”statusData.log” sourcetype=”_json_lamaxuStatus” “identifier.dataSource”=DEMO “attributes.CURDEPTH”=”*” “attributes.QUEUE”!=”AMQ.*” “attributes.QUEUE”!=”SYSTEM.*”| timechart avg(“attributes.CURDEPTH”) by attributes.QUEUE

GraphCurrent QueueDepth

Graphing Message Volume Statistics

source=”statData.log” sourcetype=_json_lamaxuEvents “identifier.dataType”=STATISTICS  identifier.dataSource”=DEMO ” attributes.QUEUE”=”QM_TEST_REPLY1*” | eval pfields=split(‘attributes.MQIAMO_PUTS’, ” “)  | eval PUTSNP=mvindex(pfields,0)| eval PUTSP=mvindex(pfields,1) |eval TPUTS=PUTSNP+PUTSP| eval gfields=split(‘attributes.MQIAMO_GETS’, ” “) | eval GETSNP=mvindex(gfields,0)| eval GETSP=mvindex(gfields,1) |eval TGETS=GETSNP+GETSP | timechart avg(attributes.MQIAMO_Q_MAX_DEPTH)  as “Hwm” avg(TPUTS) as “Puts” avg(TGETS) as Gets

GraphMsgVolumeStats

Graphing Message Time on Queue

source=”statusData.log” “attributes.QTIME”=”*” “attributes.QUEUE”!=”SYSTEM.*” “attributes.QUEUE”!=”AMQ.*” sourcetype=”_json_lamaxuStatus” “identifier.dataSource”=DEMO| timechart avg(“attributes.QTIME”) by attributes.QUEUE

GraphMsgTimeOnQueue

LAMAXU/SPLUNK Source Types

The following source type need to be added to your SPLUNK props.conf file in order to correctly recognise the time-stamp fields in the log file. Alternatively you could manually create the source types using the red highlight values as a guide to defining the time-stamps.

Source type for LAMAXU Status logs

[_json_lamaxuStatus]
INDEXED_EXTRACTIONS = json
KV_MODE = none
NO_BINARY_CHECK = true
TIMESTAMP_FIELDS = createDate
TIME_FORMAT = %d/%m/%Y %OI:%M:%S %p
TZ = Australia/Sydney
category = Structured
description = JavaScript Object Notation format. For more information, visit
http://json.org/
disabled = false
pulldown_type = true

Source type for LAMAXU Event logs

[_json_lamaxuEvents]
INDEXED_EXTRACTIONS = json
KV_MODE = none
NO_BINARY_CHECK = true
TIMESTAMP_FIELDS = attributes.MQCAMO_END_DATE,attributes.MQCAMO_END_TIME
TIME_FORMAT = %Y-%m-%d %H.%M.%S
TZ = Australia/Sydney
category = Structured
description = JavaScript Object Notation format. For more information, visit
http://json.org/
disabled = false
pulldown_type = true

Log File Format for statusData.log

Log file attributes are modeled on the IBM MQ runmqsc attribute names.

QMGR_STATUS
{
    "identifier": {
        "dataSource": "DEMO",
        "dataType": "QMGR_STATUS",
        "sui": "DEMO"
    },
    "createDate": "10/10/2015 9:47:45 AM",
    "attributes": {
        "STARTTI": "13.44.07",
        "INSTDESC": "",
        "CONNS": "24",
        "STANDBY": "NOPERMIT",
        "INSTNAME": "Installation1",
        "CHINIT": "RUNNING",
        "STATUS": "RUNNING",
        "STARTDA": "2015-09-30",
        "CMDSERV": "RUNNING",
        "LDAPCONN": "INACTIVE",
        "QMNAME": "DEMO"
    },
    "category": "STATUS"
}
QUEUE_STATUS
{
    "identifier": {
        "dataSource": "DEMO",
        "dataType": "QUEUE_STATUS",
        "sui": "LOCALQNAME"
    },
    "createDate": "10/10/2015 11:47:42 AM",
    "attributes": {
        "IPPROCS": "2",
        "LGETDATE": "",
        "QTIME": "-1 -1",
        "QUEUE": "LOCALQNAME",
        "MONQ": "OFF",
        "OPPROCS": "2",
        "CURDEPTH": "0",
        "LGETTIME": "",
        "MSGAGE": "-1",
        "LPUTDATE": "",
        "LPUTTIME": "",
        "TYPE": "QSTATUS",
        "UNCOM": "NO"
    },
    "category": "STATUS"
}
SUBSCRIPTION_STATUS
{
    "identifier": {
        "dataSource": "DEMO",
        "dataType": "SUBSCRIPTION_STATUS",
        "sui": "TEST.SUBSCRIBER "
    },
    "createDate": "10/10/2015 9:47:45 AM",
    "attributes": {
        "MCASTREL": "-1 -1",
        "DURABLE": "NO",
        "LMSGTIME": "",
        "RESMDATE": "2015-10-10",
        "QMNAME": "DEMO",
        "CURDEPTH": "4",
        "MSGAGE": "0",
        "TOPICSTR": "TEST.TOPIC",
        "SUB": "TEST.SUBSCRIBER",
        "LMSGDATE": "",
        "SUBID": "414d512044454d4f2020202020202020885a0b56049a9c20",
        "NUMMSGS": "0"
    },
    "category": "STATUS"
} 
PUBSUB_STATUS
{
    "identifier": {
        "dataSource": "DEMO",
        "dataType": "PUBSUB_STATUS",
        "sui": "DEMO"
    },
    "createDate": "10/10/2015 9:47:45 AM",
    "attributes": {
        "TPCOUNT": "6",
        "STATUS": "ACTIVE",
        "TYPE": "LOCAL",
        "SUBCOUNT": "3",
        "QMNAME": "DEMO"
    },
    "category": "STATUS"
}
LISTENER_STATUS
{
    "identifier": {
        "dataSource": "DEMO",
        "dataType": "LISTENER_STATUS",
        "sui": "DEMO.1414"
    },
    "createDate": "10/10/2015 9:47:26 AM",
    "attributes": {
        "STARTTI": "00.31.37",
        "PORT": "1414",
        "PID": "38076556",
        "TRPTYPE": "TCP",
        "BACKLOG": "100",
        "IPADDR": "::ffff:10.30.40.74",
        "STATUS": "RUNNING",
        "LISTENER": "DEMO.1414",
        "STARTDA": "2015-10-10",
        "DESCR": "DEMO default Listener"
    },
    "category": "STATUS"