Monitora le istanze Compute Engine e i cluster Slurm

Questo documento spiega come monitorare le istanze Compute Engine A4X Max, A4X, A4, A3 Ultra o A3 Mega che hai creato utilizzando la capacità riservata. In particolare, questo documento spiega come utilizzare le dashboard di Cloud Monitoring per identificare e risolvere i colli di bottiglia delle prestazioni nelle istanze di calcolo autonome o nei cluster Slurm. L'utilizzo di queste dashboard ti aiuta a ridurre al minimo i tempi di inattività e i problemi di prestazioni nei tuoi carichi di lavoro.

Quando crei o utilizzi dashboard di Monitoring predefinite per monitorare istanze di computing autonome o cluster Slurm, puoi monitorare quanto segue:

  • Integrità istanza di computing

  • Prestazioni della GPU

  • Efficienza della trasmissione di rete

  • Efficienza della rete tra blocchi e sottoblocchi

  • Efficienza del workload di machine learning (ML)

  • Rilevamento di elementi in ritardo

Prima di iniziare

Prima di monitorare il carico di lavoro, se non l'hai ancora fatto, completa i seguenti passaggi:

When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

Limitazioni

  • Le metriche in questo documento sono supportate solo per i carichi di lavoro eseguiti su istanze di Compute che soddisfano tutti i seguenti criteri:

    • Le istanze di calcolo devono essere create come istanze Compute Engine autonome o come parte di un cluster Slurm.
    • Le istanze di computing devono essere state create utilizzando la capacità riservata.
    • Le istanze di calcolo devono utilizzare le serie di macchine A4X Max, A4X, A4, A3 Ultra o A3 Mega.
      • Tuttavia, il rilevamento di ritardatari supporta anche le istanze di macchine virtuali (VM) che utilizzano la serie di macchine A3 Mega.

  • Per monitorare le metriche del carico di lavoro ML, devi configurare il monitoraggio per il carico di lavoro.

  • Le metriche di rilevamento dei ritardatari presentano le seguenti limitazioni aggiuntive:

    • Per le serie di macchine supportate diverse da A3 Mega, il rilevamento dei ritardatari supporta solo le istanze di Compute che consentono alla libreria Collective Communication Analyzer (CoMMA) di esportare la telemetria NCCL nei servizi Google Cloud . Per saperne di più, consulta la panoramica di CoMMA.
    • Il rilevamento dei ritardatari in genere richiede fino a 10 minuti per segnalare un ritardatario.
    • A differenza delle altre metriche in questo documento, non puoi filtrare le metriche di rilevamento dei valori anomali per i tuoi progetti in base a cluster, blocco, sottoblocco o istanza di Compute. Tuttavia, puoi filtrare le query per i log di rilevamento dei ritardatari in base all'ID di una o più istanze di computing sospette.

Ruoli obbligatori

Per ottenere le autorizzazioni necessarie per monitorare le metriche per i carichi di lavoro AI Hypercomputer, chiedi all'amministratore di concederti i seguenti ruoli IAM:

  • Per visualizzare le metriche in Cloud Monitoring: Editor Monitoring (roles/monitoring.editor) sul progetto
  • Per visualizzare i log di rilevamento dei ritardatari in Logging: Visualizzatore log (roles/logging.viewer) sul progetto

Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.

Questi ruoli predefiniti contengono le autorizzazioni necessarie per monitorare le metriche per i carichi di lavoro AI Hypercomputer. Per vedere quali sono esattamente le autorizzazioni richieste, espandi la sezione Autorizzazioni obbligatorie:

Autorizzazioni obbligatorie

Per monitorare le metriche per i carichi di lavoro di AI Hypercomputer sono necessarie le seguenti autorizzazioni:

  • Per visualizzare le dashboard: monitoring.dashboards.get sul progetto
  • Per creare dashboard: monitoring.dashboards.create sul progetto
  • Per visualizzare le voci di log: logging.logEntries.list sul progetto

Potresti anche ottenere queste autorizzazioni con ruoli personalizzati o altri ruoli predefiniti.

Metriche disponibili

A seconda del caso d'uso, sono disponibili le seguenti metriche per il monitoraggio delle istanze di computing e dei cluster Slurm:

Per scoprire come visualizzare queste metriche, consulta Visualizzare le metriche in questo documento.

Metriche dell'infrastruttura

Per monitorare l'integrità, il rendimento e il rendimento di rete delle GPU collegate alle istanze di computing, puoi utilizzare le seguenti metriche:

Per una panoramica delle metriche disponibili in Compute Engine, consulta MetricheGoogle Cloud .

Metriche di integrità della GPU

Per monitorare l'integrità delle GPU, utilizza le seguenti metriche:

Nome Tipo di metrica Serie di macchine supportate Descrizione
Stato della macchina machine/machine_status A4X Max, A4X, A4, A3 Ultra o A3 Mega Indica se la macchina utilizzata dall'istanza di computing è integra oppure non è integra e richiede una riparazione.
Stato NVSwitch instance/gpu/nvswitch_status A4X Max, A4X, A4, A3 Ultra o A3 Mega Se uno switch NVLink su una GPU NVIDIA collegata a un'istanza di calcolo riscontra problemi.
Stato dell'infrastruttura VM instance/gpu/infra_health A4X, A4, A3 Ultra o A3 Mega L'integrità del cluster, del blocco, del sottoblocco e dell'host su cui sono in esecuzione le istanze di computing. Se questa metrica mostra che l'infrastruttura di un'istanza di calcolo non è integra, la metrica descrive anche il problema.
Punteggio di previsione degli errori della VM instance/gpu/failure_prediction_score A4X, A4, A3 Ultra o A3 Mega La probabilità che l'host su cui viene eseguita l'istanza di computing si degradi nelle prossime cinque ore. Il valore può essere compreso tra 0.0 e 1.0. Più il valore rimane vicino a 1.0 per un periodo di tempo costante, più è probabile che l'istanza di calcolo si degraderà. In questo caso, ti consigliamo di spostare il job su un'altra istanza di calcolo e, se riscontri problemi con l'istanza di calcolo, segnala il relativo host come difettoso.

Metriche sulle prestazioni della GPU

Per monitorare le prestazioni delle GPU, utilizza le seguenti metriche:

Nome Tipo di metrica Serie di macchine supportate Descrizione
Utilizzo del contesto accumulato instance/gpu/accumulated_context_utilization_seconds A4X Max, A4X, A4, A3 Ultra o A3 Mega Il tempo totale, in secondi, durante il quale la GPU è occupata a elaborare un carico di lavoro.
Consumo energetico GPU instance/gpu/power_consumption A4X Max, A4X, A4, A3 Ultra o A3 Mega La potenza in watt (W) e in valori decimali consumata dalle singole GPU sull'host. Per le istanze di calcolo con più GPU collegate, la metrica fornisce il consumo energetico separatamente per ogni GPU sull'host.
Utilizzo SM instance/gpu/sm_utilization A4X Max, A4X, A4, A3 Ultra o A3 Mega Un valore diverso da zero indica che i multiprocessori streaming (SM) delle GPU sono in uso attivo.
Temperatura GPU instance/gpu/temperature A4X Max, A4X, A4, A3 Ultra o A3 Mega La temperatura in gradi Celsius (°C) e in valori decimali delle singole GPU sull'host. Per le istanze di calcolo con più GPU collegate, la metrica fornisce la temperatura separatamente per ogni GPU sull'host.
Margine termico della GPU instance/gpu/tlimit A4X Max, A4X, A4, A3 Ultra o A3 Mega Il margine termico in gradi Celsius (℃) e in valori decimali che le singole GPU hanno prima di dover rallentare a causa dell'alta temperatura. Per le istanze di calcolo con più GPU collegate, la metrica fornisce l'headroom termico separatamente per ogni GPU sull'host.

Metriche sulle prestazioni di rete della GPU

Per monitorare le prestazioni di rete delle GPU, utilizza le seguenti metriche:

Nome Tipo di metrica Serie di macchine supportate Descrizione
Modifiche all'operatore di collegamento instance/gpu/link_carrier_changes A4X, A4, A3 Ultra o A3 Mega La frequenza con cui cambia il vettore del collegamento di rete in un minuto.
RTT di rete instance/gpu/network_rtt A4X, A4, A3 Ultra o A3 Mega Il tempo di round trip, misurato in microsecondi, per il trasferimento dei dati di rete tra un'origine e una destinazione.
Traffico di rete tra blocchi instance/gpu/network/inter_block_tx A4X, A4, A3 Ultra o A3 Mega Il numero di byte di traffico di rete tra i blocchi.
Traffico di rete a livello di inter-sottoblocco instance/gpu/network/inter_subblock_tx A4X, A4, A3 Ultra o A3 Mega Il numero di byte di traffico di rete tra i sottoblocchi.
Traffico di rete all'interno del blocco secondario instance/gpu/network/intra_subblock_tx A4X, A4, A3 Ultra o A3 Mega Il numero di byte di traffico di rete all'interno di un singolo sottoblocco.
Velocità attiva NVLink instance/gpu/nvlink_active_speed A4X Max, A4X, A4, A3 Ultra o A3 Mega La velocità della porta del link di accesso attuale, in GBps.
Throughput Rx Bytes instance/gpu/throughput_rx_bytes A4X, A4, A3 Ultra o A3 Mega Il numero di byte ricevuti dal traffico di rete.
Throughput TX Bytes instance/gpu/throughput_tx_bytes A4X, A4, A3 Ultra o A3 Mega Il numero di byte trasmessi al traffico di rete.

Metriche errori irreversibili GPU

Per monitorare gli errori riscontrati dalle GPU e che potrebbero forzare l'arresto delle istanze di calcolo o influire negativamente sulle loro prestazioni, utilizza le seguenti metriche:

Nome Tipo di metrica Serie di macchine supportate Descrizione
Errore di runtime NVLink instance/gpu/nvlink_runtime_error A4X Max o A4X Indica se si è verificato un errore di runtime NVLink.
Errori ECC DRAM non correggibili instance/gpu/dram_uncorrectable_ecc_error_count A4X Max o A4X Il numero di codici di correzione degli errori (ECC) non correggibili in una memoria ad accesso casuale dinamica (DRAM) della GPU.
Conteggio del remapping delle righe DRAM non correggibili instance/gpu/dram_uncorrectable_row_remapping_count A4X Max o A4X Il numero di rimappature di righe da errori non correggibili nelle DRAM della GPU.
Rimappatura della riga DRAM non correggibile non riuscita instance/gpu/dram_row_remapping_failed A4X Max o A4X Indica se il remapping di una riga nelle DRAM della GPU non è riuscito a causa di uno dei seguenti problemi:
  • Un tentativo di rimappatura di una banca di memoria non è riuscito perché la banca di memoria ha già rimappato otto righe di errori non correggibili.
  • Un tentativo di rimappatura di una riga non è riuscito perché la riga era già rimappata.
  • Un tentativo di rimappatura non è riuscito perché si sono verificate 512 rimappature totali.
Errori PCIe non correggibili instance/gpu/pcie_fatal_error_count A4X Max o A4X Il numero di errori PCIe (Peripheral Component Interconnect Express) non correggibili.
Errori ECC della cache non correggibili instance/gpu/cache_uncorrectable_ecc_error_count A4X Max o A4X Il numero di ECC non correggibili nella memoria cache.

Metriche dei carichi di lavoro ML

Per monitorare la produttività, in particolare il goodput, dei tuoi workload ML, utilizza le seguenti metriche:

Nome Tipo di metrica Serie di macchine supportate Descrizione
Tempo produttivo workload/goodput_time A4X, A4, A3 Ultra o A3 Mega Il tempo, in secondi, che il workload dedica alle attività di goodput. Queste attività sono utili e fondamentali, ad esempio un passaggio in avanti o indietro durante l'addestramento del modello.
Tempo non produttivo workload/badput_time A4X, A4, A3 Ultra o A3 Mega Il tempo, in secondi, che il workload dedica alle attività di badput. Queste attività sono attività di overhead, come il caricamento o la preelaborazione dei dati per l'addestramento.

Metriche di rilevamento degli elementi in ritardo

Le metriche di rilevamento dei ritardatari ti aiutano a notare e individuare i presunti ritardatari. Gli elementi in ritardo sono errori non irreversibili che si verificano in un unico punto e che alla fine rallentano l'intero carico di lavoro.

Per monitorare il rilevamento di ritardatari per le tue VM, utilizza la seguente metrica:

Nome Tipo di metrica Serie di macchine supportate Descrizione
Elementi in ritardo sospetti instance/gpu/straggler_status A4X, A4, A3 Ultra o A3 Mega Indica se una VM è sospettata di essere un ritardatario che influisce sulle prestazioni del workload. Ti consigliamo di intervenire sui presunti ritardatari solo quando altre metriche indicano che il carico di lavoro sta riscontrando problemi.

Puoi anche visualizzare le metriche di rilevamento dei ritardatari nelle voci di log per un'istanza A4X, A4, A3 Ultra o A3 Mega. Ad esempio, puoi utilizzare le seguenti query:

Descrizione Query
Log con ritardatari sospetti per VM specifiche. Utilizza questa query per verificare se sono presenti ritardatari sospetti per un carico di lavoro specifico nel tuo progetto. 
    logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic" AND jsonPayload.suspectedStragglersDetection.numNodes > 0 AND jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID"

Sostituisci INSTANCE_ID con l'ID di una VM. Per ogni VM aggiuntiva che vuoi specificare, aggiungi la seguente condizione alla query:

    OR jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID"
Tutti i log del rilevamento di ritardatari per il tuo progetto. Utilizza questa query per verificare se il servizio di rilevamento dei ritardatari è in esecuzione quando non vengono rilevati ritardatari sospetti. A causa delle limitazioni, non puoi filtrare i log senza ritardatari sospetti in base a VM specifiche. 
    logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic"

Le metriche di rilevamento dei ritardatari sono particolarmente utili per i carichi di lavoro ML su larga scala per i seguenti motivi:

  • I carichi di lavoro ML su larga scala sono molto sensibili ai ritardatari. I carichi di lavoro di ML su larga scala utilizzano il computing sincrono e distribuito in modo massiccio. In altre parole, hanno molti componenti altamente interdipendenti che vengono eseguiti contemporaneamente. Questa architettura rende i carichi di lavoro di ML su larga scala molto suscettibili a errori di tipo single-point come i ritardatari.

  • Individuare e identificare i ritardatari nei workload ML su larga scala è molto difficile. Per riferimento, considera che esistono due tipi di single point of failure:

    • Errori di arresto: errori che causano l'arresto dell'intero sistema; ad esempio errori dell'host ed eventi di manutenzione. Sono relativamente semplici da rilevare e risolvere.

    • Errori lenti: errori che causano un grave calo delle prestazioni senza arresti anomali. Sono molto difficili da individuare e correggere.

    A causa della loro natura di guasto lento, i ritardatari sono intrinsecamente difficili da notare e individuare, soprattutto in carichi di lavoro sincroni su larga scala.

Visualizza metriche

Per visualizzare le metriche per le istanze di computing e i cluster Slurm, utilizza le dashboard di Monitoring nel seguente modo:

Se riscontri problemi durante l'utilizzo di una dashboard, consulta Risolvere i problemi di prestazioni lente.

Utilizzare le dashboard predefinite

Puoi utilizzare le dashboard di monitoraggio predefinite per AI Hypercomputer per visualizzare le metriche per le istanze di computing e i cluster Slurm. Puoi anche creare una copia di una dashboard predefinita e modificarla in base alle tue esigenze.

Per utilizzare una dashboard predefinita per AI Hypercomputer:

  1. Nella console Google Cloud , vai alla pagina  Dashboard:

    Vai a Dashboard

    Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Monitoring.

  2. Nella colonna Nome, fai clic sul nome di una delle seguenti dashboard in base alle metriche che vuoi visualizzare:

    • Per monitorare l'integrità delle istanze di computing, le prestazioni della GPU e il rilevamento di nodi lenti, utilizza la dashboard Monitoraggio dell'integrità di Cluster Director.

      Per ulteriori informazioni su come utilizzare queste metriche per identificare e analizzare i problemi, utilizza anche la dashboard del playbook GCE Interactive Playbook - Cluster Director Health Monitoring.

    • Per monitorare l'efficienza della trasmissione di rete, utilizza la dashboard Efficienza della trasmissione di Cluster Director.

    • Per monitorare l'efficienza della rete tra blocchi e sottoblocchi, utilizza la dashboard Cluster Director Block Network.

      Per ulteriori informazioni su come utilizzare queste metriche per identificare e analizzare i problemi, utilizza anche la dashboard del playbook GCE Interactive Playbook - Cluster Director Block Network.

    Viene visualizzata la pagina dei dettagli della dashboard scelta. Puoi utilizzare il selettore dell'intervallo di tempo nella barra degli strumenti per modificare l'intervallo di tempo dei dati.

  3. (Facoltativo) Per creare una copia di una dashboard e personalizzarla in base alle tue esigenze, fai clic su Copia dashboard.

Crea dashboard personalizzate

Per creare una dashboard di Monitoring personalizzata:

  1. Scegli le metriche da monitorare. Se non lo hai ancora fatto, consulta la sezione Metriche disponibili in questo documento.

  2. Creare e gestire dashboard personalizzate.

Visualizza i log di rilevamento degli elementi in ritardo

Per visualizzare i log di rilevamento dei ritardatari utilizzando Esplora log, completa i seguenti passaggi:

  1. Nella console Google Cloud , vai alla pagina Esplora log:

    Vai a Esplora log

    Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Logging.

    Per impostazione predefinita, la pagina esegue query su tutti i log del progetto. Fai clic su Interrompi query.

  2. Utilizza il selettore dell'intervallo di tempo nella barra degli strumenti per selezionare l'intervallo di tempo che vuoi analizzare.

  3. Nel riquadro Query, inserisci una query per i log di rilevamento dei ritardatari.

  4. Fai clic su Esegui query.

Di seguito è riportato un esempio di voce di log di rilevamento di attività in ritardo.

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

La voce di log include i seguenti campi:

  • numNodes: Il numero di istanze di computing sospette di essere in ritardo rilevate nel progetto. Nell'esempio, sono state rilevate quattro istanze di calcolo sospette in ritardo.
  • instanceId: l'ID di un'istanza di computing rilevata come sospetta ritardataria.

Passaggi successivi