이 페이지는 Cloud Translation API를 통해 번역되었습니다.

합성 모니터 만들기

이 문서에서는 서비스, 애플리케이션, 웹페이지, API의 가용성, 일관성, 성능을 테스트하도록 합성 모니터를 만드는 방법을 설명합니다. 애플리케이션 테스트를 제공합니다. 합성 모니터에서 해당 스크립트를 실행하고 테스트 결과 및 지연 시간과 같은 추가 데이터를 기록합니다. 테스트가 실패할 때 알림을 받으려면 알림 정책을 구성하여 테스트 결과를 모니터링할 수 있습니다.

합성 모니터 정보

합성 모니터는 Cloud Run에 배포되는 단일 목적 2세대 Cloud Run 함수를 주기적으로 실행합니다. 합성 모니터를 만들 때 Node.js로 작성해야 하는 Cloud Run 함수와 실행 빈도를 정의합니다. 예를 들어 Puppeteer를 사용하여 웹페이지와 상호작용하도록 Cloud Run 함수를 구성할 수 있습니다. 또한 Axios 모듈을 사용하여 API와 상호작용하도록 Cloud Run 함수를 구성할 수 있습니다. VPC 네트워크 내에 있는 리소스를 테스트할 수도 있습니다.

Cloud Run 함수를 만들려면 인라인 편집기를 사용하거나 ZIP 파일을 업로드하면 됩니다. 인라인 편집기를 사용하려면 제공된 스켈레톤으로 시작하면 됩니다. 합성 모니터를 만든 후에는 Cloud Monitoring에서 주기적인 Cloud Run 함수 실행을 예약하는 예약 시스템을 사용합니다. Cloud Run 함수가 있는 리전을 지정하는 동안 실행을 트리거하는 명령어는 업타임 체크 서버에서 지원하는 모든 리전에서 시작할 수 있습니다. 자세한 내용은 업타임 체크 서버 IP 주소 나열을 참조하세요.

테스트 실패 시 알림을 받도록 알림 정책을 만들 수 있습니다.

Google Cloud 콘솔을 사용하여 합성 모니터를 만들 때 기본 동작은 알림 정책을 만드는 것입니다. 알림 채널을 제공하세요. 기본 알림 정책은 연속 테스트 실패가 2개 이상일 때 알림을 제공하도록 구성됩니다.
Cloud Monitoring API를 사용하여 합성 모니터를 만드는 경우 Cloud Run 함수가 실행 중인 Cloud Run 리소스의 uptime_check/check_passed 측정항목 유형을 모니터링하는 알림 정책을 만들어야 합니다.

실행 빈도 고려사항

Cloud Run 함수가 실행되는 빈도를 구성합니다. 실행 빈도를 확인하려면 서비스의 서비스 수준 목표(SLO)를 고려하세요. 잠재적인 SLO 위반사항을 포착하려면 테스트를 자주 실행해야 합니다. 하지만 서비스 SLO만 고려되는 것은 아닙니다. 실행 비율이 서비스 및 비용에 대한 부하로 어떻게 전환되는지도 고려해야 합니다. 실행할 때마다 서비스 부하가 제공되므로 Cloud Run 함수를 자주 실행할수록 서비스에 더 많은 부하가 적용됩니다. 참고로 업타임 체크의 기본 실행 간격은 1분입니다.

실행 빈도는 테스트가 실패할 때 알림을 받을 속도도 결정합니다. Monitoring에서 이슈를 열고 순차적으로 두 번째 테스트가 실패한 후에 알림을 보냅니다. 예를 들어 실행 빈도가 5분이면 테스트가 2번 실패하기까지 10분 정도 걸릴 수 있습니다. 두 번째 테스트 실패 후 알림이 전송됩니다.

Cloud Run 함수 샘플 코드

템플릿 및 샘플은 합성 모니터 샘플을 참조하세요. 이 샘플을 Cloud Run 함수의 시작점으로 사용할 수 있습니다. 숙련된 개발자라면 Gemini를 사용하여 합성 모니터용 코드를 생성하여 개발 시간을 단축시키는 것이 좋습니다. Gemini를 사용하여 코드를 생성하는 기능은 공개 미리보기 버전입니다.

Google Cloud 콘솔을 사용하여 합성 모니터를 만들 때 선택할 수 있는 일반 템플릿은 아웃바운드 HTTP 요청의 trace 및 로그 데이터를 수집하도록 구성됩니다. 이 솔루션은 OpenTelemetry auto-Instrumentation-node 모듈과 winston logger를 활용합니다. 오픈소스 제품에 대한 종속 항목으로 인해 trace 및 로그 데이터 구조가 변경될 수 있습니다. 따라서 수집된 trace 및 로그 데이터는 디버깅 목적으로만 사용해야 합니다.

아웃바운드 HTTP 요청의 trace 및 로그 데이터를 수집하는 고유한 방법을 구현할 수 있습니다. 커스텀 방식의 예시는 SyntheticAutoInstrumentation 클래스를 참조하세요.

Cloud Run 함수 구성

Cloud Run 함수를 구성할 때 런타임, 빌드, 연결, 보안 설정을 지정하거나 기본값을 수락해야 합니다.

할당된 메모리의 기본값이 부족할 수 있습니다. 이 필드를 최소 2GiB 이상으로 설정하는 것이 좋습니다.
Cloud Run 함수의 인바운드 데이터 전송 설정 기본값은 모든 트래픽 허용입니다. 이 설정이나 더욱 제한적인 설정을 사용할 수 있습니다.

모든 트래픽을 허용하면 네트워크 수준에서 수행되는 Cloud Run 함수가 수행하는 첫 번째 검증 단계가 항상 성공합니다. 두 번째 검증 단계에서는 호출자에게 Cloud Run 함수 실행 권한이 부여되었는지 여부를 확인합니다. 승인은 호출자의 Identity and Access Management(IAM) 역할에 따라 달라집니다. 기본적으로 Cloud Monitoring에는 Cloud Run 함수를 실행할 수 있는 권한이 부여됩니다. 인바운드 데이터 전송 설정을 보거나 수정하는 방법은 인그레스 설정을 참조하세요.

Cloud Run 함수 제한사항

Cloud Run 함수 이름에는 밑줄이 포함되면 안 됩니다.
일반 템플릿을 사용할 경우에만 아웃바운드 HTTP 요청의 trace 및 로그 데이터를 수집할 수 있습니다.
HTTP 함수만 지원됩니다. Google Cloud 콘솔을 사용하여 합성 모니터를 만드는 경우 URL을 쿼리하는 기본 함수가 제공됩니다. 수정할 수 있는 기본 함수의 소스는 generic-synthetic-nodejs Git 저장소에서 사용할 수 있습니다.

HTTP 함수에 대한 자세한 내용은 HTTP 함수 작성을 참조하세요.
API를 사용하는 경우 배포 명령어에서 Cloud Run 함수가 2세대임을 지정해야 합니다. Google Cloud 콘솔을 사용하는 경우 배포가 자동으로 처리됩니다. 자세한 내용은 Cloud Run 함수 배포를 참조하세요.
런타임 환경은 Node.js로 제한됩니다. 자세한 내용은 노드를 참조하세요. 지원되는 Node.js 버전은 12, 14, 16, 18, 20입니다.

합성 모니터에서 수집한 데이터

이 섹션에서는 합성 모니터를 위해 수집되는 데이터를 설명합니다. 실행 결과를 보는 방법은 합성 모니터 결과 살펴보기를 참조하세요.

실행 기록

각 합성 모니터의 경우 실행 결과 기록이 수집됩니다. 이 데이터에는 다음이 포함됩니다.

시간 경과에 따라 실행 성공이나 실패를 기록하는 시계열입니다.
코드 실행 기간을 기록하는 시계열입니다. 함수 실행 시간은 기록되지 않습니다. 지연 시간 데이터는 Cloud Run 함수가 실행되는 Cloud Run 리소스의 uptime_check/request_latency 시계열로 기록됩니다. 이 데이터의 차트는 합성 모니터 세부정보 페이지에 제공됩니다.
테스트 및 실패 세부정보와 같은 합성 모니터 실행에 대한 정보가 포함된 로그입니다. 사용 가능한 로그는 Cloud Run 함수에 따라 다릅니다. 예를 들어 Mocha 템플릿을 사용하는 경우 로그에 테스트 성공 여부 및 테스트 기간과 관련된 정보가 포함됩니다. 스택 트레이스가 포함된 경우 실패한 코드 줄, 오류 유형, 오류 메시지가 나열됩니다.
아웃바운드 HTTP 요청의 trace 및 로그(선택사항) 이 데이터를 수집하는 방법에 대한 자세한 내용은 요청 지연 시간을 참조하세요.

Cloud Run 함수 측정항목 및 로그

Cloud Run 함수의 측정항목 및 로그입니다. Cloud Run 함수에서 수집되는 이 데이터에는 초당 실행 횟수, 실행 시간, 함수의 메모리 사용률에 대한 정보가 포함됩니다.

요청 지연 시간

합성 모니터에서 생성된 HTTP 요청의 지연 시간 데이터가 Cloud Trace에 의해 자동으로 수집 및 저장됩니다.

합성 모니터에서 생성된 아웃바운드 HTTP 요청의 trace, 로그, 지연 시간 데이터를 수집하려면 일반 템플릿을 사용해야 합니다. 자세한 내용은 합성 모니터 샘플을 참조하세요.

시작하기 전에

Google Cloud 콘솔을 사용하여 합성 모니터를 보고 수정하는 데 필요한 권한을 얻으려면 관리자에게 프로젝트에 대한 다음 IAM 역할을 부여해 달라고 요청하세요.
- 모니터링 편집자(roles/monitoring.editor)
- Cloud Functions 개발자(roles/cloudfunctions.developer)
역할 부여에 대한 자세한 내용은 액세스 관리를 참조하세요.

커스텀 역할이나 다른 사전 정의된 역할을 통해 필요한 권한을 얻을 수도 있습니다.
Enable the Cloud Monitoring API, Artifact Registry API, Cloud Build API, Cloud Functions API, Cloud Logging API, Pub/Sub API, and Cloud Run Admin API APIs.
Enable the APIs
Google Cloud 프로젝트에 기본 Compute Engine 서비스 계정이 포함되어 있는지 확인합니다. 이 서비스 계정은 Compute Engine API를 사용 설정할 때 생성되며 이름은 12345-compute@developer.gserviceaccount.com과 비슷합니다.

Google Cloud 콘솔에서 서비스 계정 페이지로 이동합니다.
서비스 계정으로 이동

검색창을 사용하여 이 페이지를 찾은 경우 부제목이 IAM 및 관리자인 결과를 선택합니다.

기본 Compute Engine 서비스 계정이 없는 경우 서비스 계정 만들기를 클릭하고 대화상자를 완료합니다.
기본 Compute Engine 서비스 계정이나 직접 만든 서비스 계정에 편집자 역할(roles/editor)이 부여되었는지 확인합니다.

서비스 계정에 부여된 역할을 보려면 다음 단계를 따르세요.
1. Google Cloud 콘솔에서 IAM 페이지로 이동합니다.
  IAM으로 이동합니다.
  
  검색창을 사용하여 이 페이지를 찾은 경우 부제목이 IAM 및 관리자인 결과를 선택합니다.
2. Google 제공 역할 부여 포함을 선택합니다.
3. 합성 모니터에서 사용하는 서비스 계정이 나열되지 않거나 Cloud Trace 에이전트(roles/cloudtrace.agent) 역할의 권한이 포함된 역할이 부여되지 않은 경우 서비스 계정에 이 역할을 부여합니다.
알림을 수신하는 데 사용할 알림 채널을 구성합니다. 여러 유형의 알림 채널을 만드는 것이 좋습니다. 자세한 내용은 알림 채널 만들기 및 관리 및 API를 통한 알림 채널 만들기 및 관리를 참조하세요.

합성 모니터 만들기

콘솔

Google Cloud 콘솔을 사용하여 합성 모니터를 만들면 새 Cloud Run 함수(2세대)가 배포되고 Cloud Run 함수 모니터가 생성됩니다. 기존 Cloud Run 함수를 모니터링하는 합성 모니터를 만들 수 없습니다.

필요한 API를 사용 설정했고 프로젝트에 기본 Compute Engine 서비스 계정이 포함되어 있으며 이 계정에 편집자(roles/editor) 역할이 부여되었는지 확인합니다. 자세한 내용은 시작하기 전에를 참조하세요.
Google Cloud 콘솔에서 합성 모니터링 페이지로 이동합니다.
합성 모니터링으로 이동

검색창을 사용하여 이 페이지를 찾은 경우 부제목이 Monitoring인 결과를 선택합니다.
합성 모니터 만들기를 선택합니다.
Cloud Run 함수의 템플릿을 선택합니다.
- 커스텀 합성 모니터: 아웃바운드 HTTP 요청의 로그 데이터 또는 trace 데이터를 수집하려면 이 템플릿을 사용합니다.
- Mocha 합성 모니터: Mocha 테스트 모음을 작성할 때 이 템플릿을 사용합니다.
- 깨진 링크 검사기: URI와 해당 URI에 있는 구성 가능한 링크 수를 테스트하려면 이 템플릿을 사용합니다. 이 검사기의 필드에 대한 자세한 내용은 깨진 링크 검사기 만들기를 참조하세요.
모니터 이름을 입력합니다.
(선택사항) 응답 제한 시간, 체크 빈도를 업데이트하고 사용자 정의 라벨을 추가합니다.
다음 중 하나를 수행합니다.
- 이 프로젝트의 Gemini Code Assist에 대한 액세스 권한이 있고 코드 작성에 도움이 필요한 경우 코딩 도우미를 클릭합니다. 이 기능은 공개 미리보기 버전에 있습니다. 프롬프트는 합성 모니터용 프롬프트 작성 알아보기를 참조하세요.
  
  코드에 만족하면 Cloud 함수에 삽입을 클릭합니다.
- 함수 만들기를 클릭합니다.
Cloud Run 함수 대화상자에서 다음을 수행합니다.
1. 표시 이름을 입력하고 리전을 선택합니다. 이름은 리전 내에서 고유해야 합니다.
  
  참고: Cloud Run 함수 이름에 밑줄을 포함하지 마세요.
2. 런타임, 빌드, 연결, 보안 설정 섹션에서 다음을 수행합니다.
  - 기본 설정을 검토하고 필요에 따라 업데이트합니다.
    
    참고: 할당된 메모리, CPU, 보안의 기본 설정이 충분하지 않을 수 있습니다. 메모리를 최소 2GiB 이상으로 설정하는 것이 좋습니다.
  - 런타임 서비스 계정 필드에서 서비스 계정을 선택합니다.
3. 생성된 코드를 수정하거나 Cloud Run 함수의 코드를 작성하거나 업로드합니다.
  - 생성된 코드를 수정하려면 자체 코드를 입력하거나 기본 샘플 함수를 로드하고 인라인 편집기를 선택합니다. 이전에 선택한 템플릿에 종속된 샘플 함수에서 특정 URL로 요청을 전송합니다. 기본 함수를 수정할 수 있습니다.
  - 로컬 시스템에서 ZIP 파일을 로드하려면 ZIP 업로드를 선택합니다.
    
    로컬 시스템에서 ZIP 파일을 업로드하는 경우 ZIP 파일의 Cloud Storage 버킷도 지정해야 합니다. 적절한 Cloud Storage 버킷이 없으면 버킷을 만듭니다.
    
    참고: 새 스토리지 버킷을 만들면 버킷이 즉시 열리고 No objects found 메시지가 표시되며 옵션이 선택되거나 취소됩니다. 취소를 클릭하여 함수 만들기 대화상자로 돌아갑니다. 다음으로 찾아보기를 선택한 후 대상 버킷에 Cloud Storage 버킷을 선택합니다.
  - Cloud Storage에서 ZIP 파일을 로드하려면 Cloud Storage의 ZIP을 선택하고 스토리지 버킷을 선택한 후 로드할 ZIP 파일을 선택합니다.
    
    Google Cloud 콘솔의 Cloud Run 함수 페이지를 사용하여 Cloud Run 함수를 만들 수도 있습니다. Cloud Run 함수의 복사본을 모니터링하는 합성 모니터를 만들려면 소스 탭으로 이동하고 zip 다운로드를 클릭합니다. 그러면 ZIP 파일을 업로드할 수 있습니다.
4. 함수 적용을 클릭합니다.
알림 정책을 구성합니다.
1. (선택사항) 알림을 보내기 전에 알림 정책 이름과 실패 기간을 업데이트합니다.
2. 알림 채널을 추가합니다.
만들기를 클릭합니다.

정의한 Cloud Run 함수가 2세대로 빌드 및 배포되고 합성 모니터가 생성됩니다.

gcloud

Google Cloud CLI 또는 Cloud Monitoring API를 사용하여 합성 모니터를 만들 때 함수 이름을 API 호출에 전달합니다. 따라서 기존 Cloud Run 함수를 모니터링하는 합성 모니터만 만들 수 있습니다.

필요한 API를 사용 설정했고 프로젝트에 기본 Compute Engine 서비스 계정이 포함되어 있으며 이 계정에 편집자(roles/editor) 역할이 부여되었는지 확인합니다. 자세한 내용은 시작하기 전에를 참조하세요.
2세대 Cloud Run 함수를 작성하고 배포합니다.

예를 들어 Google Cloud/synthetics-sdk-nodejs 저장소에 synthetics-sdk-nodejs 샘플을 배포하려면 다음 안내를 따르세요.
1. 저장소를 클론하고 소스 코드 위치로 이동합니다.
```
git clone https://github.com/GoogleCloudPlatform/synthetics-sdk-nodejs.git
cd synthetics-sdk-nodejs/samples/generic-synthetic-nodejs
```
2. gcloud functions deploy 명령어를 사용하여 Cloud Run 함수를 배포합니다.
```
gcloud functions deploy FUNCTION_NAME \
--gen2 --region="us-west2" --source="." \
--entry-point=SyntheticFunction --trigger-http --runtime=nodejs18
```
  gcloud functions deploy 명령어에서 다음을 수행합니다.
  - FUNCTION_NAME 필드 값이 배포 리전 내에서 고유한지 확인합니다.
    
    참고: Cloud Run 함수 이름에 밑줄을 포함하지 마세요.
  - --gen2 플래그를 포함하고 배포 리전을 설정합니다.
  - 다음과 같이 --entry-point 필드를 설정합니다.
    - Mocha: SyntheticMochaSuite
    - Mocha가 아님: SyntheticFunction
  - --runtime 필드를 nodejs18로 설정합니다.
  - --trigger-http 플래그를 포함합니다.
  - 모든 트래픽을 허용하는 기본 설정을 사용하지 않으려면 --ingress-settings 필드를 설정합니다.
  Cloud Run 함수가 빌드한 후 Cloud Run 함수를 배포합니다. Google Cloud CLI 명령어 결과에는 정규화된 이름을 포함한 함수에 대한 정보가 포함됩니다.
```
name: projects/PROJECT_ID/locations/REGION/functions/FUNCTION_NAME
```
  함수 배포에 대한 자세한 내용은 Cloud Run 함수 배포를 참조하세요.
Google Cloud 프로젝트에서 Cloud Run 함수를 나열하려면 gcloud functions list 명령어를 사용합니다.
```
gcloud functions list
```
이 호출의 응답은 목록 항목이며 각 항목은 Cloud Run 함수를 나열합니다.
```
NAME: function-1
STATE: ACTIVE
TRIGGER: HTTP Trigger
REGION: us-west2
ENVIRONMENT: 2nd gen
```
특정 Cloud Run 함수의 정규화된 이름을 찾으려면 gcloud monitoring uptime describe 명령어를 실행합니다.
합성 모니터를 만들려면 gcloud monitoring uptime create 명령어를 실행합니다.
```
gcloud monitoring uptime create DISPLAY_NAME --synthetic-target=TARGET
```
위 명령어를 실행하기 전에 다음을 수행합니다.
- DISPLAY_NAME을 합성 모니터 이름으로 바꿉니다.
- TARGET을 Cloud Run 함수의 정규화된 이름으로 바꿉니다.
알림 정책을 만듭니다.

알림 정책 구성의 복잡성으로 인해 Google Cloud 콘솔에서 합성 모니터 페이지로 이동하고 옵션을 사용하여 알림 정책을 만드는 것이 좋습니다. 이 방식을 사용하면 대부분의 알림 정책 필드가 자동으로 채워집니다. Google Cloud 콘솔을 사용하여 알림 정책을 만들려면 합성 모니터 페이지에서 정책 만들기를 클릭합니다.

Google Cloud CLI 또는 Cloud Monitoring API를 사용하려면 다음과 같이 조건 필터를 구성합니다.
```
"filter": "resource.type = \"cloud_run_revision\" AND
            metric.type = \"monitoring.googleapis.com/uptime_check/check_passed\" AND
            metric.labels.check_id = \"CHECK_ID\"",
```
이 조건은 합성 모니터에서 작성한 uptime_check/check_passed 시계열을 모니터링합니다. CHECK_ID를 create 명령어의 응답 데이터에 포함된 합성 모니터 식별자로 바꿔야 합니다.

알림 정책을 만드는 방법에 대한 자세한 내용은 API를 사용하여 알림 정책 만들기를 참조하세요.

API

필요한 API를 사용 설정했고 프로젝트에 기본 Compute Engine 서비스 계정이 포함되어 있으며 이 계정에 편집자(roles/editor) 역할이 부여되었는지 확인합니다. 자세한 내용은 시작하기 전에를 참조하세요.
2세대 Cloud Run 함수를 작성하고 배포합니다.

예를 들어 Google Cloud/synthetics-sdk-nodejs 저장소에 synthetics-sdk-nodejs 샘플을 배포하려면 다음 안내를 따르세요.
1. 저장소를 클론하고 소스 코드 위치로 이동합니다.
```
git clone https://github.com/GoogleCloudPlatform/synthetics-sdk-nodejs.git
cd synthetics-sdk-nodejs/samples/generic-synthetic-nodejs
```
2. gcloud functions deploy 명령어를 사용하여 Cloud Run 함수를 배포합니다.
```
gcloud functions deploy FUNCTION_NAME \
--gen2 --region="us-west2" --source="." \
--entry-point=SyntheticFunction --trigger-http --runtime=nodejs18
```
  gcloud functions deploy 명령어에서 다음을 수행합니다.
  - FUNCTION_NAME 필드 값이 배포 리전 내에서 고유한지 확인합니다.
    
    참고: Cloud Run 함수 이름에 밑줄을 포함하지 마세요.
  - --gen2 플래그를 포함하고 배포 리전을 설정합니다.
  - 다음과 같이 --entry-point 필드를 설정합니다.
    - Mocha: SyntheticMochaSuite
    - Mocha가 아님: SyntheticFunction
  - --runtime 필드를 nodejs18로 설정합니다.
  - --trigger-http 플래그를 포함합니다.
  - 모든 트래픽을 허용하는 기본 설정을 사용하지 않으려면 --ingress-settings 필드를 설정합니다.
  Cloud Run 함수가 빌드한 후 Cloud Run 함수를 배포합니다. Google Cloud CLI 명령어 결과에는 정규화된 이름을 포함한 함수에 대한 정보가 포함됩니다.
```
name: projects/PROJECT_ID/locations/REGION/functions/FUNCTION_NAME
```
  함수 배포에 대한 자세한 내용은 Cloud Run 함수 배포를 참조하세요.
Google Cloud 프로젝트에서 Cloud Run 함수를 나열하려면 gcloud functions list 명령어를 사용합니다.
```
gcloud functions list
```
이 호출의 응답은 목록 항목이며 각 항목은 Cloud Run 함수를 나열합니다.
```
NAME: function-1
STATE: ACTIVE
TRIGGER: HTTP Trigger
REGION: us-west2
ENVIRONMENT: 2nd gen
```
특정 Cloud Run 함수의 정규화된 이름을 찾으려면 gcloud monitoring uptime describe 명령어를 실행합니다.
합성 모니터를 만들려면 다음을 수행합니다.
1. projects.uptimeCheckConfigs.create를 클릭하여 메서드의 API 참조 페이지를 엽니다.
2. 사용해 보기를 클릭하여 API 탐색기를 엽니다.
3. 다음 필드를 설정한 후 명령어를 실행합니다.
  - 상위 필드: projects/PROJECT_ID
  - 요청 본문에서 다음을 지정합니다.
    - displayName: 합성 모니터 표시 이름으로 설정합니다.
    - syntheticMonitor: Cloud Run 함수의 정규화된 이름으로 설정합니다.
  성공하면 API 호출 응답은 다음과 비슷합니다.
```
{
"name": "projects/myproject/uptimeCheckConfigs/17272586127463315332",
"displayName": "MyMonitor",
...
"syntheticMonitor": {
 "cloudFunctionV2": {
    "name": "projects/myproject/locations/us-west2/functions/function-1",
    "cloudRunRevision": {
    "type": "cloud_run_revision",
    "labels": {
       "project_id": "myproject",
       "configuration_name": "",
       "location": "us-west2",
       "revision_name": "",
       "service_name": "function-1"
    }
    }
 }
}
}
```
알림 정책을 만듭니다.

알림 정책 구성의 복잡성으로 인해 Google Cloud 콘솔에서 합성 모니터 페이지로 이동하고 옵션을 사용하여 알림 정책을 만드는 것이 좋습니다. 이 방식을 사용하면 대부분의 알림 정책 필드가 자동으로 채워집니다. Google Cloud 콘솔을 사용하여 알림 정책을 만들려면 합성 모니터 페이지에서 정책 만들기를 클릭합니다.

Google Cloud CLI 또는 Cloud Monitoring API를 사용하려면 다음과 같이 조건 필터를 구성합니다.
```
"filter": "resource.type = \"cloud_run_revision\" AND
            metric.type = \"monitoring.googleapis.com/uptime_check/check_passed\" AND
            metric.labels.check_id = \"CHECK_ID\"",
```
이 조건은 합성 모니터에서 작성한 uptime_check/check_passed 시계열을 모니터링합니다. CHECK_ID를 create 명령어의 응답 데이터에 포함된 합성 모니터 식별자로 바꿔야 합니다.

알림 정책을 만드는 방법에 대한 자세한 내용은 API를 사용하여 알림 정책 만들기를 참조하세요.

Terraform

Terraform 구성을 적용하거나 삭제하는 방법은 기본 Terraform 명령어를 참조하세요. 자세한 내용은 Terraform 제공업체 참고 문서를 확인하세요.

이러한 검사를 모니터링하는 합성 모니터 및 알림 정책을 만들려면 다음 안내를 따르세요.

필요한 API를 사용 설정했고 프로젝트에 기본 Compute Engine 서비스 계정이 포함되어 있으며 이 계정에 편집자(roles/editor) 역할이 부여되었는지 확인합니다. 자세한 내용은 시작하기 전에를 참조하세요.
Terraform 구성 파일을 수정하고 google_storage_bucket 리소스를 추가한 후 변경사항을 적용합니다.

다음 코드는 US 위치에서 Cloud Storage 버킷을 정의합니다.
```
resource "google_storage_bucket" "gcf_source" {
   name = "gcf-v2-source-9948673986912-us"
   location = "US"
   uniform_bucket_level_access = true
}
```
Terraform 구성 파일을 수정하고 google_storage_bucket_object 리소스를 추가한 후 변경사항을 적용합니다.

리소스는 버킷의 객체 이름과 로컬 시스템의 ZIP 파일 위치를 지정합니다. 예를 들어 다음 코드를 적용하면 example-function.zip 파일이 스토리지 버킷에 추가됩니다.
```
resource "google_storage_bucket_object" "object" {
   name = "example-function.zip"
   bucket = google_storage_bucket.gcf_source.name
   source = "generic-synthetic-node.js.zip"
}
```

Terraform 구성 파일을 수정하고 google_cloudfunctions2_function 리소스를 추가한 후 변경사항을 적용합니다.

google_cloudfunctions2_function 리소스가 Node.js 런타임과 합성 모니터에서 사용하는 진입점을 지정하는지 확인합니다. 예를 들어 다음 코드를 적용하면 sm-central1 함수가 배포됩니다.

resource "google_cloudfunctions2_function" "central1" {
   name = "sm-central1"
   location = "us-central1"

   build_config {
      runtime = "nodejs20"
      entry_point = "SyntheticFunction"
      source {
            storage_source {
               bucket = google_storage_bucket.gcf_source.name
               object = google_storage_bucket_object.object.name
            }
      }
   }

   service_config {
      max_instance_count = 1
      available_memory = "256Mi"
      timeout_seconds  = 60
   }
}

합성 모니터를 만들려면 Terraform 구성 파일을 수정하고 google_monitoring_uptime_check_config를 추가한 후 변경사항을 적용합니다.

이 리소스에 synthetic_monitor 블록을 지정합니다.

resource "google_monitoring_uptime_check_config" "synthetic" {
   display_name = "sm-central1"
   timeout = "30s"

   synthetic_monitor {
      cloud_function_v2 {
            name = google_cloudfunctions2_function.central1.id
      }
   }
}

선택사항: 알림 채널과 알림 정책을 만듭니다.

다음 단계에서는 Google Cloud 콘솔을 사용하여 알림 채널 및 알림 정책을 만듭니다. 이 방식을 사용하면 알림 정책은 합성 모니터에서 생성한 데이터만 모니터링합니다.
1. 알림 채널을 만들려면 다음을 수행합니다.
  1. Google Cloud 콘솔에서 알림 페이지로 이동합니다.
    알림으로 이동
    
    검색창을 사용하여 이 페이지를 찾은 경우 부제목이 Monitoring인 결과를 선택합니다.
  2. 알림 채널 관리를 선택합니다.
  3. 추가하려는 채널 유형으로 이동하고 추가를 클릭한 후 대화상자를 완료합니다.
2. 알림 정책을 만들려면 다음 안내를 따르세요.
  1. Google Cloud 콘솔에서 합성 모니터링 페이지로 이동합니다.
    합성 모니터링으로 이동
    
    검색창을 사용하여 이 페이지를 찾은 경우 부제목이 Monitoring인 결과를 선택합니다.
  2. 합성 모니터를 찾고 더보기를 선택한 후 알림 정책 추가를 선택합니다.
  3. 대화상자에서 알림 및 이름 섹션으로 이동하고 알림 채널을 펼친 후 선택합니다.
  4. 알림 정책 이름을 지정한 후 정책 만들기를 클릭합니다.

가격 책정

일반적으로 Cloud Monitoring 시스템 측정항목은 무료이고 외부 시스템, 에이전트, 애플리케이션의 측정항목은 무료가 아닙니다. 청구 가능한 측정항목은 수집된 바이트 수 또는 샘플 수에 따라 청구됩니다.

Cloud Monitoring 가격 책정에 대한 자세한 내용은 다음 문서를 참조하세요.

합성 모니터 문제 해결

이 섹션에서는 합성 모니터 문제를 해결하는 데 도움이 될 수 있는 정보를 제공합니다.

API를 사용 설정한 후의 오류 메시지

합성 모니터의 만들기 흐름을 엽니다. 그러면 API를 최소 하나 이상 사용 설정하라는 메시지가 표시됩니다. API를 사용 설정하면 다음과 유사한 메시지가 표시됩니다.

An error occurred during fetching available regions: Cloud Functions API has
not been used in project PROJECT_ID before or it is disabled.

오류 메시지에서는 API가 사용 설정되었는지 확인한 후 기다렸다가 작업을 다시 시도하도록 권장합니다.

API가 사용 설정되어 있는지 확인하려면 프로젝트의 API 및 서비스 페이지로 이동합니다.

API 및 서비스로 이동합니다.

API가 사용 설정된 것을 확인한 후에 만들기 흐름을 계속할 수 있습니다. API 사용 설정이 백엔드를 통해 전파되면 조건이 자동으로 확인됩니다.

아웃바운드 HTTP 요청이 추적되지 않음

출력 HTTP 요청에 대한 trace 데이터를 수집하도록 합성 모니터를 구성합니다. trace 데이터에는 다음 스크린샷과 유사하게 스팬이 하나만 표시됩니다.

하나의 trace만 표시하는 Cloud Trace

이 문제를 해결하려면 서비스 계정에 Cloud Trace 에이전트(roles/cloudtrace.agent) 역할을 부여했는지 확인합니다. 편집자(roles/editor) 역할만으로도 충분합니다.

서비스 계정에 부여된 역할을 보려면 다음 단계를 따르세요.

Google Cloud 콘솔에서 IAM 페이지로 이동합니다.
IAM으로 이동합니다.

검색창을 사용하여 이 페이지를 찾은 경우 부제목이 IAM 및 관리자인 결과를 선택합니다.
Google 제공 역할 부여 포함을 선택합니다.
합성 모니터에 사용되는 서비스 계정이 나열되지 않거나 Cloud Trace 에이전트(roles/cloudtrace.agent) 역할의 권한을 포함하는 역할이 부여되지 않은 경우 서비스 계정에 이 역할을 부여합니다.

서비스 계정 이름을 모르는 경우 탐색 메뉴에서 서비스 계정을 선택합니다.

진행 중 상태

합성 모니터 페이지에는 상태가 In progress인 합성 모니터가 나열됩니다. In progress 상태는 합성 모니터가 최근에 생성되었으며 표시할 데이터가 없거나 함수를 배포할 수 없음을 의미합니다.

함수 배포 실패 여부를 확인하려면 다음을 시도합니다.

Cloud Run 함수 이름에 밑줄이 포함되지 않았는지 확인합니다. 밑줄이 있으면 밑줄을 삭제하고 Cloud Run 함수를 다시 배포합니다.
합성 모니터의 합성 모니터 세부정보 페이지를 엽니다.

다음 메시지가 표시되면 합성 모니터를 삭제합니다.
```
Cloud Function not found for this Synthetic monitor. Please confirm it exists or delete this monitor.
```
오류 메시지는 함수가 삭제되었으므로 합성 모니터가 함수를 실행할 수 없음을 나타냅니다.
함수의 Cloud Run 함수 페이지를 엽니다. 합성 모니터 세부정보 페이지에서 이 페이지를 열려면 코드를 클릭한 후 함수 이름을 클릭합니다.

다음과 유사한 메시지가 표시되면 함수를 배포할 수 없습니다.
```
This function has failed to deploy and will not work correctly. Please edit and redeploy
```
이 실패를 해결하려면 함수 코드를 검토하고 함수를 빌드하거나 배포하지 못하게 하는 오류를 수정합니다.

합성 모니터를 만들 때 함수가 배포되고 실행되는 데 몇 분 정도 걸릴 수 있습니다.

경고 상태

합성 모니터에는 상태가 Warning인 합성 모니터가 나열됩니다. Warning 상태는 실행 결과가 일관되지 않음을 나타냅니다. 즉, 테스트에 디자인 문제가 있거나 테스트 대상의 동작이 일치하지 않을 수 있습니다.

실패 상태

합성 모니터에는 상태가 Failing인 합성 모니터가 나열됩니다. 실패 이유에 대한 자세한 내용을 보려면 최근 실행 기록을 확인하세요.

오류 메시지 Request failed with status code 429가 표시되면 HTTP 요청의 대상이 명령어를 거부한 것입니다. 이러한 실패를 해결하려면 합성 모니터의 대상을 변경해야 합니다.

엔드포인트 https://www.google.com은 합성 모니터에서 수행된 요청을 거부합니다.
실패 시 0ms 실행 시간이 반환되는 경우 이는 Cloud Run 함수의 메모리가 부족한 것일 수 있습니다. 이 실패를 해결하려면 Cloud Run 함수를 수정한 후 메모리를 최소 2GiB 이상으로 늘리고 CPU 필드를 1로 설정합니다.

합성 모니터 삭제 실패

Cloud Monitoring API를 사용하여 합성 모니터를 삭제하지만 다음과 비슷한 응답이 표시되면서 API 호출이 실패합니다.

{
  "error": {
    "code": 400,
    "message": "Request contains an invalid argument.",
    "status": "INVALID_ARGUMENT",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.DebugInfo",
        "detail": "[ORIGINAL ERROR] generic::invalid_argument: Cannot delete check 1228258045726183344. One or more alerting policies is using it.Delete the alerting policy with id projects/myproject/alertPolicies/16594654141392976482 and any other policies using this uptime check and try again."
      }
    ]
  }
}

실패를 해결하려면 합성 모니터 결과를 모니터링하는 알림 정책을 삭제한 후 합성 모니터를 삭제합니다.