이 문서에서는 Cloud Monitoring이 합성 모니터에 제공하는 지원을 설명하며 이를 통해 서비스, 애플리케이션 웹페이지, API의 가용성, 일관성, 성능을 테스트할 수 있습니다.
합성 모니터는 시뮬레이션된 요청을 주기적으로 실행하고 요청이 성공했는지 여부를 기록하며 지연 시간과 같은 요청에 대한 추가 데이터를 기록합니다. 테스트 결과를 모니터링하는 알림 정책을 만들어 테스트가 실패할 때 알림을 받을 수 있습니다.
서비스와 애플리케이션을 테스트하려면 다음 접근 방법을 사용하면 됩니다.
업타임 체크를 사용하면 Google Cloud 에서 HTTP, HTTPS 또는 TCP 요청에 응답하는 애플리케이션을 주기적으로 쿼리할 수 있습니다. 업타임 체크는 공개 또는 비공개 엔드포인트를 테스트할 수 있으며 응답 데이터를 검증할 수 있습니다.
커스텀 및 Mocha 기반 합성 모니터를 사용하면 HTTP 또는 HTTPS 요청에 응답하는 애플리케이션을 테스트할 때 사용할 수 있는 테스트 모음을 배포할 수 있습니다.
이러한 합성 모니터를 만들려면 Cloud Monitoring에서 제공되는 커스텀 또는 Mocha 프레임워크로 시작한 후 테스트를 작성합니다. 이 프로젝트에서 Gemini Code Assist에 액세스할 수 있는 경우 테스트 코드를 생성하라는 프롬프트를 제공할 수 있습니다.
깨진 링크 검사기를 사용하면 Google Cloud 에서 주기적으로 URI를 테스트하고 해당 URI에서 찾은 구성 가능한 링크 수를 테스트할 수 있습니다.
다음 표에서는 업타임 체크 및 합성 모니터를 만드는 데 사용할 수 있는 도구를 보여줍니다.
Google Cloud 콘솔
Cloud Monitoring API
Terraform
클라이언트 라이브러리
업타임 체크
Y
Y
Y
Y
합성 모니터
Y
Y
Y
깨진 링크 검사기
Y
Y
Y
업타임 체크 정보
업타임 체크에는 두 가지 유형이 있습니다.
공개 업타임 체크는 전 세계 여러 위치에서 공개적으로 사용 가능한 URL 또는 Google Cloud 리소스에 요청을 실행합니다.
비공개 업타임 체크는 Google Cloud 리소스의 내부 IP 주소에 요청을 실행합니다. 비공개 업타임 체크는 비공개 네트워크를 통해 가상 머신(VM) 또는 L4 내부 부하 분산기(ILB)와 같은 리소스로 요청을 전송할 수 있습니다.
업타임 체크 대신 수행되는 요청은 일부 Google Cloud 리전에 남아 있는 체커로부터 시작됩니다. 업타임 체크를 만들 때 검사기의 리전을 지정합니다.
Google Cloud에서 제공하는 업타임 체크를 위한 요청-실행 시스템은 다음을 관리합니다.
구성된 검사기 실행
결과 검증
리소스가 응답하고 모든 업타임 체크 구성 요구사항이 충족되면 검사기에서 발행한 요청이 성공합니다. 그렇지 않으면 요청이 실패합니다. 개별 검사기의 쿼리는 스테이트리스(Stateless)입니다. 즉, 각 쿼리가 독립적인 작업입니다.
Google Cloud 콘솔을 사용하여 업타임 체크를 만드는 경우 검사가 실패하면 업타임 체크에서도 로그 항목을 작성하도록 구성할 수 있습니다.
ICMP 핑을 보내도록 공개 업타임 체크를 구성한 경우 핑이 실패하면 핑 결과가 Cloud Logging 로그에 기록됩니다. 자세한 내용은 ICMP 핑 사용을 참조하세요.
깨진 링크 검사기 및 기타 합성 모니터 정보
합성 모니터를 사용하면 테스트할 대상과 일련의 테스트를 정의할 수 있습니다.
예를 들어 애플리케이션의 로그인 페이지, 전자상거래 스토어의 결제 프로세스 또는 애플리케이션에서 타사 서비스에 수행하는 API 호출을 테스트할 수 있습니다.
합성 모니터를 만들 때는 Cloud Run을 기반으로 빌드된 2세대 Cloud Run 함수를 배포합니다.
함수는 Node.js로 작성되어야 하며 오픈소스 합성 SDK 프레임워크를 사용해야 합니다.
Cloud Monitoring에서 이 프레임워크를 배포하고 관리합니다.
[[["이해하기 쉬움","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-04-28(UTC)"],[],[],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)"]]
