이 문서에서는 Cloud Monitoring 대시보드를 사용하여 예약된 용량을 사용하여 만든 A4X Max, A4X, A4, A3 Ultra, A3 Mega 인스턴스를 모니터링하는 방법을 설명합니다. 이러한 대시보드를 사용하면 독립형 Compute Engine 인스턴스 또는 Slurm 클러스터의 성능 병목 현상을 식별하고 해결하여 워크로드의 다운타임을 최소화할 수 있습니다.
커스텀 대시보드를 만들거나 사전 빌드된 Monitoring 대시보드를 사용하여 다음을 모니터링할 수 있습니다.
컴퓨팅 인스턴스 상태
GPU 성능
네트워크 전송 효율
블록과 하위 블록 간의 네트워크 효율성
머신러닝 (ML) 워크로드 효율성
낙오 항목 감지
응답하지 않는 워크로드 감지
Cluster Director로 클러스터를 모니터링하려면 사전 빌드된 대시보드로 클러스터 성능 모니터링을 참고하세요.
시작하기 전에
워크로드를 모니터링하기 전에 아직 완료하지 않았다면 다음 단계를 완료하세요.
모니터링할 수 있는 워크로드 배포 지원되는 워크로드를 알아보려면 이 문서의 제한사항을 참고하세요. 워크로드를 배포하는 방법을 알아보려면 배포 옵션 개요를 참고하세요.
워크로드 모니터링을 위한 Google Cloud 서비스에 대해 알아보기:
이 문서의 측정항목은 Monitoring 대시보드를 사용합니다. 모니터링 대시보드, 모니터링 보관 기간, 모니터링 가격 책정에 대해 알아보세요.
스트래글러 감지는 Cloud Logging에 로그 항목도 제공합니다. Logging 인터페이스, Logging 보관 기간, Logging 가격 책정에 대해 알아봅니다.
Google Cloud 콘솔을 사용하여 Google Cloud 서비스 및 API에 액세스하는 경우 인증을 설정할 필요가 없습니다.
제한사항
이 문서의 측정항목은 다음 기준을 모두 충족하는 컴퓨팅 인스턴스에서 실행되는 워크로드에만 지원됩니다.
- 컴퓨팅 인스턴스는 독립형 Compute Engine 인스턴스 또는 Slurm 클러스터의 일부로 만들어야 합니다.
- 컴퓨팅 인스턴스는 예약된 용량을 사용하여 생성되어야 합니다.
- 컴퓨팅 인스턴스는 A4X Max, A4X, A4, A3 Ultra 또는 A3 Mega 머신 시리즈를 사용해야 합니다.
ML 워크로드 측정항목을 모니터링하려면 워크로드 모니터링을 설정해야 합니다.
낙오 항목 감지 제한사항
지연 감지 측정항목에는 다음과 같은 추가 제한사항이 있습니다.
- A3 Mega를 제외한 지원되는 머신 시리즈의 경우 지연 감지는 Collective Communication Analyzer (CoMMA) 라이브러리가 NCCL 원격 분석을 Google Cloud 서비스로 내보내도록 지원하는 컴퓨팅 인스턴스만 지원합니다. 자세한 내용은 CoMMA 개요를 참고하세요.
- 지연 감지에는 일반적으로 지연을 보고하는 데 최대 10분이 걸립니다.
- 이 문서의 다른 측정항목과 달리 클러스터, 블록, 하위 블록 또는 컴퓨팅 인스턴스로 프로젝트의 이상치 감지 측정항목을 필터링할 수 없습니다. 하지만 지연된 인스턴스로 의심되는 하나 이상의 컴퓨팅 인스턴스의 ID로 지연된 인스턴스 감지 로그에 대한 쿼리를 필터링할 수 있습니다.
응답하지 않는 워크로드 감지 제한사항
응답하지 않는 워크로드 감지 측정항목은 Collective Communication Analyzer (CoMMA) 라이브러리를 사용하여 NCCL 원격 분석을 Google Cloud 서비스로 내보내는 컴퓨팅 인스턴스만 지원합니다. 자세한 내용은 CoMMA 개요를 참고하세요.
필요한 역할
AI Hypercomputer 워크로드의 측정항목을 모니터링하는 데 필요한 권한을 얻으려면 관리자에게 다음 IAM 역할을 부여해 달라고 요청하세요.
-
Cloud Monitoring에서 측정항목을 보려면 프로젝트에 대한 모니터링 편집자 (
roles/monitoring.editor)가 있어야 합니다. -
Logging에서 이상치 감지 로그를 보려면 프로젝트에 대한 로그 뷰어 (
roles/logging.viewer)가 필요합니다.
역할 부여에 대한 자세한 내용은 프로젝트, 폴더, 조직에 대한 액세스 관리를 참조하세요.
이러한 사전 정의된 역할에는 AI 하이퍼컴퓨터 워크로드의 측정항목을 모니터링하는 데 필요한 권한이 포함되어 있습니다. 필요한 정확한 권한을 보려면 필수 권한 섹션을 펼치세요.
필수 권한
AI 하이퍼컴퓨터 워크로드의 측정항목을 모니터링하려면 다음 권한이 필요합니다.
-
대시보드 보기: 프로젝트에 대한
monitoring.dashboards.get권한 -
대시보드 만들기: 프로젝트에 대한
monitoring.dashboards.create -
로그 항목 보기: 프로젝트에 대한
logging.logEntries.list권한
커스텀 역할이나 다른 사전 정의된 역할을 사용하여 이 권한을 부여받을 수도 있습니다.
사용 가능한 측정항목
사용 사례에 따라 컴퓨팅 인스턴스 및 Slurm 클러스터를 모니터링하는 데 사용할 수 있는 측정항목은 다음과 같습니다.
컴퓨팅 인스턴스에 연결된 GPU의 상태, 성능, 네트워크 성능을 모니터링하려면 인프라 측정항목을 참고하세요.
ML 워크로드의 GPU 효율성을 모니터링하려면 ML 워크로드 측정항목을 참고하세요.
성능이 느린 ML 워크로드에서 의심되는 straggler 컴퓨팅 인스턴스를 모니터링하려면 Straggler 감지 측정항목을 참고하세요.
이러한 측정항목을 보는 방법을 알아보려면 이 문서의 측정항목 시각화를 참고하세요.
인프라 측정항목
컴퓨팅 인스턴스에 연결된 GPU의 상태, 성능, 네트워크 성능을 모니터링하려면 다음 측정항목을 사용하세요.
Compute Engine에서 사용 가능한 측정항목의 개요는 Google Cloud 측정항목을 참고하세요.
GPU 상태 측정항목
GPU 상태를 모니터링하려면 다음 측정항목을 사용하세요.
| 이름 | 측정항목 유형 | 지원되는 머신 시리즈 | 설명 |
|---|---|---|---|
| 머신 상태 | machine/machine_status |
A4X Max, A4X, A4, A3 Ultra 또는 A3 Mega | 컴퓨트 인스턴스에서 사용하는 머신이 정상인지 또는 머신이 비정상이며 수리가 필요한지 여부입니다. |
| NVSwitch 상태 | instance/gpu/nvswitch_status |
A4X Max, A4X, A4, A3 Ultra 또는 A3 Mega | 컴퓨팅 인스턴스에 연결된 NVIDIA GPU의 NVLink 스위치에 문제가 있는지 여부입니다. |
| VM 인프라 상태 | instance/gpu/infra_health |
A4X, A4, A3 Ultra 또는 A3 Mega | 컴퓨팅 인스턴스가 실행 중인 클러스터, 블록, 하위 블록, 호스트의 상태입니다. 이 측정항목에 컴퓨팅 인스턴스의 인프라가 비정상으로 표시되면 측정항목에 문제도 설명됩니다. |
| VM 실패 예측 점수 | instance/gpu/failure_prediction_score |
A4X, A4, A3 Ultra 또는 A3 Mega |
컴퓨팅 인스턴스가 실행되는 호스트가 향후 5시간 내에 성능이 저하될 가능성입니다. 값은 0.0에서 1.0 사이일 수 있습니다. 값이 일정한 기간 동안 1.0에 가까울수록 컴퓨팅 인스턴스가 저하될 가능성이 높습니다. 이 경우 작업을 다른 컴퓨팅 인스턴스로 이동하고 컴퓨팅 인스턴스에 문제가 발생하면 호스트가 잘못되었다고 신고하는 것이 좋습니다.
|
GPU 성능 측정항목
GPU의 성능을 모니터링하려면 다음 측정항목을 사용하세요.
| 이름 | 측정항목 유형 | 지원되는 머신 시리즈 | 설명 |
|---|---|---|---|
| 누적 컨텍스트 사용률 | instance/gpu/accumulated_context_utilization_seconds |
A4X Max, A4X, A4, A3 Ultra 또는 A3 Mega | GPU가 워크로드를 처리하는 데 걸린 총 시간(초)입니다. |
| GPU 전력 소비량 | instance/gpu/power_consumption |
A4X Max, A4X, A4, A3 Ultra 또는 A3 Mega | 호스트의 개별 GPU에서 소비되는 전력(와트(W)) 및 십진수 값입니다. GPU가 여러 개 연결된 컴퓨팅 인스턴스의 경우 이 측정항목은 호스트의 각 GPU에 대한 전력 소비량을 별도로 제공합니다. |
| SM 사용률 | instance/gpu/sm_utilization |
A4X Max, A4X, A4, A3 Ultra 또는 A3 Mega | 0이 아닌 값은 GPU의 스트리밍 멀티 프로세서(SM)가 활발하게 사용되고 있음을 나타냅니다. |
| GPU 온도 | instance/gpu/temperature |
A4X Max, A4X, A4, A3 Ultra 또는 A3 Mega | 호스트에 있는 개별 GPU의 온도(섭씨(℃)) 및 십진수 값입니다. GPU가 여러 개 연결된 컴퓨팅 인스턴스의 경우 이 측정항목은 호스트의 각 GPU 온도를 별도로 제공합니다. |
| GPU 열 마진 | instance/gpu/tlimit |
A4X Max, A4X, A4, A3 Ultra 또는 A3 Mega | 온도가 높아져 속도를 늦춰야 하기 전에 개별 GPU가 갖는 열 여유 (℃) 및 십진수 값입니다. GPU가 여러 개 연결된 컴퓨팅 인스턴스의 경우 이 측정항목은 호스트의 각 GPU에 대한 열 여유를 별도로 제공합니다. |
GPU 네트워크 성능 측정항목
GPU의 네트워크 성능을 모니터링하려면 다음 측정항목을 사용하세요.
| 이름 | 측정항목 유형 | 지원되는 머신 시리즈 | 설명 |
|---|---|---|---|
| 운송업체 변경사항 연결 | instance/gpu/link_carrier_changes |
A4X, A4, A3 Ultra 또는 A3 Mega | 네트워크 링크 캐리어가 1분 동안 변경되는 빈도입니다. |
| 네트워크 RTT | instance/gpu/network_rtt |
A4X, A4, A3 Ultra 또는 A3 Mega | 네트워크 데이터가 소스와 대상 간에 이동하는 데 걸리는 왕복 시간(마이크로초)입니다. |
| 블록 간 네트워크 트래픽 | instance/gpu/network/inter_block_tx |
A4X, A4, A3 Ultra 또는 A3 Mega | 블록 간 네트워크 트래픽의 바이트 수입니다. |
| 하위 블록 간 네트워크 트래픽 | instance/gpu/network/inter_subblock_tx |
A4X, A4, A3 Ultra 또는 A3 Mega | 하위 블록 간 네트워크 트래픽의 바이트 수입니다. |
| 서브 블록 내 네트워크 트래픽 | instance/gpu/network/intra_subblock_tx |
A4X, A4, A3 Ultra 또는 A3 Mega | 단일 하위 블록 내 네트워크 트래픽의 바이트 수입니다. |
| NVLink 활성 속도 | instance/gpu/nvlink_active_speed |
A4X Max, A4X, A4, A3 Ultra 또는 A3 Mega | 현재 액세스 링크 포트 속도(GBps)입니다. |
| 수신 처리량 바이트 수 | instance/gpu/throughput_rx_bytes |
A4X, A4, A3 Ultra 또는 A3 Mega | 네트워크 트래픽에서 수신된 바이트 수입니다. |
| 송신 처리량 바이트 수 | instance/gpu/throughput_tx_bytes |
A4X, A4, A3 Ultra 또는 A3 Mega | 네트워크 트래픽으로 전송된 바이트 수입니다. |
GPU 심각한 오류 측정항목
GPU에서 발생하여 컴퓨팅 인스턴스가 중지되거나 성능에 부정적인 영향을 미칠 수 있는 오류를 모니터링하려면 다음 측정항목을 사용하세요.
| 이름 | 측정항목 유형 | 지원되는 머신 시리즈 | 설명 |
|---|---|---|---|
| NVLink 런타임 오류 | instance/gpu/nvlink_runtime_error |
A4X Max 또는 A4X | NVLink 런타임 오류가 발생했는지 여부입니다. |
| 수정 불가능한 DRAM ECC 오류 | instance/gpu/dram_uncorrectable_ecc_error_count |
A4X Max 또는 A4X | GPU 동적 랜덤 액세스 메모리 (DRAM)의 수정 불가능한 오류 수정 코드 (ECC) 수입니다. |
| 수정 불가능한 DRAM 행 리매핑 수 | instance/gpu/dram_uncorrectable_row_remapping_count |
A4X Max 또는 A4X | GPU DRAM에서 수정 불가능한 오류로 인해 수행된 행 리매핑 수입니다. |
| 수정 불가능한 DRAM 행 리매핑 실패 | instance/gpu/dram_row_remapping_failed |
A4X Max 또는 A4X | 다음 문제 중 하나로 인해 GPU DRAM의 행 리매핑이 실패했는지 여부입니다.
|
| 수정할 수 없는 PCIe 오류 | instance/gpu/pcie_fatal_error_count |
A4X Max 또는 A4X | 수정 불가능한 주변기기 구성요소 상호 연결 익스프레스 (PCIe) 오류 수입니다. |
| 수정 불가능한 캐시 ECC 오류 | instance/gpu/cache_uncorrectable_ecc_error_count |
A4X Max 또는 A4X | 캐시 메모리에서 발생한 수정 불가능한 ECC 수입니다. |
ML 워크로드 측정항목
ML 워크로드의 생산성(특히 goodput)을 모니터링하려면 다음 측정항목을 사용하세요.
| 이름 | 측정항목 유형 | 지원되는 머신 시리즈 | 설명 |
|---|---|---|---|
| 생산적인 시간 | workload/goodput_time |
A4X, A4, A3 Ultra 또는 A3 Mega | 워크로드가 굿풋 활동에 사용한 시간(초)입니다. 이러한 활동은 모델 학습 중 순방향 또는 역방향 패스와 같은 핵심적이고 유용한 작업입니다. |
| 비생산적인 시간 | workload/badput_time |
A4X, A4, A3 Ultra 또는 A3 Mega | 워크로드가 badput 활동에 소요한 시간(초)입니다. 이러한 활동은 학습을 위한 데이터 로드 또는 사전 처리와 같은 오버헤드 작업입니다. |
낙오 항목 감지 측정항목
지연 감지 측정항목은 의심되는 지연을 파악하고 정확히 찾아내는 데 도움이 됩니다. 낙오자는 단일 지점, 비정상 종료되지 않는 실패로, 결국 전체 워크로드의 속도를 저하시킵니다.
VM의 straggler 감지를 모니터링하려면 다음 측정항목을 사용하세요.
| 이름 | 측정항목 유형 | 지원되는 머신 시리즈 | 설명 |
|---|---|---|---|
| 낙오 항목으로 의심됨 | instance/gpu/straggler_status |
A4X, A4, A3 Ultra 또는 A3 Mega | VM이 워크로드 성능에 영향을 미치는 낙오자로 의심되는지 여부입니다. 다른 측정항목에서 워크로드에 문제가 있음을 나타내는 경우에만 의심되는 지연자를 처리하는 것이 좋습니다. |
A4X, A4, A3 Ultra 또는 A3 Mega 인스턴스의 로그 항목에서 지연 감지 측정항목을 확인할 수도 있습니다. 예를 들어 다음 쿼리를 사용할 수 있습니다.
| 설명 | 쿼리 |
|---|---|
| 특정 VM의 지연이 의심되는 로그 이 쿼리를 사용하여 프로젝트의 특정 워크로드에 의심되는 누락 항목이 있는지 확인합니다. |
logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic" AND jsonPayload.suspectedStragglersDetection.numNodes > 0 AND jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID"
OR jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID"
|
| 프로젝트의 낙오자 감지에서 가져온 모든 로그 의심되는 지연자가 감지되지 않을 때 지연자 감지 서비스가 실행 중인지 확인하려면 이 쿼리를 사용하세요. (제한사항으로 인해 의심되는 지연 없이 특정 VM별로 로그를 필터링할 수 없습니다.) |
|
낙오 항목 감지 측정항목은 다음과 같은 이유로 대규모 ML 워크로드에 특히 유용합니다.
대규모 ML 워크로드는 지연에 매우 취약합니다. 대규모 ML 워크로드는 동기식 대규모 분산 컴퓨팅을 사용합니다. (즉, 동시에 실행되는 매우 상호 의존적인 구성요소가 많습니다.) 이 아키텍처는 대규모 ML 워크로드를 지연과 같은 단일 장애점에 매우 취약하게 만듭니다.
대규모 ML 워크로드에서 낙오 항목을 파악하고 찾아내는 것은 매우 어렵습니다. 참고로 단일 장애점에는 다음 두 가지 유형이 있습니다.
중지 오류: 전체 시스템이 중지되는 오류입니다. 예를 들어 호스트 오류 및 유지보수 이벤트가 있습니다. 이러한 문제는 비교적 쉽게 감지하고 해결할 수 있습니다.
느린 실패: 비정상 종료 없이 심각한 성능 저하를 일으키는 실패입니다. 이러한 버그는 정확히 파악하고 디버그하기가 매우 어렵습니다.
지연자는 느린 실패 특성으로 인해 특히 대규모 동기식 워크로드에서 눈에 띄거나 정확히 파악하기가 어렵습니다.
응답하지 않는 워크로드 감지 측정항목
응답하지 않는 워크로드 감지 측정항목은 다음 작업을 수행하는 데 도움이 됩니다.
- 전체 워크로드가 중단된 경우를 알림 (NCCL 중단이라고도 함)
- 프로세스 비정상 종료 또는 네트워크 정체와 같은 워크로드 정체의 원인 파악
컴퓨팅 인스턴스의 응답하지 않는 워크로드를 감지하고 진단하려면 다음 측정항목을 사용하세요.
| 이름 | 측정항목 유형 | 지원되는 머신 시리즈 | 설명 |
|---|---|---|---|
| NCCL 원격 분석을 사용하여 응답하지 않는 워크로드 이벤트가 감지됨 | instance/gpu/nccl_hang |
A4X Max, A4X, A4, A3 Ultra | 감지된 응답하지 않는 워크로드 이벤트의 수입니다(시계열). |
응답하지 않는 워크로드 감지 사용 설정
응답하지 않는 워크로드 감지를 사용 설정하려면 워크로드가 실행 중임을 나타내는 주기적인 핑 신호인 하트비트 원격 분석을 사용하여 CoMMA를 사용 설정해야 합니다. 최근 버전의 CoMMA에서는 이 기능이 기본적으로 사용 설정되어 있습니다. 하지만 NICCL/gIB 번들의 버전 1.1.1에서 CoMMA 버전을 사용하는 경우 하트비트 원격 분석을 수동으로 사용 설정해야 합니다. 사용 중인 NICCL/gIB 번들 버전을 확인하려면 NCCL 및 gIB 버전 확인을 참고하세요.
CoMMA의 하트비트 원격 분석을 수동으로 사용 설정하려면 학습 환경에서 다음 환경 변수를 지정하세요.
NCCL_PROFILER_HEARTBEAT=true
NCCL_PROFILER_HEARTBEAT_UPLOAD_INTERVAL=10s
NCCL_PROFILER_HEARTBEAT를 사용하여 하트비트 원격 분석을 사용 설정 또는 중지하고 NCCL_PROFILER_HEARTBEAT_UPLOAD_INTERVAL를 사용하여 하트비트 원격 분석의 빈도를 지정합니다. 자세한 내용은 CoMMA 환경 변수를 참고하세요.
응답하지 않는 워크로드 감지 사용 중지
응답하지 않는 워크로드 감지를 사용 중지하려면 학습 환경에서 다음 환경 변수를 지정하여 CoMMA에서 하트비트 원격 분석을 사용 중지하세요.
NCCL_PROFILER_HEARTBEAT=false
워크로드가 응답하지 않는 이유 이해
워크로드가 응답하지 않는 이유를 알아보려면 다음 단계를 완료하여 hang_reason 라벨의 값을 확인하세요.
-
Google Cloud 콘솔에서 leaderboard 측정항목 탐색기 페이지로 이동합니다.
검색창을 사용하여 이 페이지를 찾은 경우 부제목이 Monitoring인 결과를 선택합니다.
다음 측정항목을 검색합니다.
compute.googleapis.com/instance/gpu/nccl_hang집계 기능을 사용하고 다음 라벨을 선택합니다.
instance_idhang_reason
다음 표에는 라벨에 사용할 수 있는 값, 워크로드에 대한 값의 의미, 권장되는 다음 단계가 나와 있습니다.
| 라벨 값 | 설명 | 권장되는 다음 단계 |
|---|---|---|
MissingHeartbeatIssue |
하나 이상의 순위에서 하트비트 원격 분석이 중지되었습니다. 이는 일반적으로 심각한 프로세스 또는 노드 비정상 종료를 나타냅니다. |
|
StalledRankIssue |
하트비트 원격 분석은 계속 수신되지만 NCCL 작업에서 순위가 진행되지 않습니다. |
|
MissingCommunicatorIssue |
NCCL 커뮤니케이터에 속한 모든 순위가 진행을 중지했습니다. |
|
NoHangIssue |
기본값입니다. 감지된 문제가 없습니다. |
|
측정항목 보기
컴퓨팅 인스턴스 및 Slurm 클러스터의 측정항목을 보려면 다음과 같이 모니터링 대시보드를 사용하세요.
인프라 측정항목과 straggler 감지 측정항목을 보려면 다음 단계를 따르세요.
인프라 상태 및 성능을 빠르게 개략적으로 확인하거나 기존 대시보드를 맞춤설정하려면 사전 빌드된 대시보드를 사용하세요.
특정 모니터링 요구사항이 있는 경우 커스텀 대시보드를 만드세요.
ML 워크로드 측정항목을 보려면 워크로드 모니터링 설정 방법을 설명하는 문서를 참고하세요.
지연 감지 로그를 보려면 지연 감지 로그 보기를 참고하세요.
대시보드를 사용할 때 문제가 발생하면 성능 저하 문제 해결을 참고하세요.
사전 빌드된 대시보드 사용
AI 하이퍼컴퓨터용으로 사전 빌드된 Monitoring 대시보드를 사용하여 컴퓨팅 인스턴스 및 Slurm 클러스터의 측정항목을 확인할 수 있습니다. 사전 빌드된 대시보드의 사본을 만들어 필요에 맞게 수정할 수도 있습니다.
AI 하이퍼컴퓨터에 사전 빌드된 대시보드를 사용하려면 다음 단계를 따르세요.
-
Google Cloud 콘솔에서 대시보드 페이지로 이동합니다.
검색창을 사용하여 이 페이지를 찾은 경우 부제목이 Monitoring인 결과를 선택합니다.
이름 열에서 보려는 측정항목에 따라 다음 대시보드 중 하나의 이름을 클릭합니다.
컴퓨팅 인스턴스 상태, GPU 성능, straggler 감지를 모니터링하려면 Cluster Director 상태 모니터링 대시보드를 사용하세요.
이러한 측정항목을 사용하여 문제를 식별하고 분석하는 방법에 대한 자세한 내용은 GCE 대화형 플레이북 - Cluster Director 상태 모니터링 플레이북 대시보드를 참고하세요.
네트워크 전송 효율성을 모니터링하려면 클러스터 디렉터 전송 효율성 대시보드를 사용하세요.
블록과 하위 블록 간의 네트워크 효율성을 모니터링하려면 클러스터 디렉터 블록 네트워크 대시보드를 사용하세요.
이러한 측정항목을 사용하여 문제를 식별하고 분석하는 방법에 대한 자세한 내용은 GCE 대화형 플레이북 - Cluster Director 차단 네트워크 플레이북 대시보드를 참고하세요.
선택한 대시보드의 세부정보 페이지가 열립니다. 도구 모음의 기간 선택기를 사용하여 데이터의 기간을 변경할 수 있습니다.
선택사항: 대시보드의 사본을 만들어 필요에 맞게 맞춤설정하려면 대시보드 복사를 클릭합니다.
커스텀 대시보드 만들기
커스텀 모니터링 대시보드를 만들려면 다음 단계를 따르세요.
모니터링할 측정항목을 선택합니다. 아직 확인하지 않았다면 이 문서의 사용 가능한 측정항목을 참고하세요.
낙오 항목 감지 로그 보기
로그 탐색기를 사용하여 지연 감지 로그를 보려면 다음 단계를 완료하세요.
-
Google Cloud 콘솔에서 로그 탐색기 페이지로 이동합니다.
검색창을 사용하여 이 페이지를 찾은 경우 부제목이 Logging인 결과를 선택합니다.
이 페이지는 기본적으로 프로젝트의 모든 로그를 쿼리합니다. 쿼리 중지를 클릭합니다.
툴바의 기간 선택기를 사용하여 분석할 기간을 선택합니다.
쿼리 창에 지연 감지 로그 쿼리를 입력합니다.
쿼리 실행을 클릭합니다.
다음은 지연 감지 로그 항목의 예입니다.
{
...
"jsonPayload": {
...
"@type": "type.googleapis.com/ml.aitelemetry.performancedebugging.output.NetworkStragglersOutput",
"suspectedStragglersDetection": {
"numNodes": 4,
"nodes": [
{
"latencyMs": 9,
"instanceId": "INSTANCE_ID_1"
},
{
"latencyMs": 9,
"instanceId": "INSTANCE_ID_2"
},
{
"instanceId": "INSTANCE_ID_3",
"latencyMs": 4
},
{
"instanceId": "INSTANCE_ID_4",
"latencyMs": 0
}
],
"message": "Suspected stragglers detected."
}
},
"resource": {
"type": "project",
"labels": {
"project_id": "PROJECT_NUMBER"
}
},
...
"severity": "INFO",
"logName": "projects/PROJECT_ID/logs/compute.googleapis.com%2Fworkload_diagnostic",
...
}
로그 항목에는 다음 필드가 포함됩니다.
numNodes: 프로젝트에서 감지된 의심스러운 지연 컴퓨팅 인스턴스의 수입니다. 이 예에서는 지연된 것으로 의심되는 컴퓨팅 인스턴스 4개가 감지되었습니다.instanceId: 의심되는 지연으로 감지된 컴퓨팅 인스턴스의 ID입니다.