TPUs überwachen

In diesem Leitfaden wird erläutert, wie Sie Cloud Monitoring verwenden, um Ihre TPU-VMs zu überwachen. Cloud Monitoring erfasst automatisch Messwerte und Logs von Ihrer TPU und der zugehörigen Host-VM. Mit diesen Daten können Sie den Zustand Ihrer TPU und Compute Engine überwachen.

Mit Messwerten können Sie eine numerische Größe im Zeitverlauf verfolgen, z. B. die CPU-Auslastung, die Netzwerknutzung oder die Inaktivitätsdauer der TensorCores. In Logs werden Ereignisse zu einem bestimmten Zeitpunkt erfasst. Logeinträge werden von Ihrem eigenen Code, Diensten vonGoogle Cloud , Anwendungen von Drittanbietern und der Infrastruktur vonGoogle Cloud erstellt. Sie können auch Messwerte aus den Daten in einem Logeintrag generieren, indem Sie einen logbasierten Messwert erstellen. Sie können auch Benachrichtigungsrichtlinien auf Grundlage von Messwerten oder Logeinträgen festlegen.

Sie können zur Überwachung von TPUs auch Capacity Planner (Vorabversion) verwenden. Mit Capacity Planner können Sie TPU-Nutzungs- und Prognosedaten für Ihr Projekt, Ihren Ordner oder Ihre Organisation ansehen. Diese Daten werden alle 24 Stunden aktualisiert. Sie können sie verwenden, um Nutzungstrends zu analysieren und den zukünftigen Kapazitätsbedarf zu planen. Weitere Informationen finden Sie unter Übersicht über Capacity Planner.

Auf TPU-Messwerte zugreifen

Compute Engine generiert zwei Arten von TPU-Messwerten: TPU-Laufzeitmesswerte und TPU-VM-Infrastrukturmesswerte. Sie haben zwei Möglichkeiten, die Messwerte abzurufen:

  • TPU-Monitoring-Bibliothek: Mit der TPU-Monitoring-Bibliothek können Sie TPU-Laufzeitmesswerte aus dem LibTPU SDK abrufen. So können Ihre Anwendungen Telemetriedaten in Echtzeit aus der Gastumgebung abrufen. Weitere Informationen finden Sie unter TPU Monitoring Library.

  • AI Telemetry Collector: Mit dem AI Telemetry Collector können Sie Laufzeitmesswerte und VM-Infrastrukturmesswerte abrufen. Der AI Telemetry Collector wird in der TPU-VM ausgeführt und ermöglicht Ihnen den Zugriff auf Messwerte über Cloud Monitoring oder über Ihre eigene Prometheus-basierte Monitoring-Pipeline. Weitere Informationen finden Sie unter AI Telemetry Collector.

TPU-Messwerte

Messwerte inGoogle Cloud für Cloud TPU werden automatisch von Compute Engine-VMs und der Cloud TPU-Laufzeit generiert. Die Messwerte in der folgenden Tabelle werden von Compute Engine-VMs generiert.

Den Strings vom Typ „metric type“ in dieser Tabelle muss compute.googleapis.com/ vorangestellt werden. Dieses Präfix wurde in den Einträgen der Tabelle weggelassen. Verwenden Sie beim Abfragen eines Labels das Präfix metric.labels. Beispiel: metric.labels.LABEL="VALUE".

Messwerttyp Startphase (Ebenen der Ressourcenhierarchie)
Anzeigename
Art, Typ, Einheit
Überwachte Ressourcen
Beschreibung
Labels
instance/tpu/accelerator/duty_cycle BETA(Projekt)
Accelerator-Duty-Cycle
GAUGEDOUBLE%
gce_instance
Prozentsatz der Zeit im Stichprobenzeitraum, in der der Beschleuniger aktiv Daten verarbeitet hat. Die Werte liegen im Bereich [0,100].
accelerator_id: Geräte-ID des Beschleunigers.
instance/tpu/accelerator/memory_bandwidth_utilization BETA(Projekt)
Auslastung der Arbeitsspeicher-Bandbreite des Beschleunigers
GAUGEDOUBLE%
gce_instance
Aktueller Prozentsatz der verwendeten Arbeitsspeicherbandbreite des Beschleunigers. Wird berechnet, indem die in einem Stichprobenzeitraum verwendete Arbeitsspeicherbandbreite durch die maximal unterstützte Bandbreite im selben Stichprobenzeitraum geteilt wird.
accelerator_id: Geräte-ID des Beschleunigers.
instance/tpu/accelerator/memory_total BETA(Projekt)
Gesamtspeicher des Beschleunigers
GAUGEINT64By
gce_instance
Derzeit zugewiesener Gesamtspeicher des Beschleunigers in Byte.
accelerator_id: Geräte-ID des Beschleunigers.
instance/tpu/accelerator/memory_used BETA(Projekt)
Verwendeter Beschleunigerarbeitsspeicher
GAUGEINT64By
gce_instance
Derzeit verwendeter Gesamtspeicher des Beschleunigers in Byte.
accelerator_id: Geräte-ID des Beschleunigers.
instance/tpu/accelerator/tensorcore_utilization BETA(Projekt)
TensorCore-Auslastung des Accelerators
GAUGEDOUBLE%
gce_instance
Aktueller Prozentsatz des verwendeten TensorCore. Wird berechnet, indem die TensorCore-Vorgänge, die in einem Stichprobenzeitraum ausgeführt wurden, durch die unterstützte Anzahl von TensorCore-Vorgängen im selben Stichprobenzeitraum geteilt werden.
accelerator_id: Geräte-ID des Beschleunigers.
instance/tpu/active_chips BETA(Projekt)
Anzahl der aktiven TPU-Chips
GAUGEINT641
gce_instance
Die aktuelle Anzahl der Chips, die aktiv genutzt werden (d. h. nicht im Leerlauf sind).
accelerator_type: Beschleunigertyp und ‑generation.
reservation_id: Die ID der Reservierung für die physische Maschine.
provisioning_model: Das zugehörige Bereitstellungsmodell.
protection_tier: Das zugehörige Schutzmodell.
block_id: Die ID des Blocks im Cluster, in dem die VM gehostet wird.
subblock_id: Die ID des Unterblocks, auf dem die VM gehostet wird.
is_exr: (BOOL) Gibt an, ob der Chip Teil einer verlängerten Reservierung ist.
instance/tpu/chip_state BETA(Projekt)
Anzahl der TPU-Chip-Zustände
GAUGEINT641
gce_instance
Die Anzahl der TPU-Chips in verschiedenen Status wie „Fehlerfrei“, „Fehlerhaft“ und „Unbekannt“.
state: Der Status des Chips.
accelerator_type: Beschleunigertyp und ‑generation.
block_id: Die ID des Blocks im Cluster, in dem die VM gehostet wird.
subblock_id: Die ID des Unterblocks, auf dem die VM gehostet wird.
reservation_id: Die ID der Reservierung für die physische Maschine.
is_exr: (BOOL) Gibt an, ob der Chip Teil einer verlängerten Reservierung ist.
instance/tpu/infra_health BETA(Projekt)
TPU-Instanzstatus
GAUGEINT641
gce_instance
Gibt den allgemeinen Zustand einer TPU-Instanz an. Die Messwertlabels helfen dabei, den spezifischen Integritätsstatus und die Gründe für Probleme bei fehlerhaften oder nicht fehlerfreien TPU-Instanzen zu ermitteln. Dabei liegt der Schwerpunkt auf der TPU-Hardware und dem Systemzustand. Es kann einige Minuten dauern, bis Änderungen des Gesundheitsstatus in dieser Messgröße berücksichtigt werden. Alle 60 Sekunden wird eine Stichprobe erstellt. Nach der Stichprobe werden bis zu 420 Sekunden lang keine Daten angezeigt.
health_status: Der allgemeine Zustand der TPU-Instanz. Mögliche Werte: HEALTHY (funktioniert wie erwartet), UNHEALTHY (kritisches Problem erkannt), DEGRADED (Problem mit Auswirkungen auf die Leistung), UNKNOWN (Status kann nicht ermittelt werden).
unhealthy_category: Erklärung für den fehlerhaften VM-Status. Dieses Label wird nur ausgefüllt, wenn der Wert des Messwerts „Unhealthy“ (Nicht fehlerfrei) ist.
machine_type: Der Maschinentyp der Instanz (z.B. ct6e-standard-4t-tpu).
machine_id: Die ID des physischen Computers, auf dem die VM gehostet wird.
block_id: Die ID des Blocks im Cluster, in dem die VM gehostet wird.
cluster_id: Die ID des Clusters, auf dem die VM gehostet wird.
reservation_id: Die ID der Reservierung für die physische Maschine.
subblock_id: Die ID des Unterblocks, auf dem die VM gehostet wird.
instance/tpu/runtime/uptime BETA(Projekt)
Laufzeit-Uptime
GAUGEINT64s
gce_instance
Betriebszeit der ML-Laufzeit seit der Initialisierung der Laufzeitbibliothek (libtpu.so) durch den ML-Job. Während dieses Zeitraums blockiert die Laufzeitbibliothek die TPU-Geräte für die Verwendung durch den ML-Job.
ml_framework_name: Name des ML-Frameworks.
ml_framework_version: Version des ML-Frameworks.
instance/tpu/scheduled_chips BETA(Projekt)
Anzahl der geplanten TPU-Chips
GAUGEINT641
gce_instance
Die aktuelle Anzahl der Chips, die einer VM zugewiesen sind, die FEHLERFREI ist und NICHT für die Wartung DEAKTIVIERT wurde.
accelerator_type: Beschleunigertyp und ‑generation.
reservation_id: Die ID der Reservierung für die physische Maschine.
provisioning_model: Das zugehörige Bereitstellungsmodell.
protection_tier: Das zugehörige Schutzmodell.
block_id: Die ID des Blocks im Cluster, in dem die VM gehostet wird.
subblock_id: Die ID des Unterblocks, auf dem die VM gehostet wird.
is_exr: (BOOL) Gibt an, ob der Chip Teil einer verlängerten Reservierung ist.
instance/tpu/utilized_chips BETA(Projekt)
Verwendete TPU-Chips
GAUGEDOUBLE1
gce_instance
Die aktuelle aggregierte genutzte Kapazität, ausgedrückt als effektive Anzahl aktiver Chips. Sie entspricht der Summe der anteiligen Auslastung (0,0 bis 1,0) aller aktiven Chips.
accelerator_type: Beschleunigertyp und ‑generation.
reservation_id: Die ID der Reservierung für die physische Maschine.
provisioning_model: Das zugehörige Bereitstellungsmodell.
protection_tier: Das zugehörige Schutzmodell.
block_id: Die ID des Blocks im Cluster, in dem die VM gehostet wird.
subblock_id: Die ID des Unterblocks, auf dem die VM gehostet wird.
is_exr: (BOOL) Gibt an, ob der Chip Teil einer verlängerten Reservierung ist.
quota/tpus_per_tpu_family/exceeded ALPHA(project)
TPU count per TPU family. quota exceeded error
DELTAINT641
compute.googleapis.com/Location
Anzahl der Versuche, das Limit für den Kontingentmesswert „compute.googleapis.com/tpus_per_tpu_family“ zu überschreiten. Nach der Stichprobe werden bis zu 150 Sekunden lang keine Daten angezeigt.
limit_name: Der Name des Limits.
tpu_family: Benutzerdefinierte Dimension für die TPU-Familie.
quota/tpus_per_tpu_family/limit ALPHA(project)
TPU count per TPU family. quota limit
GAUGEINT641
compute.googleapis.com/Location
Aktuelles Limit für den Kontingentmesswert compute.googleapis.com/tpus_per_tpu_family. Alle 60 Sekunden wird eine Stichprobe erstellt. Nach der Stichprobe werden bis zu 150 Sekunden lang keine Daten angezeigt.
limit_name: Der Name des Limits.
tpu_family: Benutzerdefinierte Dimension für die TPU-Familie.
quota/tpus_per_tpu_family/usage ALPHA(project)
TPU count per TPU family. quota usage
GAUGEINT641
compute.googleapis.com/Location
Aktuelle Nutzung des Kontingentmesswerts compute.googleapis.com/tpus_per_tpu_family. Nach der Stichprobe werden bis zu 150 Sekunden lang keine Daten angezeigt.
limit_name: Der Name des Limits.
tpu_family: Benutzerdefinierte Dimension für die TPU-Familie.
tpu/multislice/accelerator/device_to_host_transfer_latencies BETA(Projekt)
Latenzen bei der Übertragung vom Gerät zum Host
CUMULATIVEDISTRIBUTIONus
gce_instance
Kumulative Verteilung der Geräte-zu-Host-Übertragungslatenz für jeden Datenblock. Eine Latenz beginnt, wenn die Anfrage zur Übertragung von Daten an den Host ausgegeben wird, und endet, wenn eine Bestätigung eingeht, dass die Datenübertragung abgeschlossen ist.
buffer_size: Puffergröße.
tpu/multislice/accelerator/host_to_device_transfer_latencies BETA(Projekt)
Latenzen bei der Übertragung vom Host zum Gerät
CUMULATIVEDISTRIBUTIONus
gce_instance
Kumulative Verteilung der Host-zu-Gerät-Übertragungslatenz für jeden Datenblock von Multi-Slice-Traffic. Eine Latenz beginnt, wenn die Anfrage zur Übertragung von Daten auf das Gerät gestellt wird, und endet, wenn eine Bestätigung eingeht, dass die Datenübertragung abgeschlossen ist.
buffer_size: Puffergröße.
tpu/multislice/network/collective_end_to_end_latencies BETA(Projekt)
Kollektive End-to-End-Latenzen
CUMULATIVEDISTRIBUTIONus
gce_instance
Kumulative Verteilung der Gesamt-End-to-End-Latenz für Multi-Slice-Traffic. Eine Latenz beginnt, wenn die Anfrage für die Sammlung ausgegeben wird, und endet, wenn eine Bestätigung eingeht, dass die Datenübertragung abgeschlossen ist.
input_size: Eingabegröße des kollektiven Vorgangs.
collective_type: Typ des kollektiven Vorgangs.
tpu/multislice/network/dcn_transfer_latencies BETA(Projekt)
DCN-Übertragungslatenzen
CUMULATIVEDISTRIBUTIONus
gce_instance
Kumulative Verteilung der Netzwerkübertragungslatenzen für Multi-Slice-Traffic. Eine Latenz beginnt, wenn die Anfrage zur Übertragung von Daten über das DCN gestellt wird, und endet, wenn eine Bestätigung eingeht, dass die Datenübertragung abgeschlossen ist.
buffer_size: Puffergröße.
type: Typ.
tpu/multislice/network/grpc_client_call_latencies BETA(Projekt)
Latenzen von gRPC-Clientaufrufen
CUMULATIVEDISTRIBUTIONus
gce_instance
Kumulative Verteilung der Latenzen für Netzwerkübertragungen, die die gRPC-Bibliothek benötigt, um einen RPC aus Sicht des Aufrufers abzuschließen.
buffer_size: Puffergröße.
tpu/multislice/network/grpc_server_call_latencies BETA(Projekt)
Latenzen von gRPC-Serveraufrufen
CUMULATIVEDISTRIBUTIONus
gce_instance
Kumulative Verteilung der Netzwerkübertragungslatenzen für den gRPC-Server, um einen RPC aus Transportsicht abzuschließen.
buffer_size: Puffergröße.
tpu/multislice/network/grpc_tcp_delivery_rates BETA(Projekt)
gRPC-TCP-Übertragungsraten
CUMULATIVEDISTRIBUTIONMb/s
gce_instance
Kumulative Verteilung der Datenübertragungsraten von TCP-Verbindungen. Jede Stichprobe ist die aktuelle durchschnittliche Datenübertragungsrate für eine bestimmte TCP-Verbindung über das letzte TCP-ACK-Intervall. Stichproben der Datenübertragungsraten werden alle 20 Sekunden aus dem Linux-TCP-Kernel gezogen. Daher ist zu erwarten, dass für jede TCP-Verbindung etwa 3 Stichproben pro 60-Sekunden-Intervall erstellt werden.
tpu/multislice/network/grpc_tcp_min_round_trip_times BETA(Projekt)
gRPC TCP Min Round Trip Times
CUMULATIVEDISTRIBUTIONus
gce_instance
Kumulative Verteilung der minimalen Netzwerkübertragungslatenzen pro TCP-Verbindung.
tpu/multislice/network/grpc_tcp_packets_retransmitted_count BETA(Projekt)
Anzahl der neu übertragenen gRPC-TCP-Pakete
CUMULATIVEINT641
gce_instance
Gesamtzahl der neu übertragenen Pakete.
tpu/multislice/network/grpc_tcp_packets_sent_count BETA(Projekt)
Anzahl der gesendeten gRPC-TCP-Pakete
CUMULATIVEINT641
gce_instance
Gesamtzahl der von TCP gesendeten Pakete.
tpu/slice/capacity/available_chips BETA(Projekt)
Anzahl der verfügbaren TPU-Chips
GAUGEINT641
compute.googleapis.com/AcceleratorSlice
Die aktuelle Anzahl der TPU-Chips der erweiterten Reservierung, die aktiv verfügbar und einsatzbereit sind. Alle 60 Sekunden wird eine Stichprobe erstellt. Nach der Stichprobe werden bis zu 360 Sekunden lang keine Daten angezeigt.
accelerator_type: Beschleunigertyp und ‑generation.
reservation_id: Die ID der Reservierung für die physische Maschine.
block_id: Die Block-ID, die dem Segment zugeordnet ist.
subblock_id: Die mit dem Slice verknüpfte Subblock-ID.
provisioning_model: Das zugehörige Bereitstellungsmodell.
protection_tier: Das zugehörige Schutzmodell.
tpu/slice/capacity/committed_chips BETA(Projekt)
Anzahl der gekauften TPU-Chips
GAUGEINT641
compute.googleapis.com/AcceleratorSlice
Die aktuelle Anzahl der gekauften TPU-Chips der erweiterten Reservierung. Alle 60 Sekunden wird eine Stichprobe erstellt. Nach der Stichprobe werden bis zu 360 Sekunden lang keine Daten angezeigt.
accelerator_type: Beschleunigertyp und ‑generation.
reservation_id: Die ID der Reservierung für die physische Maschine.
block_id: Die Block-ID, die dem Segment zugeordnet ist.
subblock_id: Die mit dem Slice verknüpfte Subblock-ID.
provisioning_model: Das zugehörige Bereitstellungsmodell.
protection_tier: Das zugehörige Schutzmodell.

Eine vollständige Liste der von Compute Engine generierten Messwerte finden Sie unter Compute Engine-Messwerte.

AI Telemetry Collector

Der AI Telemetry Collector erfasst und veröffentlicht TPU-Messwerte im Namespace compute.googleapis.com für TPUs, die mit der Compute Engine API erstellt wurden. Diese Messwerte sind integrierte Systemmesswerte, die Einblick in den Zustand und die Leistung geben.

Die Architektur des AI Telemetry Collector ist als schlanker, spezialisierter OpenTelemetry-Collector (OTEL) konzipiert. Es werden zwei primäre Empfänger zum Erfassen von Daten verwendet:

  • TPU-Laufzeit-Receiver: Ruft Laufzeit- und Arbeitslastmesswerte (z. B. Duty Cycle und Arbeitsspeichernutzung) direkt aus der TPU-Laufzeit ab, wenn eine ML-Arbeitslast aktiv ist.
  • TPU-Host-Receiver: Erfasst Hardwareauslastungsmesswerte wie TensorCore-Auslastung und Speicherbandbreitenauslastung direkt vom Gerät, unabhängig davon, ob eine Arbeitslast ausgeführt wird.

Der AI Telemetry Collector verwendet dann Prozessoren, um automatisch die erforderlichen Ressourcentags (z. B. project_id, instance_id und zone) anzuwenden und die Telemetrie sicher direkt nach Cloud Monitoring zu exportieren.

Der AI Telemetry Collector ist in den TPU-optimierten Ubuntu LTS-Images von Google vorinstalliert und wird automatisch beim Starten der VM ausgeführt. Wenn Sie diese Einrichtung verwenden möchten, geben Sie beim Erstellen einer TPU-VM-Instanz oder Instanzvorlage das offizielle Google-Beschleuniger-Image-Projekt und die entsprechende Familie an. Sobald die VM gestartet wird, sendet der AI Telemetry Collector automatisch Messwerte an Cloud Monitoring-Dashboards.

Wenn Sie benutzerdefinierte Betriebssystem-Images erstellen, können Sie den AI Telemetry Collector verwenden, nachdem Sie das ai-telemetry-collector-Docker-Image installiert und ausgeführt haben. Weitere Informationen finden Sie unter Benutzerdefiniertes Betriebssystem-Image verwenden.

Konfiguration

Der AI Telemetry Collector sendet Messwerte automatisch an Cloud Monitoring-Dashboards. Es sind keine zusätzlichen Konfigurationsschritte erforderlich. Sie können das Snap-Paket oder das Docker-Image jedoch so konfigurieren, dass externe Exportziele hinzugefügt, Messwerterfassungsintervalle geändert und Debugging-Optionen einbezogen werden.

Sie können entweder die Standardkonfiguration durch eine neue Konfigurationsdatei ersetzen oder der vorhandenen Standardkonfiguration eine zusätzliche Konfigurationsdatei anhängen. Beim Hinzufügen von Konfigurationen werden Schlüssel, die noch nicht vorhanden sind, hinzugefügt und vorhandene Schlüssel überschrieben. Arrays und Listen sind jedoch nicht additiv. Neue Listen müssen also sowohl vorhandene als auch neue Werte enthalten.

Die folgende YAML-Datei konfiguriert den AI Telemetry Collector so, dass Messwerte an Prometheus gesendet werden, ein Open-Source-Toolkit für die Systemüberwachung und Benachrichtigung. Außerdem wird die Debugging-Option aktiviert, mit der Messwerte in der Konsole ausgegeben werden.

exporters:
  prometheus:
    endpoint: 0.0.0.0:8889

service:
  pipelines:
    metrics:
      exporters:
      -   prometheus # For more: https://prometheus.io/docs/introduction/overview/
      -   googlecloud # If you do not include this, you'll lose Google Cloud Monitoring
      -   debug # print metrics within the console

Standardbetriebssystem

Wenn Sie die TPU-optimierten Ubuntu LTS-Images von Google verwenden, führen Sie den folgenden Snap-Befehl aus, um die neue Konfigurationsdatei der vorhandenen Konfiguration hinzuzufügen:

sudo snap set \
  ai-telemetry-collector \
  extra-flags="--config /home/username/additional-config.yaml"

Wenn Sie die vorhandene Konfiguration überschreiben und ersetzen möchten, verwenden Sie das Flag config-path anstelle von extra-flags:

sudo snap set \
  ai-telemetry-collector \
  config-path="/home/username/new-config.yaml"

Der Befehl snap set sollte einen automatischen Neustart des AI Telemetry Collector auslösen. Prüfen Sie mit dem folgenden Befehl, ob der Collector neu gestartet wurde und Ihre Konfigurationen erfolgreich angewendet wurden:

sudo snap logs -f ai-telemetry-collector

Benutzerdefiniertes Betriebssystem

Wenn Sie ein benutzerdefiniertes Betriebssystem verwenden, führen Sie den folgenden Docker-Befehl aus, um die neue Konfigurationsdatei zur vorhandenen Konfiguration hinzuzufügen:

# First apply the default configs via `--config=/etc/ai-telemetry-collector/config.yaml`
# Then apply your additional config by volume mount.

docker run --privileged --net=host                                                                   \
  -v <path>/additional-config.yaml:/etc/ai-telemetry-collector/additional-config.yaml \
  ai-telemetry-collector:latest                                                       \
  --config=/etc/ai-telemetry-collector/config.yaml                                    \
  --config=/etc/ai-telemetry-collector/additional-config.yaml

Wenn Sie die vorhandene Konfiguration überschreiben und ersetzen möchten, verwenden Sie den folgenden Docker-Befehl:

# Mount a volume (your config file) to `/etc/ai-telemetry-collector/config.yaml`
# The binary automatically picks up this file.

docker run --privileged --net=host                                               \
  -v <path>/my-config.yaml:/etc/ai-telemetry-collector/config.yaml   \
  ai-telemetry-collector:latest

Audit-Logs

Google Cloud -Dienste generieren Audit-Logs, in denen Verwaltungs- und Zugriffsaktivitäten in Ihren Google Cloud -Ressourcen aufgezeichnet werden. Weitere Informationen finden Sie unter Compute Engine-Audit-Logging.