This alert detects high latency in publishing messages to Google Cloud Pub/Sub topics. The alert is activated when the sum of publish request latencies exceeds 100 milliseconds for a continuous period of 5 minutes. Customization Guidance: Default Threshold: The alert is configured to trigger if the publish request latency exceeds 100 milliseconds over 5 minutes. Adjustment: Depending on your specific application requirements and historical data, you may need to adjust this threshold. Applications with higher tolerance for latency can use a higher threshold, while critical applications with low latency requirements may need a lower threshold. Topic and Project Specificity: Topic Relevance: Tailor the alert to monitor latency for different Pub/Sub topics based on their roles in your infrastructure. Critical topics that handle time-sensitive data may require stricter thresholds. Project Specificity: Customize alerts per project, especially if you manage multiple projects with varying latency sensitivities. High-stakes projects may necessitate more stringent monitoring compared to less critical ones. Notification Frequency: Alert Frequency: Consider the frequency of this alert to balance responsiveness with alert fatigue. Adjust according to the criticality of the applications and data flows supported by the Pub/Sub topics. Tiered Notifications: Implement different notification frequencies for varying severity levels. More critical breaches should trigger immediate notifications, while less critical ones can trigger less frequently. Action: Immediate Steps: Upon triggering, immediate actions include reviewing recent logs for the affected topics, analyzing the causes of increased latency, and ensuring the Pub/Sub configuration is optimized. Mitigation: To mitigate issues, you may need to optimize the publisher application or investigate network conditions affecting latency. Ensuring that your Pub/Sub setup, including quotas and scaling settings, is adequate for your load is also crucial.

This alert monitors the number of messages in Pub/Sub snapshots. It is activated when the count of snapshot messages exceeds 1000 within a continuous 5-minute period. Customization Guidance: Default Threshold: The alert triggers if the count of messages in Pub/Sub snapshots exceeds 1000 messages over a 5-minute window. Adjustment: Depending on the specific needs of your application and historical data, you may need to adjust this threshold. Applications with lower tolerance for large message backlogs may need a lower threshold, while others with more tolerance may need a higher threshold. Snapshot Relevance: Customize alerts based on the importance of different snapshots. Critical snapshots that must be processed quickly may require stricter monitoring. Project Specificity: Tailor alerts for each project, especially if you manage multiple projects with different performance and data retention needs. Alert Frequency: Balance between timely notifications and reducing alert fatigue. Adjust based on the importance of the snapshots and the applications they support. Tiered Notifications: Implement a tiered notification system where critical breaches trigger immediate alerts, while less critical ones can trigger less frequently. Action: Immediate Steps: Upon triggering, immediate actions include reviewing recent logs of the snapshots, checking for causes of message backlog, and ensuring the Pub/Sub snapshot configuration is optimized. Mitigation: To resolve issues, you may need to optimize the publisher or subscriber applications or adjust your Pub/Sub setup to handle message backlogs effectively.

This alert monitors the age of the oldest unacknowledged message in Google Cloud Pub/Sub subscriptions. It is activated when the age of the oldest unacknowledged message exceeds 5 minutes for any subscription. Customization Guidance: Default Threshold: The alert triggers if the age of the oldest unacknowledged message in a Pub/Sub subscription exceeds 5 minutes. Adjustment: Depending on your application's specific requirements and message processing capacity, you may need to adjust this threshold. Applications with stringent real-time processing needs may require a lower threshold, while those with more relaxed requirements may tolerate a higher threshold. Subscription Relevance: Customize alerts for different subscriptions based on their importance and role in your infrastructure. Critical subscriptions that require timely processing may need more stringent monitoring. Project Specificity: Tailor alerts per project, especially if you manage multiple projects with varying levels of criticality and message processing needs. Alert Frequency: Balance between timely alerts and reducing alert fatigue. Adjust the frequency based on the importance of the Pub/Sub subscriptions and the applications they support. Tiered Notifications: Implement a tiered notification system, where critical breaches trigger immediate alerts, while less critical ones may trigger less frequently. Action: Immediate Steps: Upon triggering, immediate actions include reviewing recent logs for the affected subscriptions, checking for message processing delays, and ensuring the Pub/Sub configuration is optimized. Mitigation: To resolve issues, consider optimizing the subscriber application or adjusting your Pub/Sub setup to handle message backlogs more effectively.