Memantau instance Compute Engine dan cluster Slurm

Dokumen ini menjelaskan cara menggunakan dasbor Cloud Monitoring untuk memantau instance A4X Max, A4X, A4, A3 Ultra, dan A3 Mega yang Anda buat menggunakan kapasitas yang dicadangkan. Dengan menggunakan dasbor ini, Anda dapat mengidentifikasi dan memecahkan masalah hambatan performa di instance Compute Engine mandiri atau cluster Slurm, sehingga meminimalkan waktu non-operasional dalam workload Anda.

Dengan membuat dasbor kustom atau menggunakan dasbor Monitoring bawaan, Anda dapat memantau hal berikut:

• Kondisi instance komputasi

• Performa GPU

• Efisiensi transmisi jaringan

• Efisiensi jaringan di antara blok dan sub-blok

• Efisiensi workload machine learning (ML)

• Deteksi keterlambatan

• Deteksi workload yang tidak responsif

Untuk memantau cluster Cluster Director, lihat Memantau performa cluster dengan dasbor bawaan.

Sebelum memulai

Sebelum memantau workload, jika Anda belum melakukannya, selesaikan langkah-langkah berikut:

• Deploy workload yang dapat Anda pantau. Untuk mempelajari workload mana yang didukung, lihat batasan dalam dokumen ini. Untuk mempelajari cara men-deploy workload, lihat Ringkasan opsi deployment.

• Pelajari Google Cloud layanan untuk memantau workload:

  • Metrik dalam dokumen ini menggunakan dasbor Monitoring. Pelajari Dasbor Monitoring, Periode retensi Monitoring, dan Harga Monitoring.

  • Deteksi keterlambatan juga menyediakan entri log di Cloud Logging. Pelajari Antarmuka logging, Periode retensi logging, dan Harga logging.

Saat menggunakan konsol Google Cloud untuk mengakses layanan Google Cloud dan API, Anda tidak perlu menyiapkan autentikasi.

Batasan

Masalah umum untuk metrik infrastruktur:

• Beberapa instance komputasi mungkin tidak menampilkan metrik GPU Power Consumption.
• Beberapa instance komputasi mungkin tidak menampilkan metrik GPU Temperature atau GPU Thermal Margin, atau mungkin menampilkan NaN, bukan metrik.
• Metrik mungkin tidak muncul di konsol Google Cloud hingga tujuh menit setelah dikumpulkan.
• Anda mungkin melihat metrik yang salah untuk seri mesin selain A4X Max, A4X, A4, A3 Ultra, atau A3 Mega.

Metrik dalam dokumen ini hanya didukung untuk workload yang berjalan di instance komputasi yang memenuhi semua kriteria berikut:

• Instance komputasi harus dibuat sebagai instance Compute Engine mandiri atau sebagai bagian dari cluster Slurm.
• Instance komputasi harus dibuat menggunakan kapasitas yang dicadangkan.
• Instance komputasi harus menggunakan seri mesin A4X Max, A4X, A4, A3 Ultra, atau A3 Mega.

Untuk memantau metrik workload ML, Anda harus menyiapkan pemantauan untuk workload Anda.

Batasan deteksi keterlambatan

Metrik deteksi keterlambatan memiliki batasan tambahan berikut:

• Untuk seri mesin yang didukung selain A3 Mega, deteksi lambat hanya mendukung instance komputasi yang mengaktifkan library Collective Communication Analyzer (CoMMA) untuk mengekspor telemetri NCCL ke layanan Google Cloud . Untuk mengetahui informasi selengkapnya, lihat Ringkasan CoMMA.
• Deteksi keterlambatan biasanya memerlukan waktu hingga 10 menit untuk melaporkan keterlambatan.
• Tidak seperti metrik lainnya dalam dokumen ini, Anda tidak dapat memfilter metrik deteksi keterlambatan untuk project menurut cluster, blok, sub-blok, atau instance komputasi. Namun, Anda dapat memfilter kueri untuk log deteksi straggler berdasarkan ID satu atau beberapa instance komputasi yang diduga straggler.

Perhatian: Anda mungkin melihat positif palsu atau negatif palsu saat menggunakan deteksi lambat seperti, tetapi tidak terbatas pada, berikut ini:

• Log deteksi keterlambatan melaporkan bahwa instance komputasi yang berjalan yang tidak mendukung deteksi keterlambatan tidak dicurigai sebagai keterlambatan.
• Meskipun deteksi lambat akurat untuk banyak beban kerja ML, ketidakakuratan lebih mungkin terjadi untuk beban kerja dengan pola komunikasi yang kompleks.

Oleh karena itu, sebaiknya Anda mengambil tindakan terhadap straggler yang dicurigai hanya jika metrik lain menunjukkan bahwa beban kerja mengalami masalah. Jika tidak, jika performa keseluruhan workload memuaskan, maka tidak ada tindakan yang disarankan.

Batasan deteksi workload yang tidak responsif

Metrik deteksi workload yang tidak responsif hanya mendukung instance komputasi yang menggunakan library Collective Communication Analyzer (CoMMA) untuk mengekspor telemetri NCCL ke layanan Google Cloud . Untuk mengetahui informasi selengkapnya, lihat Ringkasan CoMMA.

Peran yang diperlukan

Untuk mendapatkan izin yang Anda perlukan untuk memantau metrik untuk beban kerja AI Hypercomputer, minta administrator untuk memberi Anda peran IAM berikut:

• Untuk melihat metrik di Cloud Monitoring: Monitoring Editor (roles/monitoring.editor) di project
• Untuk melihat log deteksi keterlambatan di Logging: Logs Viewer (roles/logging.viewer) di project

Untuk mengetahui informasi selengkapnya tentang pemberian peran, lihat Mengelola akses ke project, folder, dan organisasi.

Peran bawaan ini berisi izin yang diperlukan untuk memantau metrik untuk workload AI Hypercomputer. Untuk melihat izin yang benar-benar diperlukan, perluas bagian Izin yang diperlukan:

Izin yang diperlukan

Izin berikut diperlukan untuk memantau metrik untuk workload AI Hypercomputer:

• Untuk melihat dasbor: monitoring.dashboards.get pada project
• Untuk membuat dasbor: monitoring.dashboards.create pada project
• Untuk melihat entri log: logging.logEntries.list pada project

Anda mungkin juga bisa mendapatkan izin ini dengan peran khusus atau peran bawaan lainnya.

Metrik yang tersedia

Bergantung pada kasus penggunaan Anda, metrik berikut tersedia untuk memantau instance komputasi dan cluster Slurm:

• Untuk memantau kondisi, performa, dan performa jaringan GPU yang terpasang ke instance komputasi Anda, lihat Metrik infrastruktur.

• Untuk memantau efisiensi GPU dalam workload ML Anda, lihat Metrik workload ML.

• Untuk memantau instance komputasi yang dicurigai sebagai lambat dalam workload ML dengan performa lambat, lihat Metrik deteksi lambat.

Untuk mempelajari cara melihat metrik ini, lihat Memvisualisasikan metrik dalam dokumen ini.

Metrik infrastruktur

Untuk memantau kondisi, performa, dan performa jaringan GPU yang terpasang ke instance komputasi, Anda dapat menggunakan metrik berikut:

• Metrik kesehatan GPU

• Metrik performa GPU

• Metrik performa jaringan GPU

• Metrik error fatal GPU

Untuk mengetahui ringkasan metrik yang tersedia di Compute Engine, lihat Google Cloud metrik.

Metrik kesehatan GPU

Untuk memantau kondisi GPU, gunakan metrik berikut:

Nama	Jenis metrik	Seri mesin yang didukung	Deskripsi
Status Mesin	machine/machine_status	A4X Max, A4X, A4, A3 Ultra, atau A3 Mega	Apakah mesin yang digunakan instance komputasi dalam kondisi baik, atau mesin dalam kondisi tidak baik dan memerlukan perbaikan.
Status NVSwitch	instance/gpu/nvswitch_status	A4X Max, A4X, A4, A3 Ultra, atau A3 Mega	Apakah NVLink Switch pada GPU NVIDIA yang terpasang ke instance komputasi mengalami masalah.
Kesehatan Infrastruktur VM	instance/gpu/infra_health	A4X, A4, A3 Ultra, atau A3 Mega	Kondisi cluster, blok, sub-blok, dan host tempat instance komputasi Anda berjalan. Jika metrik ini menunjukkan bahwa infrastruktur instance komputasi tidak dalam kondisi baik, metrik ini juga menjelaskan masalah tersebut.
Skor Prediksi Kegagalan VM	instance/gpu/failure_prediction_score	A4X, A4, A3 Ultra, atau A3 Mega	Kemungkinan host tempat instance komputasi berjalan mengalami penurunan performa dalam lima jam ke depan. Nilainya dapat berkisar antara 0.0 dan 1.0. Semakin dekat nilai tetap ke 1.0 selama jangka waktu yang konsisten, semakin besar kemungkinan instance komputasi akan mengalami penurunan performa. Dalam hal ini, sebaiknya pindahkan tugas ke instance komputasi lain dan, jika Anda mengalami masalah dengan instance komputasi, laporkan host-nya sebagai rusak.

Metrik performa GPU

Untuk memantau performa GPU, gunakan metrik berikut:

Nama	Jenis metrik	Seri mesin yang didukung	Deskripsi
Penggunaan Konteks yang Terakumulasi	instance/gpu/accumulated_context_utilization_seconds	A4X Max, A4X, A4, A3 Ultra, atau A3 Mega	Total waktu, dalam detik, saat GPU sibuk memproses workload.
Konsumsi Daya GPU	instance/gpu/power_consumption	A4X Max, A4X, A4, A3 Ultra, atau A3 Mega	Daya dalam watt (W) dan dalam nilai desimal yang dikonsumsi pada GPU individual di host. Untuk instance komputasi dengan beberapa GPU yang terpasang, metrik ini memberikan konsumsi daya secara terpisah untuk setiap GPU di host.
Penggunaan SM	instance/gpu/sm_utilization	A4X Max, A4X, A4, A3 Ultra, atau A3 Mega	Nilai non-nol menunjukkan bahwa multiprosesor streaming (SM) di GPU Anda sedang aktif digunakan.
Suhu GPU	instance/gpu/temperature	A4X Max, A4X, A4, A3 Ultra, atau A3 Mega	Suhu dalam Celsius (℃) dan dalam nilai desimal GPU individual di host. Untuk instance komputasi dengan beberapa GPU yang terpasang, metrik ini memberikan suhu secara terpisah untuk setiap GPU di host.
Margin Termal GPU	instance/gpu/tlimit	A4X Max, A4X, A4, A3 Ultra, atau A3 Mega	Ruang cadangan termal dalam Celsius (℃) dan dalam nilai desimal yang dimiliki setiap GPU sebelum perlu melambat karena suhu tinggi. Untuk instance komputasi dengan beberapa GPU yang terpasang, metrik memberikan ruang cadangan termal secara terpisah untuk setiap GPU di host.

Metrik performa jaringan GPU

Untuk memantau performa jaringan GPU, gunakan metrik berikut:

Nama	Jenis metrik	Seri mesin yang didukung	Deskripsi
Perubahan Operator Tertaut	instance/gpu/link_carrier_changes	A4X, A4, A3 Ultra, atau A3 Mega	Seberapa sering operator link jaringan berubah dalam satu menit.
RTT Jaringan	instance/gpu/network_rtt	A4X, A4, A3 Ultra, atau A3 Mega	Waktu round-trip, yang diukur dalam mikrodetik, untuk data jaringan yang berpindah antara sumber dan tujuan.
Traffic Jaringan di Antar-Blok	instance/gpu/network/inter_block_tx	A4X, A4, A3 Ultra, atau A3 Mega	Jumlah byte traffic jaringan di antara blok.
Traffic Jaringan di Antar-Sub-blok	instance/gpu/network/inter_subblock_tx	A4X, A4, A3 Ultra, atau A3 Mega	Jumlah byte traffic jaringan di antara sub-blok.
Traffic Jaringan di Dalam Sub-blok	instance/gpu/network/intra_subblock_tx	A4X, A4, A3 Ultra, atau A3 Mega	Jumlah byte traffic jaringan dalam satu sub-blok.
Kecepatan Aktif NVLink	instance/gpu/nvlink_active_speed	A4X Max, A4X, A4, A3 Ultra, atau A3 Mega	Kecepatan port link akses saat ini, dalam GBps.
Throughput Byte Rx	instance/gpu/throughput_rx_bytes	A4X, A4, A3 Ultra, atau A3 Mega	Jumlah byte yang diterima dari traffic jaringan.
Throughput Tx Bytes	instance/gpu/throughput_tx_bytes	A4X, A4, A3 Ultra, atau A3 Mega	Jumlah byte yang ditransmisikan ke traffic jaringan.

Metrik error fatal GPU

Untuk memantau error yang terjadi pada GPU Anda dan yang dapat menyebabkan instance komputasi Anda berhenti, atau berdampak negatif pada performanya, gunakan metrik berikut:

Nama	Jenis metrik	Seri mesin yang didukung	Deskripsi
Error runtime NVLink	instance/gpu/nvlink_runtime_error	A4X Max atau A4X	Apakah terjadi error runtime NVLink.
Error ECC DRAM yang tidak dapat dikoreksi	instance/gpu/dram_uncorrectable_ecc_error_count	A4X Max atau A4X	Jumlah kode koreksi error (ECC) yang tidak dapat dikoreksi dalam memori akses acak dinamis (DRAM) GPU.
Jumlah pemetaan ulang baris DRAM yang tidak dapat dikoreksi	instance/gpu/dram_uncorrectable_row_remapping_count	A4X Max atau A4X	Jumlah pemetaan ulang baris dari error yang tidak dapat dikoreksi di DRAM GPU.
Pemetaan ulang baris DRAM yang tidak dapat dikoreksi gagal	instance/gpu/dram_row_remapping_failed	A4X Max atau A4X	Apakah pemetaan ulang baris di DRAM GPU gagal karena salah satu masalah berikut: Upaya pemetaan ulang pada bank memori gagal karena bank memori sudah memiliki delapan baris error yang tidak dapat dikoreksi yang dipetakan ulang. Upaya pemetaan ulang pada baris gagal karena baris sudah dipetakan ulang. Upaya pemetaan ulang gagal karena total 512 pemetaan ulang telah terjadi.
Error PCIe yang tidak dapat diperbaiki	instance/gpu/pcie_fatal_error_count	A4X Max atau A4X	Jumlah error peripheral component interconnect express (PCIe) yang tidak dapat diperbaiki.
Error ECC cache yang tidak dapat dikoreksi	instance/gpu/cache_uncorrectable_ecc_error_count	A4X Max atau A4X	Jumlah ECC yang tidak dapat dikoreksi dalam memori cache.

Metrik workload ML

Untuk memantau produktivitas—khususnya, goodput—dari workload ML Anda, gunakan metrik berikut:

Nama	Jenis metrik	Seri mesin yang didukung	Deskripsi
Waktu produktif	workload/goodput_time	A4X, A4, A3 Ultra, atau A3 Mega	Waktu, dalam detik, yang dihabiskan workload untuk aktivitas goodput. Aktivitas ini adalah tugas inti yang berguna, seperti forward pass atau backward pass selama pelatihan model.
Waktu tidak produktif	workload/badput_time	A4X, A4, A3 Ultra, atau A3 Mega	Waktu, dalam detik, yang dihabiskan workload untuk aktivitas badput. Aktivitas ini adalah tugas tambahan, seperti memuat atau melakukan prapemrosesan data untuk pelatihan.

Metrik deteksi straggler

Metrik deteksi lambat membantu Anda melihat dan menentukan lokasi yang diduga lambat. Straggler adalah kegagalan titik tunggal yang tidak menyebabkan error dan pada akhirnya memperlambat seluruh beban kerja.

Untuk memantau deteksi VM yang lambat, gunakan metrik berikut:

Nama	Jenis metrik	Seri mesin yang didukung	Deskripsi
Diduga Tertinggal	instance/gpu/straggler_status	A4X, A4, A3 Ultra, atau A3 Mega	Apakah VM dicurigai sebagai VM yang lambat dan memengaruhi performa workload. Sebaiknya Anda menindaklanjuti dugaan keterlambatan hanya jika metrik lain menunjukkan bahwa workload mengalami masalah.

Anda juga dapat melihat metrik deteksi keterlambatan di entri log untuk instance A4X, A4, A3 Ultra, atau A3 Mega. Misalnya, Anda dapat menggunakan kueri berikut:

Deskripsi	Kueri
Log dengan straggler yang dicurigai untuk VM tertentu. Gunakan kueri ini untuk memeriksa apakah ada kemungkinan keterlambatan untuk workload tertentu dalam project Anda.	logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic" AND jsonPayload.suspectedStragglersDetection.numNodes > 0 AND jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID" Ganti INSTANCE_ID dengan ID VM. Untuk setiap VM tambahan yang ingin Anda tentukan, tambahkan kondisi berikut ke kueri: OR jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID"
Semua log dari deteksi keterlambatan untuk project Anda. Gunakan kueri ini untuk memverifikasi apakah layanan deteksi keterlambatan berjalan saat tidak ada keterlambatan yang dicurigai. (Karena batasan, Anda tidak dapat memfilter log tanpa VM yang diduga lambat berdasarkan VM tertentu.)	logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic"

Metrik deteksi keterlambatan sangat membantu untuk beban kerja ML skala besar karena alasan berikut:

• Workload ML berskala besar sangat rentan terhadap tugas yang tertunda. Workload ML berskala besar menggunakan komputasi sinkron dan terdistribusi secara masif. (Dengan kata lain, aplikasi ini memiliki banyak komponen yang sangat saling bergantung dan berjalan secara bersamaan.) Arsitektur ini membuat workload ML skala besar sangat rentan terhadap kegagalan satu titik seperti straggler.

• Melihat dan menentukan lokasi tugas yang tertinggal dalam workload ML berskala besar sangatlah sulit. Sebagai referensi, pertimbangkan bahwa ada dua jenis kegagalan titik tunggal:

  • kegagalan penghentian: Kegagalan yang menyebabkan seluruh sistem berhenti; misalnya error host dan peristiwa pemeliharaan. Error ini relatif mudah dideteksi dan diselesaikan.

  • kegagalan lambat: Kegagalan yang menyebabkan penurunan performa yang parah tanpa error. Bug ini sangat sulit untuk diidentifikasi dan di-debug.

  Karena sifat kegagalan yang lambat, straggler sulit untuk dideteksi dan diidentifikasi, terutama dalam workload sinkron skala besar.

Metrik deteksi beban kerja yang tidak responsif

Metrik deteksi beban kerja yang tidak responsif membantu Anda melakukan hal berikut:

• Melihat saat seluruh workload terhenti (terkadang disebut sebagai NCCL hang)
• Pahami alasan beban kerja terhenti, seperti apakah disebabkan oleh error proses atau jaringan yang terhenti

Untuk mendeteksi dan mendiagnosis workload yang tidak responsif untuk instance komputasi Anda, gunakan metrik berikut:

Nama	Jenis metrik	Seri mesin yang didukung	Deskripsi
Peristiwa workload tidak responsif terdeteksi menggunakan telemetri NCCL	instance/gpu/nccl_hang	A4X Max, A4X, A4, dan A3 Ultra	Jumlah peristiwa beban kerja tidak responsif yang terdeteksi, sebagai deret waktu.

Mengaktifkan deteksi workload yang tidak responsif

Untuk mengaktifkan deteksi workload yang tidak responsif, Anda harus mengaktifkan CoMMA dengan telemetri detak jantung, sinyal ping berkala yang menunjukkan bahwa workload sedang berjalan. Untuk CoMMA versi terbaru, fitur ini diaktifkan secara default. Namun, jika Anda menggunakan versi CoMMA dari paket NICCL/gIB versi 1.1.1, Anda harus mengaktifkan telemetri detak jantung secara manual. Untuk memverifikasi versi paket NICCL/gIB yang Anda gunakan, lihat Memeriksa versi NCCL dan gIB.

Untuk mengaktifkan telemetri detak jantung secara manual untuk CoMMA, tentukan variabel lingkungan berikut di lingkungan pelatihan Anda:

NCCL_PROFILER_HEARTBEAT=true

NCCL_PROFILER_HEARTBEAT_UPLOAD_INTERVAL=10s

Gunakan NCCL_PROFILER_HEARTBEAT untuk mengaktifkan atau menonaktifkan telemetri detak jantung, dan NCCL_PROFILER_HEARTBEAT_UPLOAD_INTERVAL untuk menentukan frekuensi telemetri detak jantung. Untuk mengetahui informasi selengkapnya, lihat Variabel lingkungan CoMMA.

Menonaktifkan deteksi workload yang tidak responsif

Untuk menonaktifkan deteksi beban kerja yang tidak responsif, nonaktifkan telemetri detak jantung di CoMMA dengan menentukan variabel lingkungan berikut di lingkungan pelatihan Anda:

NCCL_PROFILER_HEARTBEAT=false

Memahami alasan beban kerja tidak responsif

Untuk memahami alasan workload tidak merespons, periksa nilai label hang_reason dengan menyelesaikan langkah-langkah berikut:

1. Di konsol Google Cloud , buka halaman  Metrics explorer:

   Buka Metrics explorer

   Jika Anda menggunakan kotak penelusuran untuk menemukan halaman ini, pilih hasil yang subjudulnya adalah Monitoring.

2. Cari metrik berikut:

   compute.googleapis.com/instance/gpu/nccl_hang
   

3. Gunakan fitur Agregasi, lalu pilih label berikut:

   • instance_id
   • hang_reason

Tabel berikut mencantumkan kemungkinan nilai untuk label, arti nilai tersebut terkait workload Anda, dan langkah berikutnya yang direkomendasikan.

Nilai label	Deskripsi	Rekomendasi langkah selanjutnya
MissingHeartbeatIssue	Telemetri detak jantung telah berhenti untuk satu atau beberapa peringkat, yang biasanya menunjukkan proses fatal atau error node.	Pastikan apakah instance masih dapat dijangkau. Verifikasi apakah proses workload telah error. Periksa peristiwa kehabisan memori (OOM), seperti dmesg, di log sistem. Cari kegagalan hardware atau error XID NVIDIA.
StalledRankIssue	Telemetri detak jantung masih diterima, tetapi peringkat tidak berkembang pada operasi NCCL.	Menyelidiki potensi kebuntuan dalam operasi tingkat aplikasi. Periksa apakah proses aplikasi macet dalam operasi yang mencegahnya berkomunikasi dengan yang lain, seperti komputasi atau checkpointer.
MissingCommunicatorIssue	Semua peringkat yang dimiliki komunikator NCCL telah berhenti mencapai kemajuan.	Workload Anda mungkin terganggu, atau komunikator NCCL-nya mungkin ditutup tiba-tiba. Jika Anda mengharapkan workload berjalan tanpa gangguan di instance VM ini, periksa apakah workload telah terganggu atau dimatikan secara tidak normal.
NoHangIssue	Nilai default. Tidak ada masalah yang terdeteksi.	Anda tidak perlu melakukan tindakan apa pun.

Lihat metrik

Untuk melihat metrik instance komputasi dan cluster Slurm, gunakan dasbor Monitoring sebagai berikut:

• Untuk melihat metrik infrastruktur dan metrik deteksi keterlambatan, Anda dapat melakukan hal berikut:

  • Untuk ringkasan cepat tentang kondisi dan performa infrastruktur Anda, atau untuk menyesuaikan dasbor yang ada, gunakan dasbor bawaan.

  • Untuk kebutuhan pemantauan tertentu, buat dasbor kustom.

• Untuk melihat metrik workload ML, lihat dokumentasi tentang cara menyiapkan pemantauan untuk workload Anda.

• Untuk melihat log dari deteksi straggler, lihat log deteksi straggler.

Jika Anda mengalami masalah saat menggunakan dasbor, lihat Memecahkan masalah performa lambat.

Menggunakan dasbor bawaan

Anda dapat menggunakan dasbor Monitoring yang telah dibuat sebelumnya untuk AI Hypercomputer guna melihat metrik untuk instance komputasi dan cluster Slurm. Anda juga dapat membuat salinan dasbor bawaan dan mengubahnya agar sesuai dengan kebutuhan Anda.

Untuk menggunakan dasbor bawaan untuk AI Hypercomputer, lakukan hal berikut:

1. Di konsol Google Cloud , buka halaman  Dashboards:

   Buka Dasbor

   Jika Anda menggunakan kotak penelusuran untuk menemukan halaman ini, pilih hasil yang subjudulnya adalah Monitoring.

2. Di kolom Nama, klik nama salah satu dasbor berikut berdasarkan metrik yang ingin Anda lihat:

   • Untuk memantau kondisi instance komputasi, performa GPU, dan deteksi keterlambatan, gunakan dasbor Pemantauan Kondisi Cluster Director.

     Untuk mengetahui informasi selengkapnya tentang cara menggunakan metrik ini untuk mengidentifikasi dan menganalisis masalah, gunakan juga dasbor playbook GCE Interactive Playbook - Cluster Director Health Monitoring.

   • Untuk memantau efisiensi transmisi jaringan, gunakan dasbor Efisiensi Transmisi Cluster Director.

   • Untuk memantau efisiensi jaringan di antara blok dan sub-blok, gunakan dasbor Cluster Director Block Network.

     Untuk mengetahui informasi selengkapnya tentang cara menggunakan metrik ini untuk mengidentifikasi dan menganalisis masalah, gunakan juga dasbor playbook GCE Interactive Playbook - Cluster Director Block Network.

   Halaman detail dasbor yang Anda pilih akan terbuka. Anda dapat menggunakan pemilih rentang waktu di toolbar untuk mengubah rentang waktu data.

3. Opsional: Untuk membuat salinan dasbor dan menyesuaikannya agar sesuai dengan kebutuhan Anda, klik Salin dasbor.

Membuat dasbor kustom

Untuk membuat dasbor Monitoring kustom, lakukan hal berikut:

1. Pilih metrik yang akan dipantau. Jika belum, lihat Metrik yang tersedia dalam dokumen ini.

2. Membuat dan mengelola dasbor kustom.

Melihat log deteksi straggler

Untuk melihat log deteksi keterlambatan menggunakan Logs Explorer, selesaikan langkah-langkah berikut:

1. Di konsol Google Cloud , buka halaman segmen Logs Explorer:

   Buka Logs Explorer

   Jika Anda menggunakan kotak penelusuran untuk menemukan halaman ini, pilih hasil yang subjudulnya adalah Logging.

   Halaman ini mengkueri semua log di project Anda secara default. Klik Hentikan kueri.

2. Gunakan pemilih rentang waktu di toolbar untuk memilih rentang waktu yang ingin Anda analisis.

3. Di panel Query, masukkan kueri untuk log deteksi straggler.

4. Klik Run Query.

Berikut adalah contoh entri log deteksi keterlambatan.

  {
    ...
    "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",
    ...
  }
  

Entri log ini mencakup kolom berikut:

• numNodes: Jumlah instance komputasi yang diduga lambat yang terdeteksi dalam project. Dalam contoh ini, empat instance komputasi yang diduga tertinggal telah terdeteksi.
• instanceId: ID instance komputasi yang terdeteksi sebagai straggler yang dicurigai.

Langkah berikutnya

• Mengamati dan memantau VM
• Menguji cluster menggunakan pemindai kesehatan cluster
• Menyesuaikan dasbor untuk Google Cloud layanan
• Memecahkan masalah performa yang lambat