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_checkentries in themonitoringmetrics 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:
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† |
†For information about how to increase this limit, see Manage your quota using the Google Cloud console.
What's next
For information about uptime checks, see the following documents:
For information about synthetic monitors, see the following documents: