Cloud Monitoring and Uptime Checks

Uptime checks are a feature of Google Cloud's Operations Suite (formerly Stackdriver) that monitor the availability and responsiveness of your applications and resources. They allow you to verify that your services are reachable from outside the Google Cloud network, simulating user traffic. The primary purpose is to detect outages or performance degradation before they impact end users, enabling proactive remediation.

On the ACE exam, you must know how to create and configure uptime checks, understand the different check types (HTTP, HTTPS, TCP), interpret the results, and integrate them with alerting policies. Uptime checks are part of the broader Cloud Monitoring service, which also collects metrics, logs, and traces.

An uptime check is a periodic probe sent from Google Cloud's monitoring infrastructure to your resource. The probe originates from multiple geographic locations (called 'locations' in the console) to verify global reachability. The check can target:

For HTTP/HTTPS checks, the probe sends an HTTP GET request to the specified URL. It expects a response within a configurable timeout (default 10 seconds, max 30 seconds). A successful check requires a response status code in the 200-399 range (by default; you can customize accepted codes). For TCP checks, the probe attempts a TCP handshake on the specified port. If the handshake completes within the timeout, the check is successful.

Each check runs on a configurable interval (default 5 minutes, minimum 1 minute). The probe results are aggregated into a metric called uptime_check/check_passed (value 1 for pass, 0 for fail). Additionally, the latency of the check is recorded as uptime_check/check_latency.

Uptime checks can be configured via the Cloud Console, gcloud CLI, or API. Here are key gcloud commands:

# Create an HTTP uptime check
gcloud monitoring uptime create my-http-check \
    --resource-type=url \
    --url=https://example.com/health \
    --check-interval=5m \
    --timeout=10s \
    --locations=us-west1,europe-west1 \
    --failure-threshold=3 \
    --success-threshold=3 \
    --accepted-response-status-codes=200-399

# Create a TCP uptime check
gcloud monitoring uptime create my-tcp-check \
    --resource-type=instance \
    --instance=my-vm-instance \
    --port=80 \
    --check-interval=1m \
    --timeout=5s \
    --locations=us-central1

# List uptime checks
gcloud monitoring uptime list

# Describe an uptime check
gcloud monitoring uptime describe my-http-check

# Delete an uptime check
gcloud monitoring uptime delete my-http-check

To view uptime check metrics in Cloud Monitoring:

gcloud monitoring metrics list --filter='metric.type = "uptime_check/check_passed"'

Uptime checks integrate with: - Alerting Policies: You can create a policy that triggers when an uptime check fails. For example, if the metric uptime_check/check_passed is 0 for 5 minutes, send a notification. - Dashboards: Uptime check results can be displayed on custom dashboards using the Metrics Explorer. - Health Checks: Uptime checks are different from load balancer health checks. Load balancer health checks are internal and used for traffic routing, while uptime checks are external monitoring probes. - SLA Monitoring: Uptime checks are used to measure actual uptime against SLAs. You can set up alerts when uptime drops below a certain threshold.

A large e-commerce company runs a multi-region application on Google Kubernetes Engine (GKE) behind a global HTTP(S) load balancer. They need to ensure that the checkout endpoint is always responsive from different parts of the world. They create an HTTPS uptime check targeting https://shop.example.com/checkout/health with a 10-second timeout and a content match for the string 'healthy'. They select five locations: us-west1, us-east1, europe-west1, asia-east1, and australia-southeast1. The check interval is set to 1 minute for rapid detection. An alerting policy is configured to notify the on-call engineer via PagerDuty if the check fails for 3 consecutive intervals from any location. This setup catches regional DNS issues or backend failures quickly. In production, they observed that during a traffic spike, the checkout endpoint responded in 12 seconds, causing timeouts. They adjusted the timeout to 15 seconds and added a separate latency alert when response time exceeds 10 seconds.

A financial services firm has a critical internal application that is not publicly accessible. They cannot use standard uptime checks directly. Instead, they deploy a reverse proxy (e.g., NGINX) in a public subnet that forwards health check requests to the internal application. The proxy exposes a /health endpoint that returns 200 only if the internal app is healthy. They create an HTTPS uptime check targeting the proxy's public URL. The proxy also adds latency and error rate metrics. This approach allows them to monitor internal services without exposing them directly. A common misconfiguration is forgetting to update the proxy's health endpoint when the internal app's health check path changes, causing false positives.

A company uses both Google Cloud and AWS. They want to monitor the uptime of their AWS-hosted API from Google Cloud. They create an HTTP uptime check targeting the AWS API's public endpoint. This provides an independent verification of availability from a different cloud provider's network. They use this data to compare with AWS's reported uptime and to trigger failover to GCP if the API is down. A challenge is that the AWS API may block repeated probes from GCP IP ranges, so they whitelist the GCP monitoring IP ranges. They also set a higher failure threshold (5) to avoid false alarms due to transient network issues between clouds.