Synthetic monitoring overview

This document describes the support Cloud Monitoring provides for synthetic monitors, which let you test the availability, consistency, and performance of your services, applications, web pages, and APIs. Synthetic monitors periodically issue simulated requests and then record whether those requests were successful, and they record additional data about the request such as the latency. You can be notified when a test fails by creating an alerting policy to monitor the test results.

Cloud Monitoring supports two different approaches to testing your services and applications:

  • Uptime checks, which are partially configurable synthetic monitors, let Google Cloud periodically query an application that responds to HTTP, HTTPS, or TCP requests.

  • Fully configurable synthetic monitors let you deploy a single-purpose 2nd gen Cloud Function, which is built on Cloud Run. You configure your Cloud Function to run your Node.js test script. Cloud Monitoring periodically executes your Cloud Function, and it collects metrics, logs, status, and other test results.

The following table lists the tools that you can use to create uptime checks and synthetic monitors:

Google Cloud console Cloud Monitoring API Terraform Client libraries
Uptime checks Y Y Y Y
Synthetic monitors Y Y Y

About uptime checks

There are two types of uptime checks:

  • Public uptime checks issue requests from multiple locations throughout the world to publicly available URLs or Google Cloud resources.
  • Private uptime checks issue requests to internal IP addresses of Google Cloud resources. Private uptime checks can send requests over a private network to resources like a virtual machine (VM) or an L4 internal load balancer (ILB).

The requests made on behalf of uptime checks originate from checkers that reside in several Google Cloud regions. When you create an uptime check, you specify the regions for the checkers.

The request-execution system for uptime checks, which is provided by Google Cloud, manages the following:

  • Execution of the configured checkers.
  • Validation of results.

    The request issued by a checker succeeds if the resource responds and any requirements of the uptime-check configuration are met. Otherwise, the request fails. The queries by individual checkers are stateless; that is, each query is an independent action.

  • Collecting and storing the results to uptime-check metrics.

    For more information about these metrics, see the uptime_check entries in the monitoring metrics table.

  • Writing log entries on failure.

    If you create your uptime check by using the Google Cloud console, then you can configure the uptime check to also write a log entry, when the check fails. If you've configured a public uptime check to send ICMP pings, then the results of those pings are written to Cloud Logging logs when the ping fails. For more information, see Use ICMP pings.

Monitor and observe uptime check results

You can observe the results of your uptime checks by viewing the Uptime checks page in the Google Cloud console:

Sample uptime checks overview.

To be notified when an uptime check fails, create an alerting policy by using the Google Cloud console or the Google Cloud CLI. If you create the alerting policy by using the options on the Uptime checks page, then most fields of the policy are populated for you.

Data regionality for uptime checks

Don't use uptime checks when you have set up Assured Workloads because you have data-residency or Impact Level 4 (IL4) requirements.

Cloud Monitoring doesn't guarantee that the data in the uptime check request is kept in a specific geographic location.

Pricing for uptime checks

For information about pricing, see the uptime-check row in the Cloud Monitoring pricing summary.

About synthetic monitors

Synthetic monitors let you define what you are going to test and a sequence of tests. For example, you can test the login page of your application, the checkout process of your ecommerce store, or the API calls that your application makes to third-party services.

When you create a synthetic monitor, you create a 2nd gen Cloud Function that executes code written in Node.js by using the open source Synthetics SDK framework. Cloud Monitoring distributes and manages this framework.

The request-execution system for synthetic monitors, which is provided by Google Cloud, manages the following:

  • Periodic execution of your Cloud Function.
  • Collecting and storing the results of each execution:

    • Success and failure information, such as the error message, error type, and line of code.
    • Execution time
    • Logs
    • Metrics

    For information about how to view execution results, see Explore synthetic monitor results.

Observe synthetic monitor results

You can observe the results of your synthetic monitors by viewing the Synthetic monitors page in the Google Cloud console.

To be notified when a synthetic monitor fails, create an alerting policy by using the Google Cloud console or the Google Cloud CLI. If you create the alerting policy by using the options on the Synthetic monitors page, then most fields of the policy are populated for you.

Data regionality for synthetic monitors

You can specify the region where your Cloud Function is deployed. However, your function can be invoked from any region that is supported by the uptime check servers. This behavior isn't configurable.

Don't use synthetic monitors when you have set up Assured Workloads because you have data-residency or Impact Level 4 (IL4) requirements.

Pricing for synthetic monitors

For information about pricing, see the synthetic monitor row in the Cloud Monitoring pricing summary.

Limits

The following limits apply to your use of synthetic monitors:

Category Value
Uptime checks per metrics scope * 100
Maximum number of ICMP pings per public uptime check 3
Synthetic monitors per metrics scope 100
*This limit applies to the number of uptime-check configurations. Each uptime-check configuration includes the time interval between testing the status of the specified resource.
For information about how to increase this limit, see Manage your quota using the Google Cloud console.

What's next