Monitoring Amazon SQS with AppDynamics

AppDynamics recently announced the support for applications running an expanded suite of services from Amazon Web Services (AWS). As many enterprises are migrating or deploying their new applications in the AWS Cloud, it is important to have deeper insight and control over the applications and the underlying infrastructure in order to ensure they can deliver exceptional end-user experience.

AppDynamics offers the same performance monitoring, management, automated processes, and analytics for applications running on AWS that are available for applications running on-premises. With the AppDynamics Summer ’15 Release, applications deployed on AWS are now easily instrumented to provide complete visibility and control into an expanded set of AWS services, including Amazon Simple Queue Service (Amazon SQS), Amazon Simple Storage Service (Amazon S3), and Amazon DynamoDB.

In this blog, I will focus on monitoring of applications using Amazon SQS. As per the AWS web page, “Amazon SQS is a fast, reliable, scalable, fully managed message queuing service. SQS makes it simple and cost-effective to decouple the components of a cloud application. You can use SQS to transmit any volume of data, at any level of throughput, without losing messages or requiring other services to be always available.”

The Amazon SQS Java Messaging Library, which is a Java Messaging Service (JMS) interface to Amazon SQS, enables you to use Amazon SQS in the applications that already use JMS.

Message queues in SQS can be created either manually, or via the SQS Java Messaging Library and AWS Java SDK, and messages can be sent or received to the queues in various ways for different use cases.

Here is an application flow map in AppDynamics for a sample application using Amazon SQS for the following three use cases:

• Basic send/receive

• Batched send/receive

• Async send/receive

AppDynamics supports all exit points for the Amazon SQS out of the box. Each exit point is treated exactly like JMS, .NET messaging, etc. for all of the use cases outlined above.

At this time, the entry point to the Amazon SQS is supported as part of a continuing transaction only. For example, if a transaction originates at some tier “foo” and continues via an exit through some SQS queue to a downstream tier, bar – the transaction on the “bar” may continue given the appropriate configuration. The user must specify a custom-interceptors.xml configuration file to apply the special SQS entry point interceptor to a given method and to configure where to obtain the correlation header.

My colleague Anthony Kilman shared the following example in case a user’s downstream application were processing messages received from an SQS message:

public abstract class  ASQSConsumer extends ASQSActor {

   …

   protected void processMessage(Message message) {

       log.info(”  Message”);

       log.info(“ MessageId: ” + message.getMessageId());

       log.info(“ ReceiptHandle: ” + message.getReceiptHandle());

       log.info(“ MD5OfBody: ” + message.getMD5OfBody());

       log.info(“ Body:       ” + message.getBody());

       for (Map.Entry<String, String> entry : message.getAttributes().entrySet()) {

           log.info(”  Attribute”);

           log.info(“ Name:  ” + entry.getKey());

           log.info(“ Value: ” + entry.getValue());

       }

       Map<String, MessageAttributeValue> messageAttributes = message.getMessageAttributes();

       log.info(“message attributes: ” + messageAttributes);

   }

   …

}

Then, the configuration to continue the transaction would be as follows:

<custom-interceptors>

<custom-interceptor>

   <interceptor-class-name>com.singularity.SQSEntryPoint</interceptor-class-name>

   <match-class type=”matches-class”>

       <name filter-type=”equals”>aws.sqs.test.ASQSConsumer</name>

   </match-class>

   <match-method>

       <name>processMessage</name>

   </match-method>

   <configuration type=”param” param-index=”0″ operation=”getter-chain” operation-config=”this”/>

</custom-interceptor>

</custom-interceptors>

This configuration will result in a snapshot like the following:

To learn more about cloud application performance monitoring and AWS cloud, please go to http://www.appdynamics.com/cloud/.

Read our complimentary white paper, Managing the Performance of Cloud-Based Applications.