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.

To test your services and applications, you can use any of the following approaches:

  • Uptime checks let Google Cloud periodically query an application that responds to HTTP, HTTPS, or TCP requests. Uptime checks can test public or private endpoints, and they can validate the response data.

  • Custom and Mocha-based synthetic monitors let you deploy a suite of tests that you can use to test an application that responds to HTTP or HTTPS requests. To create these synthetic monitors, you start with a framework provided by Cloud Monitoring—custom or Mocha—and then write your tests. If you have access to Gemini Code Assist in this project, then you can provide a prompt to generate your test code.

  • Broken-link checkers let Google Cloud periodically test a URI, and test a configurable number of links found at that URI.

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
Broken-link checkers 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.

About broken-link checkers and other 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 deploy a 2nd gen Cloud Run function which is built on Cloud Run. Your function must be written in Node.js and rely on the open source Synthetics SDK framework. Cloud Monitoring distributes and manages this framework.

Cloud Monitoring supports the following types of synthetic monitors:

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

  • Periodic execution of your Cloud Run 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.

Monitor and view results

You can observe the results of your synthetic monitors and uptime checks in the Google Cloud console:

  • For synthetic monitors, go to the Synthetic monitors page.
  • For uptime checks, to to the Uptime checks page.

To be notified when a synthetic monitor or uptime check fails, create an alerting policy by using the Google Cloud console or the Google Cloud CLI.

Troubleshooting failures

To assist you with troubleshooting, the request headers and logged data includes the ID of the associated synthetic monitor or uptime check. For more information, see Troubleshoot synthetic monitors or uptime checks.

Data regionality

Don't use synthetic monitors or 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.

For synthetic monitors that depend on a Cloud Run function, you can specify the region where your Cloud Run 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.

Pricing

In general, Cloud Monitoring system metrics are free, and metrics from external systems, agents, or applications are not. Billable metrics are billed by either the number of bytes or the number of samples ingested.

For more information about Cloud Monitoring pricing, see the following documents:

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