This alert monitors and detects sudden surges in message traffic to ensure the SQS queue can handle increased loads without performance degradation. It helps identify potential issues or changes in the behaviour of applications sending messages to the queue. An alert triggers if the number of messages sent exceeds the usual volume by more than 1,000 messages per hour. This condition may indicate an unexpected increase in incoming traffic, which could be due to higher demand, application issues, or an unanticipated spike in activity. Customization Guidance: - Threshold: The default threshold is set to trigger an alert if the number of messages sent exceeds the usual volume by more than 1,000 messages per hour. Adjust this threshold based on the specific queue and expected load to better reflect operational norms and service requirements. - Monitoring Period: Adjust the monitoring period to shorter or longer than 1 hour based on traffic patterns and service criticality. Use shorter periods for high-traffic, critical functions to catch issues more rapidly. - Notification Frequency: Consider the frequency of this alert to optimize the balance between responsiveness and noise. Adjust according to the criticality of the service’s uninterrupted operation. Action: If this alert triggers, investigate the source of the increased message traffic by checking application logs and metrics. Verify that the SQS queue has sufficient capacity and throughput to manage the additional load. Assess the health and configuration of applications interfacing with SQS to identify and resolve anomalies. If the increase is legitimate due to higher demand, consider scaling your infrastructure to accommodate the additional traffic. Implement rate limiting or message throttling to prevent overloading the queue.

This alert is designed to monitor and detect excessive empty receive attempts in Amazon SQS. It ensures that the SQS queue is functioning optimally and that messages are being processed as expected. This alert helps identify potential issues with message availability or inefficiencies in message retrieval processes. An empty receive occurs when a ReceiveMessage call does not return any messages. A high number of empty receives may indicate issues with message availability or inefficiencies in message retrieval processes. An alert triggers if more than 500 empty receive attempts occur within a 10-minute window. Customization Guidance: - Threshold: The default threshold is set to trigger an alert if more than 500 empty receive attempts occur within a 10-minute window. Adjust this threshold based on the specific queue and expected load to better reflect operational norms and service requirements. - Monitoring Period: Adjust the monitoring period to shorter or longer than 10 minutes based on traffic patterns and service criticality. Use shorter periods for high-traffic, critical functions to catch issues more rapidly. - Notification Frequency: Consider the frequency of this alert to optimize the balance between responsiveness and noise. Adjust according to the criticality of the service’s uninterrupted operation. Action: If this alert triggers, investigate the source of the empty receive attempts by reviewing application logs and metrics. Verify that messages are being produced and delivered to the queue at expected rates. Assess and optimize the polling frequency and configuration of consuming applications. Check and adjust the visibility timeout and message retention settings if necessary. Monitor network performance to ensure reliable message delivery.

This alert is designed to monitor and detect when there is a backlog of messages waiting to be processed in the SQS queue. It ensures that messages are being consumed in a timely manner and helps identify potential issues with consuming applications or message processing logic. Visible messages are those available for retrieval from the queue. A high number of visible messages may indicate inefficiencies in message processing or a backlog building up in the queue. An alert triggers if the number of visible messages exceeds 2,000 within a 10-minute window. Customization Guidance: - Threshold: The default threshold is set to trigger an alert if the number of visible messages exceeds 2,000 within a 10-minute window. Adjust this threshold based on the specific queue and expected load to better reflect operational norms and service requirements. - Monitoring Period: Adjust the monitoring period to shorter or longer than 10 minutes based on traffic patterns and service criticality. Use shorter periods for high-traffic, critical functions to catch issues more rapidly. - Notification Frequency: Consider the frequency of this alert to optimize the balance between responsiveness and noise. Adjust according to the criticality of the service’s uninterrupted operation. Action: If this alert triggers, investigate the performance and configuration of consuming applications. Check for any recent changes or issues in the message production pipeline. Ensure that consuming applications have sufficient resources and are appropriately scaled to handle the load. Review and optimize the message processing logic to increase efficiency. Monitor network performance and other external factors that might be affecting message delivery and processing.

This alert monitors and detects messages that have remained in the queue for an unusually long time. It ensures that messages are processed within the expected timeframe and helps identify potential issues with message processing delays or bottlenecks. A message remaining in the queue longer than expected can signal delays in message processing. An alert triggers if the age of the oldest message exceeds 1 hour for a continuous period of 10 minutes. Customization Guidance: - Threshold: The default threshold is set to trigger an alert if the age of the oldest message exceeds 1 hour for a period of 10 minutes. Adjust this threshold based on the specific queue and expected load to better reflect operational norms and service requirements. - Monitoring Period: Adjust the monitoring period to shorter or longer than 10 minutes based on traffic patterns and service criticality. Use shorter periods for high-traffic, critical functions to catch issues more rapidly. - Notification Frequency: Consider the frequency of this alert to optimize the balance between responsiveness and noise. Adjust according to the criticality of the service’s uninterrupted operation. Action: If this alert triggers, investigate the performance and configuration of the consuming applications. Check for any recent changes or issues in the message production and processing pipeline. Ensure that consuming applications have sufficient resources and are appropriately scaled to handle the load. Review and optimize the message processing logic to increase efficiency. Monitor network performance and other external factors that might affect message processing.