This alert triggers when the available disk storage in a Google Bigtable instance falls below 2GB. Low disk space can result in system slowdowns or inability to store additional data, leading to potential data loss or service interruptions. Customization Guidance: Threshold: The alert is set to trigger when available disk space drops below 2GB. This can be modified based on the size of your dataset and the typical growth rate. Instance Monitoring: Monitor instances where disk storage usage is growing rapidly, or where disk space is more critical for performance. Notification Frequency: Alerts should trigger immediately when disk space falls below the threshold to prevent storage exhaustion. Action: Investigate disk space usage to determine if unnecessary data can be cleared or archived. If the instance requires more storage, consider resizing the cluster or increasing the storage capacity to accommodate growth.

This alert triggers when the ratio of server errors in a Google Bigtable cluster surpasses a set threshold for any error code. A high error rate can signal issues within the Bigtable instance or problematic queries leading to system failures. Customization Guidance: Threshold: Configure the alert to trigger if the error rate exceeds 5 over a specified time period. Adjust based on the acceptable error rate for your application. Error Code Specificity: Consider focusing on critical error codes that are more impactful to your operations. Notification Frequency: The alert should activate as soon as the error rate exceeds the threshold to ensure rapid response. Action: Review logs to identify error patterns. Address possible causes like query errors, resource limitations, or infrastructure issues. Optimize queries or enhance resources as needed.

This alert triggers when the CPU usage of the hottest node in a Google Bigtable cluster exceeds a defined threshold. High CPU usage on a single node can indicate workload imbalances, which may affect overall cluster performance. Customization Guidance: Threshold: Set a CPU usage threshold appropriate to your cluster’s capacity. For instance, you might trigger the alert if CPU usage exceeds 80% on the hottest node. Instance Monitoring: Focus on specific instances where workloads are more intensive or critical. Notification Frequency: Alerts should trigger once CPU usage exceeds the threshold to allow for prompt investigation and load adjustments. Action: Examine workload distribution and balance it across nodes. If a node consistently has high CPU usage, consider redistributing workloads or adding more nodes to handle demand effectively.