[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-09-04 (世界標準時間)。"],[],[],null,["# Synthetic monitoring overview\n\nThis document describes the support Cloud Monitoring provides for\nsynthetic monitors, which let you test the availability, consistency, and\nperformance of your services, applications, web pages, and APIs.\nSynthetic monitors periodically issue simulated requests and then record whether\nthose requests were successful, and they record additional data about the\nrequest such as the latency. You can be notified when\na test fails by creating an [alerting policy](/monitoring/alerts) to monitor the\ntest results.\n\nTo test your services and applications, you can use any of the\nfollowing approaches:\n\n- Uptime checks let Google Cloud periodically query an\n application that responds to HTTP, HTTPS, or TCP requests. Uptime checks\n can test public or private endpoints, and they can validate the response\n data.\n\n- Custom and Mocha-based synthetic monitors let you deploy a suite of tests that\n you can use to test an application that responds to HTTP or HTTPS requests.\n To create these synthetic monitors, you start with a framework provided by\n Cloud Monitoring---custom or Mocha---and\n then write your tests. If you have access to Gemini Code Assist in\n this project, then you can provide a prompt to generate your test code.\n\n- Broken-link checkers let Google Cloud periodically test a\n URI, and test a configurable number of links found at that URI.\n\nThe following table lists the tools that you can use to create\nuptime checks and synthetic monitors:\n\n\u003cbr /\u003e\n\nAbout uptime checks\n-------------------\n\nThere are two types of uptime checks:\n\n- [Public uptime checks](/monitoring/uptime-checks) issue requests from multiple locations throughout the world to *publicly available* URLs or Google Cloud resources.\n- [Private uptime checks](/monitoring/uptime-checks/private-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).\n\nThe requests made on behalf of uptime checks originate from *checkers* that\nreside in several Google Cloud regions. When you create an\nuptime check, you specify the regions for the checkers.\n\nThe request-execution system for uptime checks, which is provided by\nGoogle Cloud, manages the following:\n\n- Execution of the configured checkers.\n- Validation of results.\n\n The request issued by a checker succeeds if the resource responds and any\n requirements of the uptime-check configuration are met. Otherwise, the\n request fails. The queries by individual checkers are stateless; that is,\n each query is an independent action.\n- Collecting and storing the results to uptime-check metrics.\n\n For more information about these metrics, see the `uptime_check` entries in\n the [`monitoring` metrics table](/monitoring/api/metrics_gcp_i_o#monitoring/uptime_check/check_passed).\n- Writing log entries on failure.\n\n If you create your uptime check by using the Google Cloud console, then you can\n configure the uptime check to also write a log entry, when the check fails.\n If you've configured a public uptime check to send ICMP pings, then the\n results of those pings are written to Cloud Logging logs when the ping\n fails. For more information, see\n [Use ICMP pings](/monitoring/uptime-checks#ping).\n\nAbout broken-link checkers and other synthetic monitors\n-------------------------------------------------------\n\nSynthetic monitors let you define what you are\ngoing to test and a sequence of tests.\nFor example, you can test the login page of your application,\nthe checkout process of your ecommerce store, or the API calls that your\napplication makes to third-party services.\n\nWhen you create a synthetic monitor, you deploy a\n[2nd gen Cloud Run function](/functions/docs/concepts/overview)\nwhich is built on [Cloud Run](/run).\nYour function must be written in Node.js and rely on the open source\n[Synthetics SDK framework](https://github.com/GoogleCloudPlatform/synthetics-sdk-nodejs).\nCloud Monitoring distributes and manages this framework.\n\nCloud Monitoring supports the following types of synthetic monitors:\n\n- [Custom or Mocha-based synthetic monitors](/monitoring/synthetic-monitors/create) let you deploy a\n fully-configurable single-purpose Cloud Run function.\n\n- [Broken-link checkers](/monitoring/synthetic-monitors/broken-links) let you specify options,\n such as the origin URI, the number of links tested, and the number of retries,\n before deploying a preconfigured Cloud Run function.\n\nThe request-execution system for synthetic monitors, which is provided by\nGoogle Cloud, manages the following:\n\n- Periodic execution of your Cloud Run function.\n- Collecting and storing the results of each execution:\n\n - Success and failure information, such as the error message, error type, and line of code.\n - Execution time\n - Logs\n - Metrics\n\n For information about how to view execution results, see\n [Explore synthetic monitor results](/monitoring/synthetic-monitors/explore).\n\nMonitor and view results\n------------------------\n\nYou can observe the results of your synthetic monitors and uptime checks\nin the Google Cloud console:\n\n- For synthetic monitors, go to the **Synthetic monitors** page.\n- For uptime checks, to to the **Uptime checks** page.\n\nTo be notified when a synthetic monitor or uptime check fails, create an\n[alerting policy](/monitoring/alerts) by using the\nGoogle Cloud console or the Google Cloud CLI.\n| **Tip:** If you create the alerting policy from the details page of a synthetic monitor or an uptime check, then most of the fields of the alerting policy are preconfigured.\n\nTroubleshooting failures\n------------------------\n\nTo assist you with troubleshooting, the request headers and logged\ndata includes the ID of the associated synthetic monitor or uptime check.\nFor more information,\nsee [Troubleshoot synthetic monitors or uptime checks](/monitoring/uptime-checks/troubleshoot).\n\nData regionality\n----------------\n\nDon't use synthetic monitors or uptime checks when you have set up\n[Assured Workloads](/assured-workloads) because you have\ndata-residency or [Impact Level 4 (IL4)](/security/compliance/disa)\nrequirements.\n\nCloud Monitoring doesn't guarantee that the data in the uptime check request\nis kept in a specific geographic location.\n\nFor synthetic monitors that depend on a Cloud Run function, you can\nspecify the region where your Cloud Run function is deployed.\nHowever, your function can be invoked from any region that is supported\nby the uptime check servers. This behavior isn't configurable.\n\nPricing\n-------\n\nIn general, Cloud Monitoring system metrics are free, and metrics\nfrom external systems, agents, or applications are not. Billable metrics are\nbilled by either the number of bytes or the number of samples ingested.\n\nFor more information, see the Cloud Monitoring sections of the [Google Cloud Observability pricing](https://cloud.google.com/stackdriver/pricing) page.\n\nLimits\n------\n\nThe following limits apply to your use of synthetic monitors:\n\n^\\*^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. \n^†^For information about how to increase this limit, see [Request a quota adjustment](/docs/quotas/view-manage#requesting_higher_quota). \n\nWhat's next\n-----------\n\n- For information about uptime checks, see the following documents:\n\n - [Create public uptime checks](/monitoring/uptime-checks)\n - [Create private uptime checks](/monitoring/uptime-checks/private-checks)\n - [Create alerting policies for uptime checks](/monitoring/uptime-checks/uptime-alerting-policies)\n - [List uptime-check server IP addresses](/monitoring/uptime-checks/using-uptime-checks)\n- For information about synthetic monitors, see the following documents:\n\n - [Create a synthetic monitor](/monitoring/synthetic-monitors/create)\n - [Create a broken-link checker](/monitoring/synthetic-monitors/broken-links)\n - [Manage synthetic monitors](/monitoring/synthetic-monitors/manage)\n - [Explore synthetic monitor results](/monitoring/synthetic-monitors/explore)"]]
