이 문서에서는 공개 업타임 체크를 만드는 방법을 설명합니다. 공개 업타임 체크는 전 세계 여러 위치에서 공개적으로 사용 가능한 URL 또는 Google Cloud 리소스로 요청을 실행하고 리소스가 응답하는지 확인할 수 있습니다. 비공개 네트워크에 대해 업타임 체크를 만드는 방법에 대한 자세한 내용은 비공개 업타임 체크 만들기를 참조하세요.
공개 업타임 체크는 다음 모니터링 리소스에 대한 가용성을 확인할 수 있습니다.- 가동시간 확인 URL
- VM 인스턴스
- App Engine 애플리케이션
- Kubernetes 서비스
- Amazon Elastic Compute Cloud(EC2) 인스턴스
- Amazon Elastic 부하 분산기
- Cloud Run 버전
업타임 체크 관리 및 모니터링에 대한 정보 링크는 이 문서의 다음 단계 섹션을 참조하세요.
업타임 체크 정보
HTTP 및 HTTPS의 경우 모든 URL 리디렉션을 따르고 업타임 체크에서 수신된 최종 응답을 성공 기준을 평가하는 데 사용합니다. HTTPS 체크의 경우 SSL 인증서 만료 시간은 최종 응답에서 수신된 서버 인증서를 기반으로 계산됩니다.
업타임 체크가 성공하려면 다음 조건을 충족해야 합니다.
- HTTP 상태가 지정한 기준과 일치합니다.
- 응답 데이터에 필수 콘텐츠가 지정되지 않았거나 필수 콘텐츠가 있습니다.
업타임 체크는 페이지 애셋을 로드하거나 JavaScript를 실행하지 않으며 업타임 체크의 기본 구성에는 인증이 포함되지 않습니다.
시작하기 전에
-
업타임 체크를 만드는 데 필요한 권한을 얻으려면 관리자에게 프로젝트에 대해 다음 IAM 역할을 부여해 달라고 요청하세요.
-
모니터링 편집자(
roles/monitoring.editor
) - Google Cloud 콘솔 사용자 -
모니터링 업타임 체크 구성 편집자(
roles/monitoring.uptimeCheckConfigEditor
) - API 사용자 -
모니터링 AlertPolicy 편집자(
roles/monitoring.alertPolicyEditor
) - API 사용자 -
모니터링 NotificationChannel 편집자 (
roles/monitoring.notificationChannelEditor
) - API 사용자
역할 부여에 대한 자세한 내용은 프로젝트, 폴더, 조직에 대한 액세스 관리를 참조하세요.
-
모니터링 편집자(
검토하려는 리소스에 공개 엔드포인트가 있거나 구성 가능한 방화벽으로 보호되어 있는지 확인합니다.
다른 모든 구성의 경우 비공개 업타임 체크를 만들어야 합니다. 자세한 내용은 비공개 업타임 체크 만들기를 참조하세요.
리소스가 방화벽으로 보호되어 있다면 업타임 체크 서버의 IP 주소에서 들어오는 트래픽을 허용하도록 방화벽을 구성합니다. 자세한 내용은 업타임 체크 서버 IP 주소 나열을 참조하세요.
알림을 수신하는 데 사용할 알림 채널을 구성합니다. 다양한 유형의 알림 채널을 만드는 것이 좋습니다. 자세한 내용은 알림 채널 만들기 및 관리를 참고하세요.
업타임 체크를 위해 체커를 3개 이상 식별합니다. 업타임 체크 리전
USA
에는USA_OREGON
,USA_IOWA
,USA_VIRGINIA
리전이 포함됩니다. 각USA_*
리전에는 하나의 체커가 있고USA
에는 3개 모두 포함됩니다. 다른 업타임 체크 리전EUROPE
,SOUTH_AMERICA
,ASIA_PACIFIC
에는 각각 하나의 체커가 있습니다.Google Cloud 콘솔을 사용할 때 전역을 선택하거나 API를 사용할 때
REGION_UNSPECIFIED
를 선택하면 모든 업타임 체크 리전에서 업타임 체크가 실행됩니다.
업타임 체크 만들기
이 섹션에서는 업타임 체크를 만들고 구성하는 방법에 대해 설명합니다.
하나 이상의 TCP 또는 HTTP/s 포트가 구성된 외부 부하 분산기의 업타임 체크를 만들려면 다음 안내를 따르세요. 해당 서비스의 서비스 세부정보 페이지로 이동한 다음 업타임 체크 만들기를 클릭할 수도 있습니다. 서비스 세부정보 페이지에서 시작하면 서비스별 필드가 자동으로 입력됩니다.
Console
Google Cloud 콘솔을 사용하여 업타임 체크를 만들려면 다음을 수행합니다.
-
Google Cloud 콘솔에서 업타임 체크 페이지로 이동합니다.
검색창을 사용하여 이 페이지를 찾은 경우 부제목이 Monitoring인 결과를 선택합니다.
업타임 체크 만들기를 클릭합니다.
업타임 체크 대상을 지정합니다.
프로토콜을 선택합니다. HTTP, HTTPS 또는 TCP를 선택할 수 있습니다.
다음 리소스 유형 중 하나를 선택합니다.
- URL: 모든 IPv4 주소 또는 호스트 이름입니다. 경로와 포트는 따로 입력됩니다.
- Kubernetes LoadBalancer 서비스: LoadBalancer 유형의 Kubernetes 서비스입니다.
- 인스턴스: Compute Engine 또는 AWS EC2 인스턴스입니다.
- App Engine: App Engine 애플리케이션(모듈)입니다.
- Elastic Load Balancer: AWS 부하 분산기입니다.
프로토콜별 필드를 입력합니다.
TCP 체크의 경우 포트를 입력합니다.
HTTP 및 HTTPS 체크의 경우 호스트 또는 리소스 내에 경로를 입력할 수 있습니다. 이러한 프로토콜을 사용하는 모든 업타임 체크는
http://target/path
에 요청을 보냅니다. 이 표현식에서 URL 리소스의 경우target
은 호스트 이름 또는 IP 주소입니다. App Engine 리소스의 경우target
은 서비스 이름에서 파생된 호스트 이름입니다. 인스턴스 및 부하 분산기 리소스의 경우target
은 리소스 또는 리소스 그룹에 제공한 이름에서 파생된 IP 주소입니다.path
필드를 비워 두거나 값을/
로 설정하면 요청이http://target/
으로 전송됩니다.예를 들어 URL 리소스
example.com/tester
에 업타임 체크를 실행하려면 호스트 이름 필드를example.com
으로 설정하고 경로 필드를/tester
로 설정합니다./
및/hello
를 지원하는 디스패처로 App Engine에 서버를 배포했다고 가정해보세요. '/' 핸들러로 업타임 체크를 실행하려면 경로 필드를 비워 둡니다./hello
핸들러로 업타임 체크를 실행하려면 경로 필드 값을/hello
로 설정합니다.
리소스별 필드를 입력합니다.
URL 리소스에 대해 호스트 이름 필드에 호스트 이름을 입력합니다. 예를 들어
example.com
을 입력합니다.App Engine 리소스에 대해 서비스 필드에 서비스 이름을 입력합니다.
Elastic Load Balancer 및 인스턴스 리소스의 경우 다음과 같이 적용 대상 필드를 작성합니다.
- 단일 인스턴스 또는 부하 분산기에 업타임 체크를 실행하려면 단일을 선택한 다음 단일 메뉴를 사용해 특정 인스턴스 또는 부하 분산기를 선택합니다.
- 모니터링 그룹에 업타임 체크를 실행하려면 그룹을 선택한 다음 메뉴를 사용해 그룹 이름을 선택합니다.
선택사항: 업타임 체크 실행 빈도를 설정하려면 체크 빈도 필드를 사용합니다.
선택사항: 검사기 리전을 선택하거나 HTTP 및 HTTPS 체크를 위한 SSL 인증서, 인증, 헤더, 포트를 구성하려면 추가 대상 옵션을 클릭합니다.
- 리전: 업타임 체크가 요청을 수신할 리전을 선택합니다. 업타임 체크에는 적어도 3개의 검사기가 있어야 합니다. 3개의 검사기가 있는 미국을 제외한 모든 리전에 1개의 검사기가 있습니다. 기본 설정인 전역에는 모든 리전이 포함됩니다.
- ICMP 핑: 최대 3회까지 핑을 전송하도록 업타임 체크를 구성합니다. 자세한 내용은 ICMP 핑 사용을 참조하세요.
- 요청 메서드: HTTP 체크의 경우 요청 메서드를 선택합니다.
- 본문: HTTP POST 체크의 경우 URL로 인코딩된 본문을 입력합니다. 사용자가 직접 인코딩을 수행해야 합니다. 다른 모든 체크의 경우 이 필드를 비워 둡니다.
- 호스트 헤더: 가상 호스트를 확인하려면 이 필드를 입력하세요. TCP 체크에서는 이 필드를 사용할 수 없습니다.
- 포트: 포트 번호를 지정합니다.
- 커스텀 헤더: 커스텀 헤더를 제공하고 필요한 경우 이를 암호화합니다. 암호화하면 양식에서 헤더 값이 숨겨집니다. 다른 사용자에게 표시하지 않으려는 인증 관련 헤더에 암호화를 사용합니다.
인증: 이러한 값은 승인 헤더로 전송됩니다. TCP 체크에서는 이 필드를 사용할 수 없습니다.
다음 옵션 중에서 선택합니다.
SSL 인증서 검증: URL 리소스에 HTTPS를 선택한 경우 기본적으로 서비스는 HTTPS를 통해 연결을 시도하고 SSL 인증서를 검증합니다. URL에 잘못된 인증서가 있으면 업타임 체크에 실패합니다. 잘못된 인증서의 이유는 다음과 같습니다.
- 만료된 인증서
- 자체 서명된 인증서
- 도메인 이름이 일치하지 않는 인증서
- AIA(Authority Information Access) 확장 프로그램을 사용하는 인증서
HTTPS 업타임 체크에서 SSL 인증서를 검증하려면 SSL 인증서 검증을 선택합니다.
SSL 인증서 확인을 사용 중지하려면 SSL 인증서 검증을 선택 취소합니다.
AIA 확장 프로그램이 있는 SSL 인증서가 있는 경우 SSL 인증서 검증을 사용 중지해야 합니다. 이러한 유형의 인증서는 지원되지 않으며 유효성 검사 시퀀스에 실패합니다. 일반적으로 오류 메시지는 '10000ms 후 SSL 핸드셰이크 오류로 응답됨'입니다.
monitoring.googleapis.com/uptime_check/time_until_ssl_cert_expires
측정항목을 사용하여 인증서가 만료되기 전에 알림을 제공하는 알림 정책을 만들 수 있습니다. 자세한 내용은 샘플 정책: 업타임 체크 정책을 참조하세요.SSL 인증서 유효성 검사 체크박스를 선택합니다.
계속을 클릭해서 응답 요구사항을 구성합니다. 이 섹션의 모든 설정에는 기본값이 있습니다.
업타임 체크 제한 시간을 변경하려면 응답 제한 시간 필드를 사용합니다. 이 기간 내에 둘 이상의 위치에서 응답이 수신되지 않으면 업타임 체크가 실패합니다.
콘텐츠 일치를 수행하도록 업타임 체크를 구성하려면 전환 라벨이 콘텐츠 일치 사용 설정됨인지 확인합니다.
- 옵션 메뉴에서 응답 콘텐츠 일치 유형을 선택합니다.
이 필드에 따라 응답 콘텐츠가 반환된 데이터와 어떻게 비교되는지 결정됩니다. 예를 들어 응답 콘텐츠가
abcd
이고 콘텐츠 일치 유형이 포함이라고 가정해 보겠습니다. 업타임 체크는 응답 데이터에abcd
가 포함된 경우에만 성공합니다. 자세한 내용은 응답 데이터 검증을 참조하세요. - 응답 콘텐츠를 입력합니다. 응답 콘텐츠는 1,024바이트보다 길지 않은 문자열이어야 합니다. API에서 이 필드는
ContentMatcher
객체입니다.
- 옵션 메뉴에서 응답 콘텐츠 일치 유형을 선택합니다.
이 필드에 따라 응답 콘텐츠가 반환된 데이터와 어떻게 비교되는지 결정됩니다. 예를 들어 응답 콘텐츠가
업타임 체크로 인한 로그 항목 생성을 방지하려면 로그 체크 실패를 선택 해제합니다.
HTTP 업타임 체크의 경우 허용되는 응답 코드를 구성합니다. 기본적으로 HTTP 업타임 체크는
2xx
응답을 성공 응답으로 표시합니다.
계속을 클릭하고 알림을 구성합니다.
업타임 체크가 실패할 때 알림을 받으려면 알림 정책을 만들고 해당 정책에 대한 알림 채널을 구성합니다.
- 선택사항: 알림 정책 이름을 업데이트합니다.
- 선택사항: 기간 필드에서 알림이 전송되기 전에 업타임 체크가 실패해야 하는 기간을 선택합니다. 기본적으로 2개 이상의 리전에서 1분 이상 업타임 체크 실패를 보고하면 알림이 전송됩니다.
알림 채널 상자에서 arrow_drop_down 메뉴를 클릭하고 추가할 채널을 선택한 다음 확인을 클릭합니다.
메뉴에서 알림 채널은 각 채널 유형별로 알파벳순으로 그룹화됩니다.
알림 정책을 만들지 않으려면 전환 버튼의 텍스트가 알림 생성 안함인지 확인합니다.
계속을 클릭하여 업타임 체크를 완료합니다.
업타임 체크를 설명하는 제목을 입력합니다.
선택사항: 업타임 체크에 사용자 정의 라벨을 추가하려면 다음을 수행합니다.
- expand_more 사용자 라벨 표시를 클릭합니다.
- 키 필드에 라벨 이름을 입력합니다.
라벨 이름은 소문자로 시작해야 하며 소문자, 숫자, 밑줄, 대시를 포함할 수 있습니다. 예를 들어
severity
을 입력합니다. - 값 필드에 라벨 값을 입력합니다. 라벨 값에는 소문자, 숫자, 밑줄, 대시를 포함할 수 있습니다. 예를 들어
critical
을 입력합니다. - 추가 라벨마다 사용자 라벨 추가를 클릭한 후 라벨의 키와 값을 입력합니다.
업타임 체크 구성을 확인하려면 테스트를 클릭합니다. 결과가 예상과 다르면 체크 실패를 참조하여 구성을 수정한 후 확인 단계를 반복합니다.
만들기를 클릭합니다. 만들기를 선택했지만 필수 입력란이 채워지지 않으면 오류 메시지가 표시됩니다.
gcloud
업타임 체크를 만들려면 gcloud monitoring uptime create
명령어를 실행합니다.
gcloud monitoring uptime create DISPLAY_NAME REQUIRED_FLAGS OPTIONAL_FLAGS
위 명령어를 실행하기 전에 다음을 수행합니다.
DISPLAY_NAME을 업타임 체크 이름으로 바꿉니다.
REQUIRED_FLAGS를 구성하여 업타임 체크로 프로브한 리소스를 지정합니다. 예를 들어 다음 명령어는 특정 프로젝트의 URL EXAMPLE.com을 테스트하는 업타임 체크를 만듭니다.
gcloud monitoring uptime create DISPLAY_NAME \ --resource-labels=host=EXAMPLE.com,project_id=PROJECT_ID \ --resource-type=uptime-url
위 명령어는
uptime-url
리소스 유형에 필요한 각 라벨의 값을 지정합니다.기본값을 재정의하도록 OPTIONAL_FLAGS 플래그를 구성합니다. 예를 들어 프로토콜이
http
가 아니면--protocol
플래그를 설정해야 합니다.
API
업타임 체크를 만들려면 projects.uptimeCheckConfigs.create
메서드를 호출합니다. 메서드 매개변수를 다음과 같이 설정합니다.
parent: 필수입니다. 이 매개변수는 업타임 체크를 생성할 프로젝트의 이름이어야 합니다.
PROJECT_ID
를 Google Cloud 프로젝트 ID로 바꿉니다. 형식은 다음과 같습니다.projects/PROJECT_ID
요청 본문에는 새 업타임 체크를 위한
UptimeCheckConfig
객체가 포함되어야 합니다. 이 페이지는 몇 가지 필드에 대한 정보를 제공합니다. 이 객체 및 해당 필드에 대한 자세한 내용은UptimeCheckConfig
를 참조하세요.구성 객체의
name
필드를 비워 둡니다. 시스템은 응답 구성 객체를 구성할 때 이 필드를 설정합니다.HTTP 또는 HTTPS 확인을 구성할 때는
UptimeCheckConfig
객체의HttpCheck
필드를 채워야 합니다. 이 객체에서는requestMethod
필드를GET
또는POST
로 설정합니다. 이 필드가 생략되었거나METHOD_UNSPECIFIED
로 설정되었으면GET
요청이 실행됩니다.POST
요청을 구성하는 경우contentType
,customContentType
(선택사항) 및body
필드를 작성합니다.
create
메서드는 새 구성의 UptimeCheckConfig
객체를 반환합니다.
생성된 업타임 구성이 예상대로 작동하지 않을 경우, 이 페이지의 체크 실패 섹션을 참조하세요.
C#
Monitoring에 인증하려면 애플리케이션 기본 사용자 인증 정보를 설정합니다. 자세한 내용은 로컬 개발 환경의 인증 설정을 참조하세요.
Java
Monitoring에 인증하려면 애플리케이션 기본 사용자 인증 정보를 설정합니다. 자세한 내용은 로컬 개발 환경의 인증 설정을 참조하세요.
Go
Monitoring에 인증하려면 애플리케이션 기본 사용자 인증 정보를 설정합니다. 자세한 내용은 로컬 개발 환경의 인증 설정을 참조하세요.
Node.js
Monitoring에 인증하려면 애플리케이션 기본 사용자 인증 정보를 설정합니다. 자세한 내용은 로컬 개발 환경의 인증 설정을 참조하세요.
PHP
Monitoring에 인증하려면 애플리케이션 기본 사용자 인증 정보를 설정합니다. 자세한 내용은 로컬 개발 환경의 인증 설정을 참조하세요.
Python
Monitoring에 인증하려면 애플리케이션 기본 사용자 인증 정보를 설정합니다. 자세한 내용은 로컬 개발 환경의 인증 설정을 참조하세요.
Ruby
Monitoring에 인증하려면 애플리케이션 기본 사용자 인증 정보를 설정합니다. 자세한 내용은 로컬 개발 환경의 인증 설정을 참조하세요.
Terraform
Terraform 구성을 적용하거나 삭제하는 방법은 기본 Terraform 명령어를 참조하세요. 자세한 내용은 Terraform 제공업체 참고 문서를 확인하세요.
업타임 체크와 이 검사를 모니터링하는 알림 정책을 만들려면 다음 안내를 따르세요.
Terraform 구성 파일을 수정하고
google_monitoring_uptime_check_config
리소스를 추가한 후 구성 파일을 적용합니다.다음 예시에서는 공개 URL을 확인하는 구성을 보여줍니다.
resource "google_monitoring_uptime_check_config" "example" { display_name = "example" timeout = "60s" http_check { port = "80" request_method = "GET" } monitored_resource { type = "uptime_url" labels = { project_id = "PROJECT_ID" host="EXAMPLE.com" } } checker_type = "STATIC_IP_CHECKERS" }
선택사항: 알림 채널과 알림 정책을 만듭니다.
다음 단계에서는 Google Cloud 콘솔을 사용하여 알림 채널 및 알림 정책을 만듭니다. 이 방식을 사용하면 알림 정책은 업타임 체크에서 생성한 데이터만 모니터링합니다.
알림 채널을 만들려면 다음을 수행합니다.
-
Google Cloud 콘솔에서 notifications 알림 페이지로 이동합니다.
검색창을 사용하여 이 페이지를 찾은 경우 부제목이 Monitoring인 결과를 선택합니다.
- 알림 채널 관리를 선택합니다.
- 추가하려는 채널 유형으로 이동하고 추가를 클릭한 후 대화상자를 완료합니다.
-
알림 정책을 만들려면 다음 안내를 따르세요.
-
Google Cloud 콘솔에서 업타임 체크 페이지로 이동합니다.
검색창을 사용하여 이 페이지를 찾은 경우 부제목이 Monitoring인 결과를 선택합니다.
- 업타임 체크를 찾고 more_vert 더보기를 선택한 다음 알림 정책 추가를 선택합니다.
- 대화상자에서 알림 및 이름 섹션으로 이동하고 알림 채널을 펼친 후 선택합니다.
- 알림 정책 이름을 지정한 후 정책 만들기를 클릭합니다.
-
구성 파일에
google_monitoring_alert_policy
리소스를 추가하고 새 구성을 적용하여 알림 정책을 만들 수 있습니다.
업타임 체크 결과가 Monitoring으로 전달되기 시작할 때까지 최대 5분이 지연될 수 있습니다. 이 기간 동안 업타임 체크 대시보드에는 '사용 가능한 데이터 없음' 상태가 보고됩니다.
ICMP 핑 사용
실패한 공개 업타임 체크를 문제 해결하기 위해 확인 중 최대 3회까지 ICMP 핑을 전송하도록 업타임 체크를 구성할 수 있습니다. 핑은 예를 들어 네트워크 연결 문제 및 애플리케이션의 시간 초과로 인해 발생하는 실패를 구분하는 데 도움이 될 수 있습니다.
기본적으로 업타임 체크는 핑을 전송하지 않습니다. 핑을 수행할 때마다 업타임 체크에 지연 시간이 추가됩니다. 비공개 업타임 체크는 핑을 전송할 수 없습니다.
공개 업타임 체크가 실패하면 핑 결과가 Cloud Logging 로그에 기록됩니다. 핑이 실패하면 로그 항목의 httpRequest
필드에 다음 필드가 추가됩니다.
rtt_usec
: 실패한 각 핑 요청의 왕복 시간입니다.unreachable_count
: 상태 코드ICMP_DEST_UNREACH
를 반환한 핑 요청의 수입니다.no_answer_count
: 시간 초과되고 응답을 반환하지 않은 핑 요청의 수입니다.
성공한 업타임 체크의 핑 결과는 로깅되지 않습니다.
핑 구성
각 업타임 체크 구성에는 HttpCheck
객체 또는 TcpCheck
객체가 포함됩니다.
두 객체 모두 pingConfig
필드를 포함합니다.
이 필드를 사용하여 각 체크에 포함할 ICMP 핑 수를 최대 3개까지 지정합니다. 기본적으로 핑은 전송되지 않습니다.
핑을 구성하려면 다음 중 하나를 수행합니다.
Google Cloud 콘솔을 사용하는 경우 대상 옵션 더보기를 펼치고 ICMP 핑 필드에 값을 입력합니다.
Cloud Monitoring API를 사용할 경우 다음과 같은 구조의
PingConfig
객체를 사용합니다.{ "pingsCount": integer }
업타임 체크 구성에 Monitoring API를 사용하는 방법에 대한 자세한 내용은 업타임 체크 만들기: API 또는 업타임 체크 수정: API를 참조하세요.
업타임 체크 검증
Google Cloud 콘솔에서 업타임 체크를 만들 때 저장하기 전에 구성을 테스트할 수 있습니다.
성공적인 체크
다음 조건을 모두 충족하면 업타임 체크에 성공한 것입니다.
- HTTP 상태가 선택한 기준과 일치합니다.
- 응답에 필수 콘텐츠가 없거나 필수 콘텐츠의 응답 검색이 성공했습니다.
실패한 체크
다음은 가동시간 확인 실패의 몇 가지 가능한 원인입니다.
- 연결 오류 - 거부됨: 기본 HTTP 연결 유형을 사용하는 경우 HTTP 요청에 응답하는 웹 서버가 설치되었는지 확인합니다. 연결 오류는 웹 서버를 설치하지 않은 경우에 새 인스턴스에서 발생할 수 있습니다. Compute Engine 빠른 시작을 참조하세요. HTTPS 연결 유형을 사용할 경우 추가 구성 단계를 수행해야 할 수 있습니다. 방화벽 문제는 업타임 체크 서버 IP 주소 나열을 참조하세요.
- 이름 또는 서비스를 찾을 수 없음: 호스트 이름이 잘못되었을 수 있습니다.
- 403 금지됨: 서비스가 업타임 체커에 오류 코드를 반환합니다. 예를 들어 기본 Apache 웹 서버 구성은 Amazon Linux에서 이 코드를 반환하지만, 다른 Linux 버전에서는 코드 200(성공)을 반환합니다. Amazon Linux용 LAMP 튜토리얼 또는 웹 서버 문서를 참조하세요.
- 404 찾을 수 없음: 경로가 잘못되었을 수 있습니다.
408 요청 시간 제한 또는 응답 없음: 포트 번호가 잘못되었거나, 서비스가 실행 중이 아니거나, 서비스에 액세스할 수 없거나, 제한시간이 너무 짧습니다. 업타임 서버의 트래픽이 방화벽에서 허용되는지 확인합니다. 업타임 체크 서버 IP 주소 나열을 참조하세요. 시간 제한 한도는 응답 확인 옵션의 일부로 지정됩니다.
네트워크 혼잡으로 인해 요청 시간 초과가 발생할 수 있습니다. 예를 들어 일시적인 네트워크 혼잡으로 인해 하나의 검사기는 실패하지만 다른 모든 검사기는 성공할 수 있습니다. 알림 정책에서 기본 구성을 사용하는 경우 단일 검사기의 실패로 인해 알림이 발생하지 않습니다.
업타임 체크가 핑을 보내도록 구성된 경우 업타임 체크 실패의 핑 결과가 Cloud Logging에 기록됩니다. 자세한 내용은 ICMP 핑 사용을 참조하세요.