Cloud Composer 1 befindet sich im Modus „Nach der Wartung“. Google veröffentlicht keine weiteren Updates für Cloud Composer 1, einschließlich neuer Versionen von Airflow sowie Fehlerkorrekturen und Sicherheitsupdates. Wir empfehlen die Migration zu Cloud Composer 2.
Auf dieser Seite wird beschrieben, wie Sie Cloud Composer insgesamt überwachen.
Status und Leistung der Umgebung mit wichtigen Messwerten im Monitoring-Dashboard.
Einleitung
In dieser Anleitung geht es um die wichtigsten Monitoring-Messwerte für Cloud Composer.
die einen guten Überblick
über den Zustand und die Leistung der Umgebung geben.
Cloud Composer bietet mehrere Messwerte, die den gesamten
Zustand der Umgebung. Die Monitoring-Richtlinien in dieser Anleitung basieren auf
für die im Monitoring-Dashboard bereitgestellten Messwerte
Ihrer Cloud Composer-Umgebung.
In diesem Tutorial lernen Sie die wichtigsten Messwerte kennen,
Hauptindikatoren für Probleme mit der Leistung und dem Zustand Ihrer Umgebung sind,
sowie die Richtlinien für die Interpretation der einzelnen Messwerte in Korrekturmaßnahmen, um
dass die Umwelt gesund bleibt. Außerdem richten Sie Benachrichtigungsregeln für die einzelnen
den Beispiel-DAG ausführen und mit diesen Messwerten und Benachrichtigungen den
und die Leistung Ihrer Umgebung.
Lernziele
Kosten
In dieser Anleitung werden die folgenden kostenpflichtigen Komponenten von Google Cloud verwendet:
Nach Abschluss dieser Anleitung können Sie weitere Kosten durch Löschen von erstellten Ressourcen vermeiden. Weitere Informationen finden Sie unter Bereinigen.
Hinweise
In diesem Abschnitt werden die Aktionen beschrieben, die vor dem Start der Anleitung erforderlich sind.
Projekt erstellen und konfigurieren
Für diese Anleitung benötigen Sie eine Google Cloud
Projekt erstellen.
Konfigurieren Sie das Projekt so:
Im Rahmen dieses Verfahrens
Sie gewähren die Dienst-Agent-Erweiterung für die Cloud Composer v2 API.
Rolle (roles/composer.ServiceAgentV2Ext) für den Composer-Dienst-Agent
Konto. Cloud Composer verwendet dieses Konto, um Vorgänge auszuführen
in Ihrem Google Cloud-Projekt.
Wichtige Messwerte für Zustand und Leistung der Umgebung entdecken
In diesem Tutorial geht es vorrangig um die
wichtigsten Messwerte, die Ihnen einen guten Überblick
des Zustands und der Leistung Ihrer Umgebung.
Das Monitoring-Dashboard in
Die Google Cloud Console enthält eine Vielzahl von Messwerten und Diagrammen, mit denen Sie
Trends in Ihrer Umgebung überwachen und Probleme mit Airflow identifizieren
und Cloud Composer-Ressourcen.
Jede Cloud Composer-Umgebung hat ein eigenes Monitoring
Dashboard.
Machen Sie sich mit den folgenden wichtigen Messwerten vertraut und suchen Sie sie im Monitoring-Dashboard:
Rufen Sie in der Google Cloud Console die Seite Umgebungen auf.
Klicken Sie in der Liste der Umgebungen auf den Namen Ihrer Umgebung.
Die Seite Umgebungsdetails wird geöffnet.
Rufen Sie den Tab Monitoring auf.
Wählen Sie den Abschnitt Übersicht aus und suchen Sie den Punkt Umgebungsübersicht auf der
des Dashboards und beobachten Sie die
Messwert Umgebungsstatus (Airflow-Monitoring-DAG):
Diese Zeitachse zeigt den Status von Cloud Composer.
zu verbessern. Die grüne Farbe der Leiste „Umweltzustand“
zeigt an, dass die Umgebung fehlerfrei ist, während der Status „Nicht gesund“ rot dargestellt wird.
Alle paar Minuten führt Cloud Composer einen Aktivitäts-DAG mit dem Namen
airflow_monitoring Wenn die Ausführung des Aktivitäts-DAG erfolgreich abgeschlossen wird,
Systemstatus ist True. Wenn die Ausführung des Aktivitäts-DAG fehlschlägt (z. B.
aufgrund von Pod-Bereinigung, Beendigung externer Prozesse oder Wartung)
Der Systemstatus lautet False.
Wählen Sie im Bereich SQL-Datenbank den Abschnitt Datenbankstatus aus.
im Dashboard und beobachten Sie den Messwert Datenbankzustand.
Diese Zeitachse zeigt den Status der Verbindung zum
Cloud SQL-Instanz Ihrer Umgebung. Die grüne Datenbank
Statusleiste zeigt Konnektivität an, während Verbindungsfehler
in Rot dargestellt.
Der Airflow-Monitoring-Pod pingt die Datenbank regelmäßig an und meldet
Status als True, wenn eine Verbindung hergestellt werden kann, oder als
False, wenn nicht.
Beobachten Sie im Element Datenbankzustand die CPU-Nutzung der Datenbank und
Messwerte zur Arbeitsspeichernutzung der Datenbank.
Das Diagramm zur CPU-Nutzung der Datenbank zeigt die Nutzung von CPU-Kernen durch den
Cloud SQL-Datenbankinstanzen Ihrer Umgebung im Vergleich zu den
das gesamte verfügbare CPU-Limit für die Datenbank.
Im Diagramm zur Arbeitsspeichernutzung der Datenbank wird die Arbeitsspeichernutzung durch den
Cloud SQL-Datenbankinstanzen Ihrer Umgebung im Vergleich zu den
Gesamtlimit für den verfügbaren Datenbankarbeitsspeicher.
Wählen Sie den Abschnitt Schedulers (Planer) aus und suchen Sie nach Scheduler Heartbeat.
im Dashboard und beobachten Sie den Messwert Scheduler Heartbeat.
Diese Zeitachse zeigt die
Status des Airflow-Planers.
Suchen Sie nach roten Bereichen, um Probleme mit Airflow-Planern zu identifizieren. Wenn Ihr
Umgebung mehr als einen Planer hat, ist der Heartbeat-Status
funktionieren, solange mindestens einer
der Planer antwortet.
Der Planer gilt als fehlerhaft, wenn der letzte Herzschlag empfangen wurde.
mehr als 30 Sekunden (Standardwert) vor der aktuellen Uhrzeit.
Wählen Sie den Abschnitt DAG-Statistiken aus und suchen Sie nach Zombie-Aufgaben beendet.
Element im Dashboard und beobachten Sie den Messwert Zombie Tasks killed.
Dieses Diagramm zeigt die Anzahl der getöteten Zombie-Aufgaben in einem
Zeitfenster. Zombie-Aufgaben werden häufig durch die externe Beendigung verursacht
von Airflow-Prozessen (z. B. wenn der Prozess einer Aufgabe beendet wird).
Der Airflow-Planer bricht Zombie-Aufgaben regelmäßig ab, was sich darauf
in diesem Diagramm.
Wählen Sie den Abschnitt Worker und den Abschnitt Worker-Container-Neustarts aus.
im Dashboard und achten Sie auf den Messwert Worker-Container-Neustarts.
Ein Diagramm zeigt die Gesamtzahl der Neustarts für einzelne Worker
Container. Zu viele Containerneustarts können die Verfügbarkeit
Ihrem Dienst oder anderen nachgelagerten Diensten,
die ihn als Abhängigkeit verwenden.
Benchmarks und mögliche Korrekturmaßnahmen für wichtige Messwerte kennenlernen
In der folgenden Liste werden Benchmarkwerte beschrieben, die auf Probleme und
finden Sie Korrekturmaßnahmen, die Sie ergreifen können, um diese Probleme zu beheben.
Umgebungszustand (Airflow-Monitoring-DAG)
Eine Erfolgsquote von weniger als 90% über einen Zeitraum von 4 Stunden
Fehler können Pod-Bereinigungen oder Beendigungen von Workern bedeuten, da
überlastet ist oder nicht richtig funktioniert. Rote Bereiche in der Umwelt
Die Zeitachse korreliert normalerweise mit den roten Bereichen in den anderen Gesundheitsbalken
der einzelnen Umgebungskomponenten. Die Grundursache identifizieren, indem
andere Messwerte im Monitoring-Dashboard prüfen.
Datenbankstatus
Eine Erfolgsquote von weniger als 95% über einen Zeitraum von 4 Stunden
Fehler bedeuten, dass es Probleme mit der Verbindung zu Airflow gibt.
Datenbank, die aufgrund eines Datenbankabsturzes oder
einer Ausfallzeit auftreten kann,
Die Datenbank ist überlastet (z. B. aufgrund einer hohen CPU- oder Speicherkapazität).
oder eine höhere Latenz beim Herstellen einer Verbindung zur Datenbank). Diese Symptome
werden am häufigsten durch suboptimale DAGs verursacht, z. B. wenn DAGs die Verwendung von
viele global definierte Airflow- oder Umgebungsvariablen. Die Wurzel ermitteln
indem Sie die Nutzungsmesswerte der SQL-Datenbankressource überprüfen. Sie können auch die Planerlogs auf Fehler im Zusammenhang mit der Datenbankverbindung prüfen.
CPU- und Arbeitsspeichernutzung der Datenbank
Mehr als 80% der durchschnittlichen CPU- oder Arbeitsspeichernutzung innerhalb eines 12-Stunden-Fensters
Die Datenbank ist möglicherweise überlastet. Korrelation zwischen DAG analysieren
und Spitzen bei der CPU- oder Speichernutzung
für die Datenbank verursacht.
Alternativ können Sie der Datenbank mehr CPU oder Arbeitsspeicher zuweisen.
Datenbankressourcen werden über das Attribut für die Umgebungsgröße von
und die Umgebung muss
auf eine größere Größe skaliert werden.
Planer-Heartbeat
Eine Erfolgsquote von weniger als 90% über einen Zeitraum von 4 Stunden
Weisen Sie dem Planer mehr Ressourcen zu oder erhöhen Sie die Anzahl der Planer
zwischen 1 und 2 (empfohlen).
Zombie-Aufgaben gelöscht
Mehr als eine Zombie-Aufgabe pro 24 Stunden
Der häufigste Grund für Zombie-Aufgaben ist ein Mangel an CPU oder Arbeitsspeicher
Ressourcen im Cluster Ihrer Umgebung. Nutzung von Worker-Ressourcen prüfen
Grafiken erstellen und den Workern weitere Ressourcen zuweisen.
Zeitlimit für Zombie-Aufgaben erhöhen
damit der Planer länger wartet, bevor er eine Aufgabe als Zombie betrachtet.
Neustarts von Worker-Containern
Mehr als ein Neustart pro 24 Stunden
Der häufigste Grund ist ein Mangel an Worker-Arbeitsspeicher oder -Speicher. Sehen Sie sich
Verbrauch von Worker-Ressourcen und Zuweisen von mehr Arbeitsspeicher oder Speicher
für Ihre Mitarbeiter. Wenn der Mangel an Ressourcen nicht der Grund ist,
Fehlerbehebung bei Vorfällen beim Neustart von Workern
und verwenden Sie
Logging von Abfragen
um die Gründe für Worker-Neustarts zu ermitteln.
Erstellen Sie Benachrichtigungsrichtlinien anhand der im vorherigen Abschnitt bereitgestellten Benchmarks.
dieses Tutorials, um die Werte
von Messwerten kontinuierlich zu überwachen und
Benachrichtigungen erhalten, wenn diese Messwerte gegen eine Bedingung verstoßen.
Console
Sie können Benachrichtigungen für jeden im Monitoring-Dashboard angezeigten Messwert einrichten, indem Sie
Klicken Sie auf das Glockensymbol in der Ecke des entsprechenden Elements:
<ph type="x-smartling-placeholder"></ph>
Abbildung 1: Benachrichtigung für einen Messwert erstellen, der auf dem Monitoring-Dashboard angezeigt wird (zum Vergrößern klicken)
Suchen Sie im Monitoring alle Messwerte, die Sie beobachten möchten.
Dashboard und klicken Sie in der Ecke des Messwertelements auf das Glockensymbol. Die
Die Seite Benachrichtigungsrichtlinie erstellen wird geöffnet.
Im Abschnitt Daten transformieren:
Konfigurieren Sie den Abschnitt Innerhalb jeder Zeitreihe wie in den
Konfiguration von Benachrichtigungsrichtlinien für den Messwert.
Klicken Sie auf Weiter und konfigurieren Sie den Bereich Trigger für Benachrichtigungen konfigurieren.
enthalten, wie in der Konfiguration der Benachrichtigungsrichtlinien für den Messwert beschrieben.
Klicken Sie auf Weiter.
Konfigurieren Sie die Benachrichtigungen. Maximieren Sie das Menü Benachrichtigungskanäle.
und wählen Sie die Benachrichtigungskanäle aus, die Sie im
vorherigen Schritt.
Klicken Sie auf OK.
Geben Sie im Abschnitt Benachrichtigungsrichtlinie benennen das Feld Name der Benachrichtigungsrichtlinie ein.
ein. Verwenden Sie für jeden Messwert einen aussagekräftigen Namen. Verwenden Sie die Funktion
Benachrichtigungsrichtlinie“ Wert entsprechend der Beschreibung in der Konfiguration der Benachrichtigungsrichtlinien
für den Messwert aus.
Klicken Sie auf Weiter.
Überprüfen Sie die Benachrichtigungsrichtlinie und klicken Sie auf Richtlinie erstellen.
Messwert für den Umgebungsstatus (Airflow-Monitoring-DAG) – Konfigurationen der Benachrichtigungsrichtlinien
Daten transformieren > Innerhalb jeder Zeitreihe:
Rollierendes Fenster: Benutzerdefiniert
Benutzerdefinierter Wert: 4
Benutzerdefinierte Einheiten: Stunde(n)
Funktion für rollierendes Fenster: Anzahl
Konfigurieren Sie den Benachrichtigungstrigger:
Bedingungstypen: Grenzwert
Trigger für Benachrichtigung: „Any timeseries verstößt“
Grenzwertposition: unter Grenzwert
Grenzwert: 216
Sie können diese Zahl ermitteln, indem Sie eine Abfrage ausführen, die Werte aggregiert
_scheduler_heartbeat_count_mean im
Metrics Explorer-Abfrageeditor:
Bedingungsname: Planer-Heartbeat-Bedingung
Konfigurieren Sie Benachrichtigungen und schließen Sie die Benachrichtigung ab:
Benennen Sie die Benachrichtigungsrichtlinie: Airflow Scheduler Heartbeat
Messwert für beendete Zombie-Aufgaben – Konfigurationen von Benachrichtigungsrichtlinien
Daten transformieren > Innerhalb jeder Zeitreihe:
Rollierendes Zeitfenster: 1 Tag
Funktion des rollierenden Fensters: Summe
Konfigurieren Sie den Benachrichtigungstrigger:
Bedingungstypen: Grenzwert
Trigger für Benachrichtigung: „Any timeseries verstößt“
Grenzwertposition: über Grenzwert
Grenzwert: 1
Bedingungsname: Zombie-Aufgabenbedingung
Konfigurieren Sie Benachrichtigungen und schließen Sie die Benachrichtigung ab:
Benennen Sie die Benachrichtigungsrichtlinie: Airflow-Zombie-Tasks
Terraform
Terraform-Skript ausführen, das einen E-Mail-Benachrichtigungskanal erstellt und Uploads erstellt
für die wichtigsten Messwerte, die in dieser Anleitung bereitgestellt werden, basierend auf
ihre jeweiligen Benchmarks:
Speichern Sie die Terraform-Beispieldatei auf Ihrem lokalen Computer.
Ersetzen Sie Folgendes:
PROJECT_ID: die Projekt-ID
Ihres Projekts. Beispiel: example-project
EMAIL_ADDRESS: die E-Mail-Adresse, die benachrichtigt werden muss, wenn ein
Benachrichtigung ausgelöst.
ENVIRONMENT_NAME: der Name Ihrer Cloud Composer-Umgebung.
Beispiel: example-composer-environment.
CLUSTER_NAME: Name Ihres Umgebungsclusters, unter dem Sie zu finden sind
Umgebungskonfiguration > Ressourcen > GKE
in der Google Cloud Console erstellen.
resource "google_monitoring_notification_channel" "basic" {
project = "PROJECT_ID"
display_name = "Test Notification Channel"
type = "email"
labels = {
email_address = "EMAIL_ADDRESS"
}
# force_delete = false
}
resource "google_monitoring_alert_policy" "environment_health_metric" {
project = "PROJECT_ID"
display_name = "Airflow Environment Health"
combiner = "OR"
notification_channels = [google_monitoring_notification_channel.basic.name] // To manually add a notification channel add it with the syntax "projects/[PROJECT_ID]/notificationChannels/[CHANNEL_ID]"
conditions {
display_name = "Environment health condition"
condition_threshold {
filter = "resource.type = \"cloud_composer_environment\" AND metric.type=\"composer.googleapis.com/environment/healthy\" AND resource.label.environment_name=\"ENVIRONMENT_NAME\""
duration = "60s"
comparison = "COMPARISON_LT"
threshold_value = 0.9
aggregations {
alignment_period = "14400s"
per_series_aligner = "ALIGN_FRACTION_TRUE"
}
}
}
}
resource "google_monitoring_alert_policy" "database_health_metric" {
project = "PROJECT_ID"
display_name = "Airflow Database Health"
combiner = "OR"
notification_channels = [google_monitoring_notification_channel.basic.name] // To manually add a notification channel add it with the syntax "projects/[PROJECT_ID]/notificationChannels/[CHANNEL_ID]"
conditions {
display_name = "Database health condition"
condition_threshold {
filter = "resource.type = \"cloud_composer_environment\" AND metric.type=\"composer.googleapis.com/environment/database_health\" AND resource.label.environment_name=\"ENVIRONMENT_NAME\""
duration = "60s"
comparison = "COMPARISON_LT"
threshold_value = 0.95
aggregations {
alignment_period = "14400s"
per_series_aligner = "ALIGN_FRACTION_TRUE"
}
}
}
}
resource "google_monitoring_alert_policy" "alert_database_cpu_usage" {
project = "PROJECT_ID"
display_name = "Airflow Database CPU Usage"
combiner = "OR"
notification_channels = [google_monitoring_notification_channel.basic.name] // To manually add a notification channel add it with the syntax "projects/[PROJECT_ID]/notificationChannels/[CHANNEL_ID]"
conditions {
display_name = "Database CPU usage condition"
condition_threshold {
filter = "resource.type = \"cloud_composer_environment\" AND metric.type=\"composer.googleapis.com/environment/database/cpu/utilization\" AND resource.label.environment_name=\"ENVIRONMENT_NAME\""
duration = "60s"
comparison = "COMPARISON_GT"
threshold_value = 80
aggregations {
alignment_period = "43200s"
per_series_aligner = "ALIGN_MEAN"
}
}
}
}
resource "google_monitoring_alert_policy" "alert_database_memory_usage" {
project = "PROJECT_ID"
display_name = "Airflow Database Memory Usage"
combiner = "OR"
notification_channels = [google_monitoring_notification_channel.basic.name] // To manually add a notification channel add it with the syntax "projects/[PROJECT_ID]/notificationChannels/[CHANNEL_ID]"
conditions {
display_name = "Database memory usage condition"
condition_threshold {
filter = "resource.type = \"cloud_composer_environment\" AND metric.type=\"composer.googleapis.com/environment/database/memory/utilization\" AND resource.label.environment_name=\"ENVIRONMENT_NAME\""
duration = "60s"
comparison = "COMPARISON_GT"
threshold_value = 80
aggregations {
alignment_period = "43200s"
per_series_aligner = "ALIGN_MEAN"
}
}
}
}
resource "google_monitoring_alert_policy" "alert_scheduler_heartbeat" {
project = "PROJECT_ID"
display_name = "Airflow Scheduler Heartbeat"
combiner = "OR"
notification_channels = [google_monitoring_notification_channel.basic.name] // To manually add a notification channel add it with the syntax "projects/[PROJECT_ID]/notificationChannels/[CHANNEL_ID]"
conditions {
display_name = "Scheduler heartbeat condition"
condition_threshold {
filter = "resource.type = \"cloud_composer_environment\" AND metric.type=\"composer.googleapis.com/environment/scheduler_heartbeat_count\" AND resource.label.environment_name=\"ENVIRONMENT_NAME\""
duration = "60s"
comparison = "COMPARISON_LT"
threshold_value = 216 // Threshold is 90% of the average for composer.googleapis.com/environment/scheduler_heartbeat_count metric in an idle environment
aggregations {
alignment_period = "14400s"
per_series_aligner = "ALIGN_COUNT"
}
}
}
}
resource "google_monitoring_alert_policy" "alert_zombie_task" {
project = "PROJECT_ID"
display_name = "Airflow Zombie Tasks"
combiner = "OR"
notification_channels = [google_monitoring_notification_channel.basic.name] // To manually add a notification channel add it with the syntax "projects/[PROJECT_ID]/notificationChannels/[CHANNEL_ID]"
conditions {
display_name = "Zombie tasks condition"
condition_threshold {
filter = "resource.type = \"cloud_composer_environment\" AND metric.type=\"composer.googleapis.com/environment/zombie_task_killed_count\" AND resource.label.environment_name=\"ENVIRONMENT_NAME\""
duration = "60s"
comparison = "COMPARISON_GT"
threshold_value = 1
aggregations {
alignment_period = "86400s"
per_series_aligner = "ALIGN_SUM"
}
}
}
}
resource "google_monitoring_alert_policy" "alert_worker_restarts" {
project = "PROJECT_ID"
display_name = "Airflow Worker Restarts"
combiner = "OR"
notification_channels = [google_monitoring_notification_channel.basic.name] // To manually add a notification channel add it with the syntax "projects/[PROJECT_ID]/notificationChannels/[CHANNEL_ID]"
conditions {
display_name = "Worker container restarts condition"
condition_threshold {
filter = "resource.type = \"k8s_container\" AND (resource.labels.cluster_name = \"CLUSTER_NAME\" AND resource.labels.container_name = monitoring.regex.full_match(\"airflow-worker|base\") AND resource.labels.pod_name = monitoring.regex.full_match(\"airflow-worker-.*|airflow-k8s-worker-.*\")) AND metric.type = \"kubernetes.io/container/restart_count\""
duration = "60s"
comparison = "COMPARISON_GT"
threshold_value = 1
aggregations {
alignment_period = "86400s"
per_series_aligner = "ALIGN_RATE"
}
}
}
}
Benachrichtigungsrichtlinien testen
In diesem Abschnitt wird beschrieben, wie Sie die erstellten Benachrichtigungsrichtlinien testen und interpretieren
Ergebnisse.
Beispiel-DAG hochladen
Der in dieser Anleitung angegebene Beispiel-DAG memory_consumption_dag.py imitiert
und einer hohen Auslastung
des Worker-Arbeitsspeichers. Der DAG enthält vier Aufgaben, die jeweils
Tasks schreibt Daten in einen Musterstring und beansprucht 380 MB Arbeitsspeicher. Das Beispiel
Der DAG wird alle zwei Minuten ausgeführt und beginnt automatisch
sobald Sie es in Ihre Composer-Umgebung hochgeladen haben.
from datetime import datetime
import sys
import time
from airflow import DAG
from airflow.operators.python import PythonOperator
def ram_function():
data = ""
start = time.time()
for i in range(38):
data += "a" * 10 * 1000**2
time.sleep(0.2)
print(f"{i}, {round(time.time() - start, 4)}, {sys.getsizeof(data) / (1000 ** 3)}")
print(f"Size={sys.getsizeof(data) / (1000 ** 3)}GB")
time.sleep(30 - (time.time() - start))
print(f"Complete in {round(time.time() - start, 2)} seconds!")
with DAG(
dag_id="memory_consumption_dag",
start_date=datetime(2023, 1, 1, 1, 1, 1),
schedule="1/2 * * * *",
catchup=False,
) as dag:
for i in range(4):
PythonOperator(
task_id=f"task_{i+1}",
python_callable=ram_function,
retries=0,
dag=dag,
)
Benachrichtigungen und Messwerte in Monitoring interpretieren
Warten Sie etwa zehn Minuten, nachdem der Beispiel-DAG ausgeführt wurde, und bewerten Sie den
Testergebnisse:
Sehen Sie in Ihrem E-Mail-Postfach nach, ob Sie eine Benachrichtigung von
Google Cloud-Benachrichtigungen mit einer Betreffzeile, die mit [ALERT] beginnt.
Der Inhalt dieser Nachricht enthält die Details zum Vorfall in der Benachrichtigungsrichtlinie.
Klicken Sie in der E-Mail-Benachrichtigung auf die Schaltfläche Vorfall ansehen. Sie sind
werden zum Metrics Explorer weitergeleitet. Überprüfen Sie die Details der Benachrichtigung
Vorfall:
<ph type="x-smartling-placeholder"></ph>
Abbildung 2: Details zum Benachrichtigungsvorfall (zum Vergrößern klicken)
Im Diagramm mit den Vorfallsmesswerten ist zu sehen, dass die von Ihnen erstellten Messwerte die
der Schwellenwert 1, d. h. Airflow hat mehr als 1 Zombie erkannt und getötet
.
Wechseln Sie in der Cloud Composer-Umgebung zum Tab Monitoring.
Öffnen Sie den Bereich DAG-Statistiken und suchen Sie nach den abgelegten Zombie-Aufgaben.
Grafik:
<ph type="x-smartling-placeholder"></ph>
Abbildung 3: Grafik zu Zombie-Aufgaben (zum Vergrößern klicken)
Das Diagramm zeigt, dass Airflow etwa 20 Zombie-Aufgaben in nur
ersten 10 Minuten der Ausführung des Beispiel-DAG.
Laut den Benchmarks und Korrekturmaßnahmen
ist der häufigste Grund
für Zombie-Aufgaben ist der Mangel an Worker-Arbeitsspeicher oder CPU-Kapazität. Grundursache ermitteln
von Zombie-Aufgaben durch Analysieren der Auslastung Ihrer Worker-Ressourcen.
Öffnen Sie in Ihrem Monitoring-Dashboard den Abschnitt „Worker“ und prüfen Sie den Worker
Messwerte zur CPU- und Arbeitsspeichernutzung:
<ph type="x-smartling-placeholder"></ph>
Abbildung 4: Messwerte zur CPU- und Arbeitsspeichernutzung für Worker (zum Vergrößern klicken)
Das Diagramm zur CPU-Nutzung der Worker insgesamt zeigt an, dass die CPU-Auslastung der Worker betrug
unter 50% des gesamten verfügbaren Limits liegen, sodass die
ist ausreichend. Das Diagramm "Gesamte Arbeitsspeichernutzung der Worker" zeigt, dass die Ausführung der
Beispiel-DAG führte dazu, dass das Limit für den zuweisbaren Arbeitsspeicher erreicht wurde,
75% des gesamten Arbeitsspeicherlimits, das in der Grafik dargestellt ist,
(GKE reserviert 25% der ersten 4 GiB Arbeitsspeicher und
zusätzliche 100 MiB Arbeitsspeicher auf jedem Knoten für die Pod-Bereinigung).
Sie können daraus schließen, dass den Workern nicht genügend Arbeitsspeicherressourcen zum Ausführen der
Beispiel-DAG erfolgreich.
Umgebung optimieren und Leistung bewerten
Basierend auf der Analyse der Worker-Ressourcennutzung müssen Sie mehr zuweisen
damit alle Aufgaben in Ihrem DAG erfolgreich sind.
Öffnen Sie in Ihrer Composer-Umgebung den Tab DAGs und klicken Sie auf den Namen des
Beispiel-DAG (memory_consumption_dag) und dann auf DAG pausieren.
Zusätzlichen Worker-Arbeitsspeicher zuweisen:
Suchen Sie im Tab „Umgebungskonfiguration“ nach Ressourcen.
> Konfiguration der Arbeitslasten und klicken Sie auf Bearbeiten.
Erhöhen Sie im Element Worker das Arbeitsspeicherlimit. In dieser Anleitung
3,25 GB Speicherplatz belegt.
Speichern Sie die Änderungen und warten Sie einige Minuten, bis der Worker neu gestartet wird.
Öffnen Sie den Tab „DAGs“ und klicken Sie auf den Namen des Beispiel-DAG.
(memory_consumption_dag) und klicken Sie auf Pausieren des DAG aufheben.
Gehen Sie zu Monitoring und prüfen Sie, ob nach dem Start keine neuen Zombie-Aufgaben mehr angezeigt wurden.
hat Ihre Worker-Ressourcenlimits aktualisiert:
<ph type="x-smartling-placeholder"></ph>
Abbildung 5: Grafik zu Zombie-Aufgaben nach Änderung des Arbeitsspeicherlimits (zum Vergrößern klicken)
Fazit
In dieser Anleitung haben Sie die wichtigsten Funktionen
wie Sie Benachrichtigungsrichtlinien
für die einzelnen Messwerte einrichten
um jeden Messwert als Korrekturmaßnahmen zu interpretieren. Anschließend haben Sie
einen Beispiel-DAG ausgeführt,
die Ursache von Problemen zum Zustand der Umgebung mithilfe von Warnmeldungen erkannt
und Monitoring-Diagrammen erstellen und Ihre Umgebung durch Zuweisen von mehr Arbeitsspeicher
für Ihre Mitarbeiter. Es wird jedoch empfohlen,
DAGs optimieren
den Ressourcenverbrauch der Worker zu reduzieren,
um die Ressourcen über einen
bestimmten Schwellenwert hinaus zu erhöhen.
Bereinigen
Um zu vermeiden, dass Ihrem Google Cloud-Konto die Ressourcen in Rechnung gestellt werden
Löschen Sie entweder das Projekt, das die Ressourcen enthält,
oder das Projekt behalten und die einzelnen Ressourcen löschen.
Projekt löschen
Wechseln Sie in der Google Cloud Console zur Seite Ressourcen verwalten.
Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.
Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Shut down (Beenden), um das Projekt zu löschen.
Einzelne Ressourcen löschen
Wenn Sie mehrere Anleitungen und Kurzanleitungen durcharbeiten möchten, können Sie die Überschreitung von Projektkontingenten verhindern, indem Sie Projekte wiederverwenden.
Ihr Terraform-Skript darf keine Einträge für
Ressourcen, die für Ihr Projekt noch benötigt werden. Zum Beispiel haben Sie
möchten vielleicht einige APIs aktiviert lassen und
Berechtigungen zugewiesen sind (sofern Sie diese Definitionen
Terraform-Script.
Führen Sie terraform destroy aus.
Löschen Sie den Bucket der Umgebung manuell. Cloud Composer
nicht automatisch gelöscht. Sie können es von
mit der Google Cloud Console
oder der Google Cloud CLI.
