Compute Engine-Instanzen und Slurm-Cluster überwachen

In diesem Dokument wird beschrieben, wie Sie mit Cloud Monitoring-Dashboards A4X Max-, A4X-, A4-, A3 Ultra- und A3 Mega-Instanzen überwachen, die Sie mit reservierungsgebundener Kapazität erstellt haben. Mithilfe dieser Dashboards können Sie Leistungsengpässe in Ihren eigenständigen Compute Engine-Instanzen oder Slurm-Clustern identifizieren und beheben und so die Ausfallzeiten Ihrer Arbeitslasten minimieren.

Wenn Sie benutzerdefinierte Dashboards erstellen oder vordefinierte Monitoring-Dashboards verwenden, können Sie Folgendes überwachen:

  • Zustand der Compute-Instanz

  • GPU-Leistung

  • Effizienz der Netzwerkübertragung

  • Netzwerkeffizienz zwischen Blöcken und Unterblöcken

  • Effizienz von Arbeitslasten für maschinelles Lernen (ML)

  • Nachzüglererkennung

  • Erkennung nicht reagierender Arbeitslasten

Informationen zum Überwachen von Cluster Director-Clustern finden Sie unter Clusterleistung mit vordefinierten Dashboards überwachen.

Hinweis

Führen Sie die folgenden Schritte aus, bevor Sie Ihre Arbeitslast überwachen, falls Sie dies noch nicht getan haben:

Wenn Sie über die Google Cloud Console auf Dienste und APIs von Google Cloud zugreifen, müssen Sie die Authentifizierung nicht einrichten.

Beschränkungen

  • Die Messwerte in diesem Dokument werden nur für Arbeitslasten unterstützt, die auf Compute-Instanzen ausgeführt werden, die alle folgenden Kriterien erfüllen:

    • Die Compute-Instanzen müssen entweder als eigenständige Compute Engine-Instanzen oder als Teil eines Slurm-Clusters erstellt werden.
    • Die Compute-Instanzen müssen mit reservierungsgebundener Kapazität erstellt worden sein.
    • Die Compute-Instanzen müssen die Maschinenserie A4X Max, A4X, A4, A3 Ultra oder A3 Mega verwenden.
      • Die Straggler-Erkennung unterstützt jedoch auch VM-Instanzen, die die Maschinenserie A3 Mega verwenden.

Wenn Sie Messwerte für ML-Arbeitslasten überwachen möchten, müssen Sie das Monitoring für Ihre Arbeitslast einrichten.

Einschränkungen bei der Erkennung von Nachzüglern

Für Messwerte zur Straggler-Erkennung gelten die folgenden zusätzlichen Einschränkungen:

  • Für andere unterstützte Maschinenserien als A3 Mega unterstützt die Straggler-Erkennung nur Compute-Instanzen, die die Collective Communication Analyzer-Bibliothek (CoMMA) aktivieren, um NCCL-Telemetriedaten in Google Cloud -Dienste zu exportieren. Weitere Informationen finden Sie in der CoMMA-Übersicht.
  • Die Straggler-Erkennung benötigt in der Regel bis zu 10 Minuten, um einen Straggler zu melden.
  • Im Gegensatz zu den anderen Messwerten in diesem Dokument können Sie die Messwerte zur Erkennung von Nachzüglern für Ihre Projekte nicht nach Cluster, Block, Unterblock oder Compute-Instanz filtern. Sie können jedoch Abfragen für Logs zur Erkennung von Nachzüglern nach der ID einer oder mehrerer Compute-Instanzen filtern, die als Nachzügler vermutet werden.

Einschränkungen bei der Erkennung nicht reagierender Arbeitslasten

Messwerte zur Erkennung nicht reagierender Arbeitslasten unterstützen nur Compute-Instanzen, die die CoMMA-Bibliothek (Collective Communication Analyzer) verwenden, um NCCL-Telemetriedaten in Google Cloud -Dienste zu exportieren. Weitere Informationen finden Sie in der CoMMA-Übersicht.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Überwachen von Messwerten für AI Hypercomputer-Arbeitslasten benötigen:

  • Zum Aufrufen von Messwerten in Cloud Monitoring: Monitoring-Bearbeiter (roles/monitoring.editor) für das Projekt
  • So rufen Sie Logs zur Straggler-Erkennung in Logging auf: Loganzeige (roles/logging.viewer) für das Projekt

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Diese vordefinierten Rollen enthalten die Berechtigungen, die zum Überwachen von Messwerten für AI Hypercomputer-Arbeitslasten erforderlich sind. Maximieren Sie den Abschnitt Erforderliche Berechtigungen, um die notwendigen Berechtigungen anzuzeigen:

Erforderliche Berechtigungen

Die folgenden Berechtigungen sind erforderlich, um Messwerte für AI Hypercomputer-Arbeitslasten zu überwachen:

  • Zum Aufrufen von Dashboards: monitoring.dashboards.get für das Projekt
  • Zum Erstellen von Dashboards: monitoring.dashboards.create für das Projekt
  • So rufen Sie Logeinträge auf: logging.logEntries.list für das Projekt

Sie können diese Berechtigungen auch mit benutzerdefinierten Rollen oder anderen vordefinierten Rollen erhalten.

Verfügbare Messwerte

Je nach Anwendungsfall stehen die folgenden Messwerte für das Monitoring Ihrer Compute-Instanzen und Slurm-Cluster zur Verfügung:

  • Informationen zum Überwachen des Zustands, der Leistung und der Netzwerkleistung der GPUs, die an Ihre Compute-Instanzen angehängt sind, finden Sie unter Infrastrukturmesswerte.

  • Informationen zum Monitoring von VM-Beendigungen und den zugehörigen Ursachen finden Sie unter Monitoring von VM-Beendigungen.

  • Informationen zum Überwachen der Effizienz der GPUs in Ihren ML-Arbeitslasten finden Sie unter Messwerte für ML-Arbeitslasten.

  • Informationen zum Überwachen von mutmaßlichen Nachzügler-Compute-Instanzen in ML-Arbeitslasten mit langsamer Leistung finden Sie unter Messwerte zur Nachzüglererkennung.

Informationen zum Aufrufen dieser Messwerte finden Sie in diesem Dokument unter Messwerte visualisieren.

Infrastrukturmesswerte

Mit den folgenden Messwerten können Sie den Zustand, die Leistung und die Netzwerkleistung der GPUs überwachen, die an Ihre Compute-Instanzen angehängt sind:

Eine Übersicht über die in Compute Engine verfügbaren Messwerte finden Sie unter Google Cloud -Messwerte.

GPU-Zustandsmesswerte

Verwenden Sie die folgenden Messwerte, um den Zustand Ihrer GPUs zu überwachen:

Name Messwerttyp Unterstützte Maschinenserien Beschreibung
Maschinenstatus machine/machine_status A4X Max, A4X, A4, A3 Ultra oder A3 Mega Ob die Maschine, die die Compute-Instanz verwendet, fehlerfrei ist oder ob sie fehlerhaft ist und repariert werden muss.
NVSwitch-Status instance/gpu/nvswitch_status A4X Max, A4X, A4, A3 Ultra oder A3 Mega Ob bei einem NVLink-Switch auf einer NVIDIA-GPU, die an eine Compute-Instanz angehängt ist, Probleme auftreten.
VM-Infrastrukturzustand instance/gpu/infra_health A4X, A4, A3 Ultra oder A3 Mega Der Zustand des Clusters, Blocks, Unterblocks und Hosts, auf dem Ihre Compute-Instanzen ausgeführt werden. Wenn dieser Messwert zeigt, dass die Infrastruktur einer Compute-Instanz fehlerhaft ist, wird das Problem auch im Messwert beschrieben.
Vorhersagewert für VM-Fehler instance/gpu/failure_prediction_score A4X, A4, A3 Ultra oder A3 Mega Die Wahrscheinlichkeit, dass sich die Leistung des Hosts, auf dem die Compute-Instanz ausgeführt wird, in den nächsten fünf Stunden verschlechtert. Der Wert kann im Bereich von 0.0 bis 1.0 liegen. Je näher der Wert über einen längeren Zeitraum an 1.0 liegt, desto wahrscheinlicher ist es, dass die Leistung der Compute-Instanz beeinträchtigt wird. In diesem Fall empfehlen wir, den Job auf eine andere Compute-Instanz zu verschieben. Wenn Probleme mit der Compute-Instanz auftreten, melden Sie den Host als fehlerhaft.

GPU-Leistungsmesswerte

Verwenden Sie die folgenden Messwerte, um die Leistung Ihrer GPUs zu überwachen:

Name Messwerttyp Unterstützte Maschinenserien Beschreibung
Kumulierte Kontextnutzung instance/gpu/accumulated_context_utilization_seconds A4X Max, A4X, A4, A3 Ultra oder A3 Mega Die Gesamtzeit in Sekunden, die die GPU mit der Verarbeitung einer Arbeitslast beschäftigt ist.
GPU-Stromverbrauch instance/gpu/power_consumption A4X Max, A4X, A4, A3 Ultra oder A3 Mega Die Leistung in Watt (W) und in Dezimalwerten, die von einzelnen GPUs auf dem Host verbraucht wird. Bei Compute-Instanzen mit mehreren angehängten GPUs wird der Stromverbrauch für jede GPU auf dem Host separat angegeben.
SM-Auslastung instance/gpu/sm_utilization A4X Max, A4X, A4, A3 Ultra oder A3 Mega Ein Wert ungleich null gibt an, dass die Streaming-Multiprozessoren (SMs) auf Ihren GPUs aktiv verwendet werden.
GPU-Temperatur instance/gpu/temperature A4X Max, A4X, A4, A3 Ultra oder A3 Mega Die Temperatur in Celsius (℃) und in Dezimalwerten einzelner GPUs auf dem Host. Bei Compute-Instanzen mit mehreren angehängten GPUs wird die Temperatur für jede GPU auf dem Host separat angegeben.
GPU-Wärmemarge instance/gpu/tlimit A4X Max, A4X, A4, A3 Ultra oder A3 Mega Der thermische Spielraum in Celsius (℃) und in Dezimalwerten, den einzelne GPUs haben, bevor sie aufgrund hoher Temperaturen langsamer werden müssen. Bei Compute-Instanzen mit mehreren angehängten GPUs wird der thermische Spielraum für jede GPU auf dem Host separat angegeben.

Leistungsmesswerte für GPU-Netzwerke

Verwenden Sie die folgenden Messwerte, um die Netzwerkleistung Ihrer GPUs zu überwachen. Informationen zum Monitoring von ToR-Netzwerk-Switches im Backend finden Sie unter ToR-Switch-Messwerte.

Name Messwerttyp Unterstützte Maschinenserien Beschreibung
Änderungen am Link-Mobilfunkanbieter instance/gpu/link_carrier_changes A4X, A4, A3 Ultra oder A3 Mega Wie oft sich der Netzwerkverbindungsanbieter innerhalb einer Minute ändert.
Netzwerk-RTT instance/gpu/network_rtt A4X, A4, A3 Ultra oder A3 Mega Die Umlaufzeit in Mikrosekunden, die Netzwerkdaten für die Übertragung zwischen einer Quelle und einem Ziel benötigen.
Netzwerkverkehr zwischen Blöcken instance/gpu/network/inter_block_tx A4X, A4, A3 Ultra oder A3 Mega Die Anzahl der Byte des Netzwerkverkehrs zwischen Blöcken.
Netzwerktraffic zwischen Subblöcken instance/gpu/network/inter_subblock_tx A4X, A4, A3 Ultra oder A3 Mega Die Anzahl der Byte des Netzwerkverkehrs zwischen Unterblöcken.
Netzwerkverkehr im Subblock instance/gpu/network/intra_subblock_tx A4X, A4, A3 Ultra oder A3 Mega Die Anzahl der Byte des Netzwerkverkehrs innerhalb eines einzelnen Unterblocks.
Aktive NVLink-Geschwindigkeit instance/gpu/nvlink_active_speed A4X Max, A4X, A4, A3 Ultra oder A3 Mega Die aktuelle Portgeschwindigkeit des Zugriffslinks in Gbit/s.
Durchsatz-RX-Bytes instance/gpu/throughput_rx_bytes A4X, A4, A3 Ultra oder A3 Mega Die Anzahl der Byte, die über den Netzwerkverkehr empfangen wurden.
Durchsatz-TX-Bytes instance/gpu/throughput_tx_bytes A4X, A4, A3 Ultra oder A3 Mega Die Anzahl der Byte, die an den Netzwerkverkehr übertragen wurden.

ToR-Switch-Messwerte

Bei A4X Max- und A4X-Clustern können Sie die Telemetrie des Backend-ToR-Netzwerk-Switches überwachen, um während des verteilten ML-Trainings Folgendes zu tun:

  • Zustand von Switch und Port beobachten.
  • Verfügbare Bandbreitenkapazität und Tiefe der Warteschlange bewerten.
  • Diagnostizieren Sie Paketverluste, Fehler, Schnittstellen-Flaps und Ereignisse im Zusammenhang mit der Überlastungsverwaltung.

Diese Messwerte verwenden den überwachten Ressourcentyp compute.googleapis.com/NetworkSwitch und das Messwerttyppräfix compute.googleapis.com/. Wählen Sie im Metrics Explorer den Ressourcentyp NetworkSwitch (compute.googleapis.com/NetworkSwitch) aus.

Die Messwerte für den Wechsel sind in folgende Kategorien unterteilt:

Gesundheits- und Statusmesswerte wechseln

Mit den in diesem Abschnitt aufgeführten Messwerten können Sie Folgendes tun:

  • Betriebsstatus von Switch-Ports prüfen
  • CPU- und Arbeitsspeicherauslastung des Switches überwachen
  • Prüfen Sie die Bootzeiten, um unerwartete Neustarts zu erkennen.
Name Messwerttyp Unterstützte Maschinenserien Beschreibung
Status der Nummernmitnahme network_switch/port_status A4X Max oder A4X Gibt den Betriebsstatus der physischen Schnittstelle (Port) auf dem Netzwerk-Switch an. Der Messwert ist für die Aggregation immer 1. Der tatsächliche Status wird im Label status angegeben (z. B. UP oder DOWN).
Wichtige Labels: port_identifier, status, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
CPU-Auslastung network_switch/cpu_utilization A4X Max oder A4X Die CPU-Auslastung des Netzwerk-Switches, gemessen als Bruchteil von 0.0 bis 1.0.
Wichtige Labels: subblock_id, block_id, reservation_id, switch_type.
Verwendeter Arbeitsspeicher network_switch/memory_used A4X Max oder A4X Der vom Netzwerk-Switch verwendete Arbeitsspeicher in Byte.
Wichtige Labels: subblock_id, block_id, reservation_id, switch_type.
Arbeitsspeicher insgesamt network_switch/total_memory_bytes A4X Max oder A4X Die Gesamtspeicherkapazität des Netzwerk-Switches in Byte.
Wichtige Labels: subblock_id, block_id, reservation_id, switch_type.
Bootzeit network_switch/boot_time_in_ns A4X Max oder A4X Der Boot-Zeitstempel des Netzwerk-Switches in Nanosekunden seit der Unix-Epoche.
Wichtige Labels: subblock_id, block_id, reservation_id, switch_type.
Messwerte für Kapazität und Warteschlange wechseln

Verwenden Sie die folgenden Messwerte, um die Referenz- und die nutzbare Netzwerkkapazität zu verfolgen und die Tiefe der Warteschlange und die Anzahl der verworfenen Pakete auf dem Switch zu überwachen:

Name Messwerttyp Unterstützte Maschinenserien Beschreibung
Referenzkapazität network_switch/baseline_capacity_kbps A4X Max oder A4X Die gesamte potenzielle Bandbreitenkapazität (Baseline) einer ToR-Switch-Verbindung zum Superblock in Kilobit pro Sekunde (kbit/s).
Wichtige Labels: subblock_id, block_id, reservation_id, switch_type.
Effektive Kapazität network_switch/effective_capacity_kbps A4X Max oder A4X Die nutzbare Betriebskapazität einer ToR-Switch-Verbindung zum Superblock in Kilobit pro Sekunde (kbit/s). Dieser Messwert spiegelt Kapazitätsreduzierungen wider, die durch beeinträchtigte oder Offline-Links verursacht werden.
Wichtige Labels: subblock_id, block_id, reservation_id, switch_type.
Maximale Warteschlangentiefe für ausgehenden Traffic network_switch/egress_max_queue_depth A4X Max oder A4X Die maximale Warteschlangentiefe, die während des letzten Messzyklus beobachtet wurde.
Wichtige Labels: port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
Verworfene Pakete in der Warteschlange für ausgehenden Traffic network_switch/egress_queue_drops_count A4X Max oder A4X Die kumulative Anzahl der Pakete, die aufgrund von Überlastung der Warteschlange oder Erschöpfung des Puffers aus den Warteschlangen für ausgehenden Traffic verworfen wurden.
Wichtige Labels: port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
Verworfene Pakete im Zwischenspeicher network_switch/in_buffer_discards A4X Max oder A4X Die kumulative Anzahl der eingehenden Pakete, die beim Eingang aufgrund eines Pufferüberlaufs verworfen wurden.
Schlüssellabels: port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Messwerte zu Switch-Drops, Fehlern und Flusssteuerung

Verwenden Sie die Messwerte in diesem Abschnitt, um die folgenden Probleme zu diagnostizieren, die zu Stillständen beim verteilten Training oder zu Zeitüberschreitungen bei der kollektiven Kommunikation (z. B. NCCL-Watchdog-Zeitüberschreitungen) führen können:

  • Paketverluste, Übertragungsfehler und physische Verbindungsabbrüche.
  • FEC-Wortfehler (Forward Error Correction).
  • Ereignisse zur Überlastungsverwaltung, z. B. Pausen bei der prioritätsbasierten Flusssteuerung (Priority-based Flow Control, PFC) und Markierungen für die explizite Überlastungsbenachrichtigung (Explicit Congestion Notification, ECN).
Name Messwerttyp Unterstützte Maschinenserien Beschreibung
Schnittstellenklappen network_switch/interface_flaps_count A4X Max oder A4X Die kumulative Anzahl der Zustandsübergänge der physischen Verbindung (Wechsel zwischen UP und DOWN) auf der Switch-Port-Schnittstelle.
Wichtige Labels: port_identifier, subblock_id, block_id, reservation_id, switch_type.
FEC-Wortfehler network_switch/fec_word_error_count A4X Max oder A4X Die kumulative Anzahl der FEC-Wortfehler (Forward Error Correction). Verwenden Sie das boolesche Label correctable (true oder false), um zwischen korrigierbaren und nicht korrigierbaren Fehlern zu unterscheiden.
Wichtige Labels: port_identifier, correctable, subblock_id, block_id, reservation_id, switch_type.
ECN-markierte Pakete network_switch/ecn_marked_packets_count A4X Max oder A4X Die kumulative Anzahl der Pakete, die aufgrund von Überschreitungen des Pufferschwellenwerts mit ECN-Bits (Explicit Congestion Notification) gekennzeichnet sind.
Wichtige Labels: port_identifier, subblock_id, block_id, reservation_id, switch_type.
Pfc rx-Pakete network_switch/pfc_rx_packets_count A4X Max oder A4X Die kumulative Anzahl der auf dem Port empfangenen Pause-Frames für die prioritätsbasierte Flusssteuerung (Priority-based Flow Control, PFC).
Hinweis: Gilt nur für dedizierte Umgebungen, in denen PFC aktiviert ist.
Wichtige Labels: port_identifier, priority_index, subblock_id, block_id, reservation_id, switch_type.
PFC-TX-Pakete network_switch/pfc_tx_packets_count A4X Max oder A4X Die kumulative Anzahl der Pause-Frames der prioritätsbasierten Flusssteuerung (PFC), die vom Port übertragen werden, um eingehenden Traffic zu drosseln.
Hinweis: Gilt nur für dedizierte Umgebungen, in denen PFC aktiviert ist.
Wichtige Labels: port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
QoS-TX-Pakete network_switch/qos_tx_packets A4X Max oder A4X Die kumulative Anzahl der QoS-Pakete (Quality of Service), die in der angegebenen Warteschlange übertragen wurden.
Wichtige Labels: port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
Anzahl der eingehenden Pakete network_switch/in_packets_count A4X Max oder A4X Die kumulative Anzahl der eingehenden Pakete, die am Switch-Port empfangen wurden.
Wichtige Labels: port_identifier, subblock_id, block_id, reservation_id, switch_type.
In Fehlern network_switch/in_errors A4X Max oder A4X Die kumulative Anzahl der eingehenden Pakete, die mit Fehlern empfangen wurden, die ihre Zustellung verhindert haben.
Schlüssellabels: port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
In „Verworfen“ network_switch/in_discards A4X Max oder A4X Die kumulative Anzahl gültiger eingehender Pakete, die verworfen wurden (z. B. aufgrund von fehlendem Pufferspeicher).
Schlüssellabels: port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Ausgangsfehler network_switch/out_errors A4X Max oder A4X Die kumulative Anzahl der ausgehenden Pakete, die aufgrund von Fehlern nicht übertragen werden konnten.
Schlüssellabels: port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Ausgehende verworfene Pakete network_switch/out_discards A4X Max oder A4X Die kumulative Anzahl der ausgehenden Pakete, die verworfen wurden, obwohl keine Fehler erkannt wurden.
Schlüssellabels: port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Anzahl der eingehenden Bytes network_switch/in_bytes_count A4X Max oder A4X Die kumulative Anzahl der eingehenden Bytes, die am Switch-Port empfangen wurden.
Wichtige Labels: port_identifier, subblock_id, block_id, reservation_id, switch_type.
Anzahl der ausgehenden Bytes network_switch/out_bytes_count A4X Max oder A4X Die kumulative Anzahl der ausgehenden Byte, die über den Switch-Port übertragen wurden.
Wichtige Labels: port_identifier, subblock_id, block_id, reservation_id, switch_type.

Messwerte zu schwerwiegenden GPU-Fehlern

Mit den folgenden Messwerten können Sie die Fehler überwachen, die bei Ihren GPUs auftreten und die dazu führen können, dass Ihre Compute-Instanzen beendet werden oder ihre Leistung beeinträchtigt wird:

Name Messwerttyp Unterstützte Maschinenserien Beschreibung
NVLink-Laufzeitfehler instance/gpu/nvlink_runtime_error A4X Max oder A4X Gibt an, ob ein NVLink-Laufzeitfehler aufgetreten ist.
Nicht korrigierbare DRAM-ECC-Fehler instance/gpu/dram_uncorrectable_ecc_error_count A4X Max oder A4X Die Anzahl der nicht korrigierbaren Fehlerkorrekturcodes (ECCs) in einem GPU-DRAM (Dynamic Random Access Memory).
Anzahl der nicht korrigierbaren DRAM-Zeilenneuzuordnungen instance/gpu/dram_uncorrectable_row_remapping_count A4X Max oder A4X Die Anzahl der Zeilenneuzuordnungen aufgrund nicht korrigierbarer Fehler in GPU-DRAMs.
Nicht korrigierbare DRAM-Zeilenneuzuordnung fehlgeschlagen instance/gpu/dram_row_remapping_failed A4X Max oder A4X Gibt an, ob eine Zeilenneuzuordnung in GPU-DRAMs aufgrund eines der folgenden Probleme fehlgeschlagen ist:
  • Ein Neuzuordnungsversuch für eine Memory Bank ist fehlgeschlagen, da die Memory Bank bereits acht nicht korrigierbare Fehlerzeilen neu zugeordnet hat.
  • Ein Versuch, eine Zeile neu zuzuordnen, ist fehlgeschlagen, da die Zeile bereits neu zugeordnet wurde.
  • Ein Neuzuordnungsversuch ist fehlgeschlagen, da insgesamt 512 Neuzuordnungen vorgenommen wurden.
Nicht korrigierbare PCIe-Fehler instance/gpu/pcie_fatal_error_count A4X Max oder A4X Die Anzahl der nicht korrigierbaren PCIe-Fehler (Peripheral Component Interconnect Express).
Nicht korrigierbare Cache-ECC-Fehler instance/gpu/cache_uncorrectable_ecc_error_count A4X Max oder A4X Die Anzahl der nicht korrigierbaren ECCs im Cache-Speicher.

Monitoring der VM-Beendigung

Wenn eine Compute-Instanz unerwartet beendet wird, können Sie mithilfe von Berichten zu VM-Unterbrechungen die Ursache der Unterbrechung ermitteln.

Compute Engine kategorisiert die Ereignisse, die eine Compute-Instanz beenden, so:

  • Geplante Wartung: Regelmäßige Wartung, die die Zuverlässigkeit und Leistung der Infrastruktur verbessert. Compute Engine kennt diese Ereignisse und benachrichtigt Sie im Voraus.

  • Notfallwartung: Reparaturen für Probleme mit mittlerem Schweregrad, z. B. Hardwareverschlechterung oder kritische Softwarekorrekturen, die nicht bis zur nächsten geplanten Wartung warten können, aber keine sofortige Behebung erfordern. Compute Engine benachrichtigt Sie mit einem kürzeren Benachrichtigungsfenster als bei einer geplanten Wartung.

  • Dringende Reparatur: Unerwartete Software- oder Hardwareprobleme, die sofort behoben werden müssen und für die Sie nur wenig oder gar keine Vorankündigung erhalten.

  • Kritischer Fehler: Unerwartete Software- oder Hardwarefehler, die von Compute Engine nicht im Voraus erkannt werden können.

  • Vom Nutzer gemeldeter Fehler: Sie haben den Host als fehlerhaft gemeldet, wodurch die Compute-Instanz beendet und eine Reparatur gestartet wurde.

  • Vom Nutzer initiierte Beendigung: Sie haben die Compute-Instanz neu gestartet, beendet oder gelöscht.

Jedes Mal, wenn Compute Engine eine Compute-Instanz beendet, wird ein Unterbrechungsbericht in Logging geschrieben. Unterbrechungsberichte verwenden den Lognamen compute.googleapis.com/interruption_report und den überwachten Ressourcentyp gce_instance. Der erste Bericht zur Beendigungsunterbrechung mit einer ausstehenden Diagnose wird in der Regel innerhalb einer Stunde nach der Beendigung gesendet. Der endgültige Bericht zur Unterbrechung der Kündigung wird innerhalb von 72 Stunden nach dem Kündigungszeitpunkt gesendet.

Das Feld jsonPayload.instanceInterruptionReport jedes Logeintrags enthält die folgenden Felder:

Feld Beschreibung
type Die Kategorie des Ereignisses, durch das die Compute-Instanz beendet wurde. Es gibt folgende Ereigniskategorien:
  • PLANNED_MAINTENANCE
  • EMERGENT_MAINTENANCE
  • CRITICAL_FAILURE
  • URGENT_REPAIR
  • USER_REPORTED_FAULT
  • USER_INITIATED_TERMINATION
reason Die genaue Ursache des Ereignisses. Die möglichen Werte hängen vom Wert des Felds type ab. Dieser Wert kann sich zwischen den Berichten zu Beendigungsunterbrechungen ändern, da Compute Engine mehr Informationen darüber erhält, warum die Unterbrechung aufgetreten ist. Der Bericht zur Beendigungsunterbrechung mit dem Status COMPLETE hat den endgültigen reason-Wert.
status Der Status der Diagnose. Es gibt folgende Diagnosestatus:
  • INITIAL_DIAGNOSIS: Compute Engine hat die Beendigung erkannt und eine erste Kategorie und einen Grund zugewiesen, die gerade validiert werden.
  • PENDING_DIAGNOSIS: Die erste Diagnose wurde validiert und Compute Engine schließt die Ursachenanalyse ab.
  • COMPLETE: Die Diagnose ist abgeschlossen und die Felder type und reason sind endgültig.
interruptionTime Der Zeitpunkt, zu dem die Compute-Instanz beendet wurde. Dieser Wert entspricht dem Feld timestamp des Logeintrags.
diagnosisTime Der Zeitpunkt, zu dem Compute Engine den aktuellen Bericht erstellt hat.
summary Eine menschenlesbare Zusammenfassung des Berichts und seines Status.

Sie können diese Berichte zu Beendigungsunterbrechungen in Verbindung mit dem Messwert compute.googleapis.com/instance/interruption_count verwenden, der die Anzahl der Unterbrechungen nach Typ und Grund erfasst.

ML-Arbeitslastmesswerte

Wenn Sie die Produktivität – insbesondere den Goodput – Ihrer ML-Arbeitslasten überwachen möchten, verwenden Sie die folgenden Messwerte:

Name Messwerttyp Unterstützte Maschinenserien Beschreibung
Produktive Zeit workload/goodput_time A4X, A4, A3 Ultra oder A3 Mega Die Zeit in Sekunden, die die Arbeitslast für Goodput-Aktivitäten aufwendet. Diese Aktivitäten sind wichtige, nützliche Aufgaben, z. B. ein Vorwärts- oder Rückwärtsdurchlauf während des Modelltrainings.
Unproduktive Zeit workload/badput_time A4X, A4, A3 Ultra oder A3 Mega Die Zeit in Sekunden, die die Arbeitslast für Badput-Aktivitäten aufwendet. Diese Aktivitäten sind Overhead-Aufgaben, z. B. das Laden oder Vorverarbeiten von Daten für das Training.

Messwerte zur Erkennung von Nachzüglern

Mithilfe von Messwerten zur Erkennung von Nachzüglern können Sie mutmaßliche Nachzügler erkennen und lokalisieren. Nachzügler sind einzelne, nicht abstürzende Fehler, die letztendlich die gesamte Arbeitslast verlangsamen.

Verwenden Sie den folgenden Messwert, um die Straggler-Erkennung für Ihre VMs zu überwachen:

Name Messwerttyp Unterstützte Maschinenserien Beschreibung
Verdächtige Nachzügler instance/gpu/straggler_status A4X, A4, A3 Ultra oder A3 Mega Ob eine VM als Nachzügler vermutet wird, der die Leistung der Arbeitslast beeinträchtigt. Wir empfehlen, nur dann auf vermutete Nachzügler zu reagieren, wenn andere Messwerte darauf hindeuten, dass bei der Arbeitslast Probleme auftreten.

Sie können sich auch Messwerte zur Erkennung von Nachzüglern in den Logeinträgen für eine A4X-, A4-, A3 Ultra- oder A3 Mega-Instanz ansehen. Sie können beispielsweise die folgenden Abfragen verwenden:

Beschreibung Abfrage
Logs mit mutmaßlichen Nachzüglern für bestimmte VMs. Mit dieser Abfrage können Sie prüfen, ob es in Ihrem Projekt mutmaßliche Nachzügler für eine bestimmte Arbeitslast gibt. 
    logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic" AND jsonPayload.suspectedStragglersDetection.numNodes > 0 AND jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID"

Ersetzen Sie INSTANCE_ID durch die ID einer VM. Fügen Sie für jede zusätzliche VM, die Sie angeben möchten, die folgende Bedingung zur Abfrage hinzu:

    OR jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID"
Alle Logs aus der Straggler-Erkennung für Ihr Projekt. Verwenden Sie diese Abfrage, um zu prüfen, ob der Dienst zur Erkennung von Nachzüglern ausgeführt wird, wenn keine mutmaßlichen Nachzügler erkannt werden. Aufgrund der Einschränkungen können Sie die Logs ohne verdächtige Nachzügler nicht nach bestimmten VMs filtern. 
    logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic"

Messwerte zur Straggler-Erkennung sind aus folgenden Gründen besonders hilfreich für große ML-Arbeitslasten:

  • Umfangreiche ML-Arbeitslasten sind sehr anfällig für Nachzügler. Bei umfangreichen ML-Arbeitslasten wird synchrones und massiv verteiltes Computing verwendet. (Mit anderen Worten: Sie haben viele, stark voneinander abhängige Komponenten, die gleichzeitig ausgeführt werden.) Diese Architektur macht große ML-Arbeitslasten sehr anfällig für Single-Point-Fehler wie Straggler.

  • Es ist sehr schwierig, Nachzügler in umfangreichen ML-Arbeitslasten zu erkennen und zu lokalisieren. Es gibt zwei Arten von Single-Point-of-Failure-Fehlern:

    • Stoppfehler: Fehler, die dazu führen, dass das gesamte System angehalten wird, z. B. Hostfehler und Wartungsereignisse. Sie sind relativ einfach zu erkennen und zu beheben.

    • Langsame Fehler: Fehler, die zu einer erheblichen Leistungsminderung ohne Abstürze führen. Sie sind sehr schwer zu lokalisieren und zu beheben.

    Aufgrund ihrer langsamen Ausfallnatur sind Nachzügler von Natur aus schwer zu erkennen und zu lokalisieren, insbesondere bei umfangreichen synchronen Arbeitslasten.

Messwerte zur Erkennung nicht reagierender Arbeitslasten

Messwerte zur Erkennung nicht reagierender Arbeitslasten helfen Ihnen bei Folgendem:

  • Erkennen, wenn eine gesamte Arbeitslast blockiert ist (manchmal als NCCL-Blockierung bezeichnet)
  • Gründe für das Stocken der Arbeitslast, z. B. ob es durch einen Prozessabsturz oder ein blockiertes Netzwerk verursacht wurde

Verwenden Sie die folgenden Messwerte, um nicht reagierende Arbeitslasten für Ihre Compute-Instanzen zu erkennen und zu diagnostizieren:

Name Messwerttyp Unterstützte Maschinenserien Beschreibung
Nicht reagierende Arbeitslasten mithilfe von NCCL-Telemetrie erkennen instance/gpu/nccl_hang A4X Max, A4X, A4 und A3 Ultra Die Anzahl der erkannten nicht reagierenden Arbeitslast-Ereignisse als Zeitreihe.

Erkennung nicht reagierender Arbeitslasten aktivieren

Wenn Sie die Erkennung nicht reagierender Arbeitslasten aktivieren möchten, müssen Sie CoMMA mit Heartbeat-Telemetrie aktivieren. Dabei handelt es sich um ein regelmäßiges Ping-Signal, das angibt, dass eine Arbeitslast ausgeführt wird. In aktuellen Versionen von CoMMA ist diese Option standardmäßig aktiviert. Wenn Sie jedoch die CoMMA-Version aus Version 1.1.1 des NICCL/gIB-Bundles verwenden, müssen Sie die Heartbeat-Telemetrie manuell aktivieren. Informationen dazu, welche Version des NICCL/gIB-Bundles Sie verwenden, finden Sie unter NCCL- und gIB-Version prüfen.

Wenn Sie die Heartbeat-Telemetrie für CoMMA manuell aktivieren möchten, geben Sie die folgenden Umgebungsvariablen in Ihrer Trainingsumgebung an:

NCCL_PROFILER_HEARTBEAT=true

NCCL_PROFILER_HEARTBEAT_UPLOAD_INTERVAL=10s

Mit NCCL_PROFILER_HEARTBEAT können Sie die Heartbeat-Telemetrie aktivieren oder deaktivieren und mit NCCL_PROFILER_HEARTBEAT_UPLOAD_INTERVAL die Häufigkeit der Heartbeat-Telemetrie festlegen. Weitere Informationen finden Sie unter CoMMA-Umgebungsvariablen.

Erkennung nicht reagierender Arbeitslasten deaktivieren

Wenn Sie die Erkennung nicht reagierender Arbeitslasten deaktivieren möchten, deaktivieren Sie die Heartbeat-Telemetrie in CoMMA. Geben Sie dazu die folgende Umgebungsvariable in Ihrer Trainingsumgebung an:

NCCL_PROFILER_HEARTBEAT=false

Gründe für nicht reagierende Arbeitslasten

Wenn Sie wissen möchten, warum eine Arbeitslast nicht reagiert, prüfen Sie den Wert des Labels hang_reason. Gehen Sie dazu so vor:

  1. Rufen Sie in der Google Cloud Console das auf der Seite des Metrics Explorer auf:

    Zu Metrics Explorer

    Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Monitoring ist.

  2. Suchen Sie nach dem folgenden Messwert:

    compute.googleapis.com/instance/gpu/nccl_hang

  3. Verwenden Sie die Funktion Aggregation und wählen Sie die folgenden Labels aus:

    • instance_id
    • hang_reason

In der folgenden Tabelle sind mögliche Werte für das Label aufgeführt, was diese Werte für Ihre Arbeitslasten bedeuten und welche nächsten Schritte empfohlen werden.

Labelwert Beschreibung Empfehlungen
MissingHeartbeatIssue Die Heartbeat-Telemetrie wurde für einen oder mehrere Ränge beendet, was in der Regel auf einen schwerwiegenden Prozess- oder Knotenabsturz hinweist.
  • Prüfen Sie, ob die Instanz noch erreichbar ist.
  • Prüfen Sie, ob Arbeitslastprozesse abgestürzt sind.
  • Suchen Sie in den Systemprotokollen nach OOM-Ereignissen (Out-of-Memory), z. B. dmesg.
  • Suchen Sie nach Hardwarefehlern oder NVIDIA-XID-Fehlern.
StalledRankIssue Heartbeat-Telemetriedaten werden weiterhin empfangen, aber die Ränge machen bei NCCL-Vorgängen keine Fortschritte.
  • Untersuchen Sie potenzielle Deadlocks bei Vorgängen auf Anwendungsebene.
  • Prüfen Sie, ob der Anwendungsprozess in einem Vorgang hängen geblieben ist, der die Kommunikation mit anderen verhindert, z. B. bei einer Berechnung oder einem Prüfpunkt.
MissingCommunicatorIssue Alle Ränge, die zu einem NCCL-Kommunikator gehören, haben aufgehört, Fortschritte zu machen.
  • Ihre Arbeitslast wurde möglicherweise unterbrochen oder die NCCL-Kommunikatoren wurden abrupt geschlossen. Wenn Sie erwarten, dass eine Arbeitslast auf dieser VM-Instanz ohne Unterbrechung ausgeführt wird, prüfen Sie, ob die Arbeitslast ungewöhnlich unterbrochen oder beendet wurde.
NoHangIssue Der Standardwert. Es wurden keine Probleme festgestellt.
  • Sie müssen nichts weiter tun.

Messwerte aufrufen

So rufen Sie Messwerte für Ihre Compute-Instanzen und Slurm-Cluster auf:

Wenn bei der Verwendung eines Dashboards Probleme auftreten, lesen Sie den Hilfeartikel Fehlerbehebung bei langsamer Leistung.

Vordefinierte Dashboards verwenden

Sie können vordefinierte Monitoring-Dashboards für AI Hypercomputer verwenden, um Messwerte für Ihre Compute-Instanzen und Slurm-Cluster aufzurufen. Sie können auch eine Kopie eines vordefinierten Dashboards erstellen und an Ihre Anforderungen anpassen.

So verwenden Sie ein vordefiniertes Dashboard für AI Hypercomputer:

  1. Öffnen Sie in der Google Cloud Console die Seite Dashboards :

    Zu Dashboards

    Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Monitoring ist.

  2. Klicken Sie in der Spalte Name auf den Namen eines der folgenden Dashboards, je nachdem, welche Messwerte Sie sich ansehen möchten:

    • Verwenden Sie das Dashboard Cluster Director Health Monitoring, um den Zustand von Compute-Instanzen, die GPU-Leistung und die Erkennung von Stragglern zu überwachen.

      Weitere Informationen dazu, wie Sie diese Messwerte verwenden, um Probleme zu identifizieren und zu analysieren, finden Sie im Playbook-Dashboard GCE Interactive Playbook – Cluster Director Health Monitoring.

    • Verwenden Sie das Dashboard Cluster Director Transmission Efficiency, um die Effizienz der Netzwerkübertragung zu überwachen.

    • Verwenden Sie das Dashboard Cluster Director Block Network, um die Netzwerkeffizienz zwischen Blöcken und Unterblöcken zu überwachen.

      Weitere Informationen dazu, wie Sie diese Messwerte verwenden, um Probleme zu identifizieren und zu analysieren, finden Sie im Playbook-Dashboard GCE Interactive Playbook – Cluster Director Block Network.

    Die Detailseite des ausgewählten Dashboards wird geöffnet. Mit der Zeitraumauswahl in der Symbolleiste können Sie den Zeitraum der Daten ändern.

  3. Optional: Wenn Sie eine Kopie eines Dashboards erstellen und an Ihre Anforderungen anpassen möchten, klicken Sie auf Dashboard kopieren.

Benutzerdefinierte Dashboards erstellen

So erstellen Sie ein benutzerdefiniertes Monitoring-Dashboard:

  1. Wählen Sie die Messwerte aus, die Sie beobachten möchten. Falls noch nicht geschehen, lesen Sie den Abschnitt Verfügbare Messwerte in diesem Dokument.

  2. Benutzerdefinierte Dashboards erstellen und verwalten

Logs zur Nachzüglererkennung ansehen

Führen Sie die folgenden Schritte aus, um Logs zur Nachzüglererkennung mit dem Log-Explorer aufzurufen:

  1. Rufen Sie in der Google Cloud Console das und die Seite Log-Explorer auf:

    Zum Log-Explorer

    Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis mit der Zwischenüberschrift Logging aus.

    Auf der Seite werden standardmäßig alle Logs in Ihrem Projekt abgefragt. Klicken Sie auf Abfrage beenden.

  2. Wählen Sie in der Symbolleiste mit der Zeitraumauswahl den Zeitraum aus, den Sie analysieren möchten.

  3. Geben Sie im Bereich Abfrage eine Abfrage für Logs zur Erkennung von Nachzüglern ein.

  4. Klicken Sie auf Abfrage ausführen.

Das folgende Beispiel zeigt einen Logeintrag für die Straggler-Erkennung.

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

Der Logeintrag enthält diese Felder:

  • numNodes: Die Anzahl der im Projekt erkannten mutmaßlichen Nachzügler-Compute-Instanzen. Im Beispiel wurden vier mutmaßliche Nachzügler-Compute-Instanzen erkannt.
  • instanceId: Die ID einer Compute-Instanz, die als mutmaßlicher Nachzügler erkannt wurde.

Nächste Schritte