Come join our live training webinar every other Wednesday at 11am PST and hear LogicMonitor experts explain best practices and answer common questions. We understand these are uncertain times, and we are here to help!
LogicMonitor has two datasources for monitoring SQS performance metrics:
Default Polling Interval: 5 minutes
Additional Configuration Necessary?: No. This datasource will automatically apply to the SQS resources discovered for your AWS account and start collecting data.
This datasource utilizes the AWS SDK to perform SQS operations, and measures the transaction times. Note that this datasource does not measure the round-trip time of an individual SQS message – there is no guarantee that the message placed in a queue is the same one measured for the retrieval operation. Instead, it measures the time to perform GetMessage and ReceiveMessage operations, independently. This measurement will take into account network latency and real processing times, as measured from the collectors.
Source: AWS SDK
Additional Configuration Necessary?: Yes – see below section. This datasource inserts and removes SQS messages from a queue, and as such requires a specific SQS queue designated solely for these measurement transactions, to ensure it does not impact messages placed in other queues. To ensure accurate measurements, the configuration of this queue will be automatically set by LogicMonitor to a 1 minute message retention policy. This also ensures that the queue has been appropriately designated as a measurement queue, by ensuring that the account LogicMonitor uses to access AWS has been given complete rights to this queue.
In order to use this datasource, the following steps are required:
Create SQS measurement queues
As noted above, this datasource will insert and remove messages from a queue, and so should not be associated with production SQS queues. Instead, specific SQS measurement queues should be created in each region where production SQS queues exist, in order to identify issues with accessing SQS services.
To do so, access the SQS service in the AWS console, and create a new SQS queue. We recommend naming the queue like “SQSLatencyTest_us_east_1”, to easily identify that it is for latency testing. Accept the default queue configuration – LogicMonitor will adjust the queue configuration appropriately.
You should create a latency test queue in each region that you have production SQS queues.
Assign the AWS user that LogicMonitor is using complete rights to each SQS measurement queue
Attach a policy such as the below to the AWS user that you have set up in LogicMonitor to monitor AWS:
Replace ACCOUNTID with your AWS account. This will grant the appropriate privileges to all SQS queues, in all regions, whose name starts with SQSLatencyTest. Note that the monitoring will fail unless SetQueueAttributes right is granted.
Associate the datasource, and specify where to measure from
From Settings | Datasources, search for the AWS_SQS_MessageLatency datasource.
If you created SQS measurement queues with the suggested names (containing “SQSLatencyTest”), you do not need to change the AppliesTo field.
In all cases, however, you will need to edit the Collector IDs in the Active Discovery section. This specifies which collectors will run this datasource, and report on SQS latency.
You specify the collector id, and an optional identifier for that collector, for each collector that will measure the time to send and receive SQS messages.
1=Los Angeles, 2=London Datacenter, 3
would create instances of this datasource whereby the SQS times are measured from 3 different collectors (with collector IDs 1, 2 and 3), with descriptive text shown for the first two.
In This Article