As part of monitoring our backend components, we will need to gain an insight into the messaging statistics. The SQS is designed to provide essentially unlimited performance for our messaging needs, so the metrics being collected from the SQS will not have any information about the performance of the service. However, there will be crucial information about the delivery of messages that can help us gain insight into the messaging component of our application. 

The CloudWatch overview console for the SQS provides us with a common set of statistics that we need to track, as can be seen in the following screenshot:

There are several important metrics that will tell us if our application is performing correctly. For example, a continuously growing number of messages in our queue could indicate that the workers are unable to process the messages in time. This could be because of messages that are broken and cannot be successfully processed. These should be moved to a dead letter queue.

We should also be mindful of the number of empty responses, as the service charges will apply even to GET requests that receive an empty response. When we have a lot of empty responses, we should implement an exponential back-off strategy to reduce the amount of GET operations against the SQS and thus reduce our costs of retrieving messages from the queue.