Ereignistypen

In diesem Dokument werden die Ereignistypen beschrieben, die als Annotationen angezeigt werden können in Diagrammen. Ein Ereignis ist eine Aktivität, z. B. ein Neustart oder ein Absturz, die sich auf den Betrieb eines Systems. Wenn Sie Ereignisse einblenden, können Sie leichter den Zusammenhang Daten aus verschiedenen Quellen verwenden, ein Problem zu lösen.

Für jedes Ereignis sind Links zu Referenzen oder der Dokumentation zur Fehlerbehebung aufgeführt. zusammen mit Informationen zur Abfrage des Ereignisses bereitgestellt. Wenn beispielsweise Ereignisse durch die Analyse Ihrer Logs identifiziert werden, eine Abfrage, die sich für den Log-Explorer oder mit einem logbasierten Benachrichtigungsrichtlinie bereitgestellt.

Um Ihren Diagrammen Anmerkungen hinzuzufügen, müssen Sie das Dashboard oder den Tab konfigurieren auf dem das Diagramm angezeigt wird. Sie können beispielsweise die meisten Dashboards der Google Cloud Console auf der Seite Dashboards, um Ereignisse anzuzeigen. Ebenso können Sie einige dienstspezifische Tabs für die Beobachtbarkeit konfigurieren, wie die für Compute Engine und Google Kubernetes Engine, um Ereignisse anzuzeigen. Informationen zur Konfiguration finden Sie unter Ereignisse auf einem Dashboard anzeigen

Der folgende Screenshot zeigt ein Diagramm mit mehreren Ereignisse, die durch die Analyse von Logeinträgen identifiziert wurden, und Service Health-Ereignis:

Jede Anmerkung kann mehrere Ereignisse enthalten. Im vorherigen Screenshot wird ein Ereignis für ein GKE-Deployment aufgeführt.

Hinweis :Auf dem Rest dieser Seite werden die unterstützten Ereignistypen aufgeführt. durch Dashboards. Dienstspezifische Tabs für Beobachtbarkeit unterstützen in der Regel nur eine Teilmenge dieser Ereignistypen.

Ereignistypen für Benachrichtigungen

In diesem Abschnitt werden die Ereignistypen für Benachrichtigungen beschrieben, die auf einem Dashboard.

Benachrichtigung geöffnet

Geöffnete Benachrichtigungsereignisse helfen Ihnen, Ihre Diagrammdaten incidents geöffnet. Ein Ereignis, das eine Benachrichtigung geöffnet hat, wird angezeigt, wenn die folgenden Bedingungen erfüllt sind:

• Der entsprechende Vorfall wurde im angegebenen Zeitraum geöffnet über das Dashboard.
• Der entsprechende Vorfall ist nicht geschlossen.

Für Vorfälle, die außerhalb des die vom Dashboard vorgegebene Zeitspannen festgelegt werden, werden nicht angezeigt. Ähnlich verhält es sich bei einem Ereignis „Benachrichtigung geöffnet“ wird nicht angezeigt, wenn der entsprechende Vorfall geöffnet wurde und dann innerhalb des vom Dashboard angegebenen Zeitraums geschlossen.

Die Kurzinfo für ein Ereignis, das eine Benachrichtigung geöffnet hat, enthält Folgendes:

• Name der Benachrichtigungsrichtlinie.
• Zusammenfassende Informationen, sofern diese Informationen verfügbar sind. Zum Beispiel wie der Schwellenwert und der gemessene Wert.
• Dauer des Vorfalls sowie Datum und Uhrzeit wann der Vorfall geöffnet wurde.
• Messwert- und Ressourcenlabels. In der Kurzinfo werden möglicherweise nicht alle Labels angezeigt.
• Eine Schaltfläche Anzeigen, über die die Seite Details für den Vorfall geöffnet wird

Google Kubernetes Engine-Ereignistypen

In diesem Abschnitt werden die Google Kubernetes Engine-Ereignistypen beschrieben, die Sie die auf einem Dashboard angezeigt werden.

Gepatchte oder aktualisierte GKE-Arbeitslast

Dieser Ereignistyp hilft Ihnen bei der Fehlerbehebung in GKE die Bereitstellung von Arbeitslasten oder Änderungen an Statefulset, da diese Ereignisse mit Leistungsabfälle oder andere Leistungsprobleme auftreten. Dieser Ereignistyp wird angezeigt Eine Arbeitslast wird erstellt, aktualisiert oder gelöscht.

Wenn Sie Erstellen Sie eine logbasierte Benachrichtigungsrichtlinie dafür. und verwenden Sie die folgende Abfrage:

resource.type=k8s_cluster protoPayload.methodName=(
    io.k8s.apps.v1.deployments.create OR io.k8s.apps.v1.deployments.patch OR
    io.k8s.apps.v1.deployments.update OR io.k8s.apps.v1.deployments.delete OR
    io.k8s.apps.v1.deployments.deletecollection OR io.k8s.apps.v1.statefulsets.create OR
    io.k8s.apps.v1.statefulsets.patch OR io.k8s.apps.v1.statefulsets.update OR
    io.k8s.apps.v1.statefulsets.delete OR io.k8s.apps.v1.statefulsets.deletecollection OR
    io.k8s.apps.v1.daemonsets.create OR io.k8s.apps.v1.daemonsets.patch OR
    io.k8s.apps.v1.daemonsets.update OR io.k8s.apps.v1.daemonsets.delete OR
    io.k8s.apps.v1.daemonsets.deletecollection
)
-protoPayload.authenticationInfo.principalEmail="system:addon-manager"
-protoPayload.request.metadata.namespace=(kube-system OR gmp-system OR gmp-public OR gke-gmp-system)

Weitere Informationen finden Sie unter Übersicht über das Bereitstellen von Arbeitslasten und Beobachtbarkeitsmesswerte ansehen.

Absturz eines GKE-Pods

Mithilfe dieses Ereignistyps können Sie GKE-Pod-Abstürze. Pod-Abstürze können durch Speicherausschöpfung oder einen Anwendungsfehler verursacht werden. Dieser Ereignistyp wird in folgenden Fällen angezeigt:

• Pod-Status ist CrashLoopBackoff
• Der Pod endet mit einem Exit-Code ungleich null.
• Der Pod endet mit einer Bedingung des unzureichenden Arbeitsspeichers.
• Pod wurde entfernt.
• Bereitschafts-/Aktivitätsprüfung schlägt fehl.

Wenn Sie Erstellen Sie eine logbasierte Benachrichtigungsrichtlinie dafür. und verwenden Sie die folgende Abfrage:

(
    log_id(events)
    (
        (resource.type=k8s_pod jsonPayload.reason=(BackOff OR Unhealthy OR Killing OR Evicted)) OR
        (resource.type=k8s_node jsonPayload.reason=OOMKilling)
    )
    severity=WARNING
) OR (
    log_id(cloudaudit.googleapis.com%2Factivity) resource.type=k8s_cluster
    (protoPayload.methodName=io.k8s.core.v1.pods.eviction.create OR
        (protoPayload.methodName=io.k8s.core.v1.pods.delete
        protoPayload.response.status.containerStatuses.state.terminated.exitCode:*
        -protoPayload.response.status.containerStatuses.state.terminated.exitCode=0
        )
    )
)

Informationen zur Fehlerbehebung finden Sie unter Fehlerbehebung: CrashLoopBackOff

Fehler beim Planen eines GKE-Pods

Mit diesem Ereignistyp können Sie ermitteln, wann Pods, die nicht für einen Knoten geplant. Dieser Ereignistyp wird angezeigt, wenn die Pod-Planung fehlschlägt aus einem der folgenden Gründe:

• Unzureichende Knoten-CPU.
• Nicht genügend Knotenarbeitsspeicher.
• Keine Knoten für Markierungen oder Toleranzen.
• Knoten mit dem maximalen Pod-Limit.
• Knotenpool mit maximaler Größe.

Wenn Sie Erstellen Sie eine logbasierte Benachrichtigungsrichtlinie dafür. und verwenden Sie die folgende Abfrage:

(
    log_id(events) resource.type=k8s_pod jsonPayload.reason=(NotTriggerScaleUp OR FailedScheduling)
) OR (
    log_id(container.googleapis.com/cluster-autoscaler-visibility)
    resource.type=k8s_cluster jsonPayload.noDecisionStatus.noScaleUp:*
)

Informationen zur Fehlerbehebung finden Sie unter Fehlerbehebung: Pod nicht planbar

Fehler beim Erstellen eines GKE-Containers

Mit diesem Ereignistyp können Sie Fehler identifizieren und beheben, GKE-Container. Die Containererstellung kann aus folgenden Gründen fehlschlagen: wie fehlgeschlagene Volume-Bereitstellungen oder Image-Abrufe.

Wenn Sie Erstellen Sie eine logbasierte Benachrichtigungsrichtlinie dafür. Ereignistyp und verwenden Sie dann die folgende Abfrage:

log_id(events) resource.type=k8s_pod jsonPayload.reason=(Failed OR FailedMount) severity=WARNING

Informationen zur Fehlerbehebung finden Sie unter Fehlerbehebung: ImagePullBackOff und ErrImagePull

Pod-Autoscaling nach oben und unten skalieren

Durch dieses Ereignis erhalten Sie Einblick in die Skalierungen des horizontalen Pod-Autoscaling, Erhöhen oder verringern Sie die Anzahl der ausgeführten Pods für eine Arbeitslast. Weitere Informationen finden Sie unter Horizontales Pod-Autoscaling.

Wenn Sie Erstellen Sie eine logbasierte Benachrichtigungsrichtlinie dafür. und verwenden Sie die folgende Abfrage:

resource.type=k8s_cluster log_id(events)
jsonPayload.involvedObject.kind=HorizontalPodAutoscaler jsonPayload.reason=SuccessfulRescale

Cluster Autoscaler zum Hoch- und Herunterskalieren

Dieses Ereignis gibt Aufschluss darüber, wann Cluster Autoscaler hochskaliert oder die Anzahl der Knoten in einem Knotenpool Ihres Clusters herunter. Weitere Informationen Siehe Cluster-Autoscaling und Cluster-Autoscaling-Ereignisse ansehen.

Wenn Sie Erstellen Sie eine logbasierte Benachrichtigungsrichtlinie dafür. Ereignistyp und verwenden Sie dann die folgende Abfrage:

(resource.type=k8s_cluster log_id(container.googleapis.com%2Fcluster-autoscaler-visibility)
jsonPayload.decision:*)

Cluster erstellen und löschen

Dieses Ereignis verfolgt das Erstellen und Löschen von GKE-Cluster Aktionen. Weitere Informationen finden Sie unter Autopilot-Cluster erstellen Zonalen Cluster erstellen und Cluster löschen

Wenn Sie Erstellen Sie eine logbasierte Benachrichtigungsrichtlinie dafür. Ereignistyp und verwenden Sie dann die folgende Abfrage:

resource.type=gke_cluster log_id(cloudaudit.googleapis.com%2Factivity)
protoPayload.methodName=(
    google.container.v1alpha1.ClusterManager.CreateCluster OR
    google.container.v1beta1.ClusterManager.CreateCluster OR
    google.container.v1.ClusterManager.CreateCluster OR
    google.container.v1alpha1.ClusterManager.DeleteCluster OR
    google.container.v1beta1.ClusterManager.DeleteCluster OR
    google.container.v1.ClusterManager.DeleteCluster
)
operation.first=true

Clusteraktualisierung

Dieses Ereignis verfolgt GKE-Clusterupdates. Aktualisierungen umfassen automatische und manuelle Versionsupgrades der Steuerungsebene und Änderungen der Clusterkonfiguration. Weitere Informationen finden Sie unter Manuelles Upgrade eines Clusters oder Knotenpools und Standard-Clusterupgrades.

Wenn Sie Erstellen Sie eine logbasierte Benachrichtigungsrichtlinie dafür. und verwenden Sie die folgende Abfrage:

resource.type=gke_cluster log_id(cloudaudit.googleapis.com%2Factivity)
(
    protoPayload.methodName=(
        google.container.internal.ClusterManagerInternal.PatchCluster OR
        google.container.internal.ClusterManagerInternal.UpdateClusterInternal OR
        google.container.internal.ClusterManagerInternal.UpdateCluster
    )
) OR (
    protoPayload.methodName=(
        google.container.v1beta1.ClusterManager.UpdateCluster OR
        google.container.v1.ClusterManager.UpdateCluster
    )
    operation.first=true
)
protoPayload.metadata.operationType=(UPGRADE_MASTER OR REPAIR_CLUSTER OR UPDATE_CLUSTER)

Knotenpoolupdate

Dieses Ereignis verfolgt Updates von GKE-Knotenpools. Updates beinhalten automatische Knotenpools Versionsupgrades sowie manuelle Upgrades, Konfigurationsänderungen und Größenanpassungen. Weitere Informationen finden Sie unter Manuelles Upgrade eines Clusters oder Knotenpools und Standard-Clusterupgrades.

Wenn Sie Erstellen Sie eine logbasierte Benachrichtigungsrichtlinie dafür. und verwenden Sie die folgende Abfrage:

resource.type=gke_nodepool log_id(cloudaudit.googleapis.com%2Factivity)
(
    protoPayload.methodName=(
        google.container.internal.ClusterManagerInternal.UpdateClusterInternal OR
        google.container.internal.ClusterManagerInternal.RepairNodePool
    )
) OR (
    protoPayload.methodName=(
        google.container.v1beta1.ClusterManager.UpdateNodePool OR
        google.container.v1.ClusterManager.UpdateNodePool OR
        google.container.v1beta1.ClusterManager.SetNodePoolSize OR
        google.container.v1.ClusterManager.SetNodePoolSize OR
        google.container.v1beta1.ClusterManager.SetNodePoolManagement OR
        google.container.v1.ClusterManager.SetNodePoolManagement OR
        google.container.v1beta1.ClusterManager.SetNodePoolAutoscaling OR
        google.container.v1.ClusterManager.SetNodePoolAutoscaling
    )
    operation.first=true
)

Cloud Run-Ereignistypen

In diesem Abschnitt werden die Cloud Run-Ereignistypen beschrieben, die Sie die auf einem Dashboard angezeigt werden.

Cloud Run-Bereitstellung

Mithilfe dieses Ereignistyps können Sie Fehler bei der Cloud Run-Bereitstellung. Die Bereitstellung kann aus verschiedenen Gründen fehlschlagen wie z. B. gelöschtes Dienstkonto, falsche Berechtigungen, den Import eines Container fehlgeschlagen oder ein Container konnte nicht gestartet werden.

Wenn Sie Erstellen Sie eine logbasierte Benachrichtigungsrichtlinie dafür. und verwenden Sie die folgende Abfrage:

log_id(cloudaudit.googleapis.com%2Factivity) resource.type=cloud_run_revision
protoPayload.methodName=google.cloud.run.v1.Services.ReplaceService

Informationen zur Fehlerbehebung finden Sie unter Fehlerbehebung: Cloud Run-Probleme

Cloud SQL-Ereignistypen

In diesem Abschnitt werden die Cloud SQL-Ereignistypen beschrieben, die die auf einem Dashboard angezeigt werden.

Cloud SQL-Failover

Mit diesem Ereignistyp können Sie ermitteln, wann manuelle oder automatische Failovers auftreten. Ein Failover tritt auf, wenn eine Instanz oder Zone ausfällt und wird die Stand-by-Instanz zur neuen primären Instanz. Während eines Failovers Cloud SQL wechselt automatisch zur Bereitstellung von Daten aus der Standby-Instanz.

Wenn Sie Erstellen Sie eine logbasierte Benachrichtigungsrichtlinie dafür. und verwenden Sie die folgende Abfrage:

resource.type=cloudsql_database
(
    (
        log_id(cloudaudit.googleapis.com%2Factivity)
        protoPayload.methodName=cloudsql.instances.failover
        operation.last=true
    ) OR (
        log_id(cloudaudit.googleapis.com%2Fsystem_event)
        protoPayload.methodName=cloudsql.instances.autoFailover
    )
)

Weitere Informationen finden Sie unter Informationen zur Hochverfügbarkeit

Cloud SQL starten oder beenden

Mit diesem Ereignistyp können Sie feststellen, dass eine Cloud SQL-Instanz manuell gestartet, angehalten oder neu gestartet. Wenn eine Instanz beendet wird, geöffnete Dateien und laufende Vorgänge werden ebenfalls gestoppt.

Wenn Sie Erstellen Sie eine logbasierte Benachrichtigungsrichtlinie dafür. und verwenden Sie die folgende Abfrage:

log_id(cloudaudit.googleapis.com%2Factivity) resource.type=cloudsql_database
protoPayload.methodName=cloudsql.instances.update operation.last=true
protoPayload.metadata.intents.intent=(START_INSTANCE OR STOP_INSTANCE)

Weitere Informationen finden Sie unter Hochverfügbarkeit und Instanzen starten, stoppen und neu starten

Cloud SQL-Speicher

Mit diesem Ereignistyp können Sie Ereignisse im Zusammenhang mit dem Cloud SQL-Speicher z. B. wenn der Datenbankspeicher voll ist oder wenn eine Datenbank aufgrund bis die Speicherkapazität erreicht ist. Datenbanken mit Speicherkapazität und ohne der automatische Speicher aktiviert wird, wird möglicherweise heruntergefahren, um eine Beschädigung von Daten zu verhindern.

Wenn Sie Erstellen Sie eine logbasierte Benachrichtigungsrichtlinie dafür. und verwenden Sie die folgende Abfrage:

resource.type=cloudsql_database
(
    (
        (log_id(cloudsql.googleapis.com%2Fpostgres.log) OR log_id(cloudsql.googleapis.com%2Fmysql.err))
        textPayload=~"No space left on device"
        severity=(ERROR OR EMERGENCY)
    ) OR (
        log_id(cloudaudit.googleapis.com%2Fsystem_event)
        protoPayload.methodName=cloudsql.instances.databaseShutdownOutOfStorage
    )
)

Compute Engine-Ereignistypen

In diesem Abschnitt werden die Compute Engine-Ereignistypen beschrieben, die Sie die auf einem Dashboard angezeigt werden.

Beendigungen von virtuellen Maschinen

Mit diesem Ereignistyp können Sie VM-Beendigungen einschließlich manuell ausgelöster Zurücksetzungen und Stopps, Beendigungen von Gastbetriebssystemen, Wartungsbeendigungen und Hostfehler.

Wenn Sie Erstellen Sie eine logbasierte Benachrichtigungsrichtlinie dafür. und verwenden Sie die folgende Abfrage:

resource.type=gce_instance
(
    (
        log_id(cloudaudit.googleapis.com%2Factivity)
        protoPayload.methodName=(
            beta.compute.instances.reset OR v1.compute.instances.reset OR
            beta.compute.instances.stop OR v1.compute.instances.stop
        )
        operation.first=true
    ) OR (
        log_id(cloudaudit.googleapis.com%2Fsystem_event)
        protoPayload.methodName=(
            compute.instances.hostError OR
            compute.instances.guestTerminate OR
            compute.instances.terminateOnHostMaintenance
        )
    )
)

Weitere Informationen finden Sie unter VM beenden und starten und Fehlerbehebung beim Herunterfahren und Neustarten von VMs

Fehler beim Start der VM-Instanz

Dieses Ereignis verfolgt Fehler beim Starten von Compute Engine-VM-Instanzen. Das Ereignis zeigt Startfehler aufgrund von Ressourcenmangel, Erschöpfung des IP-Bereichs, überschrittene Kontingente, oder Shielded VM-Integritätsfehler.

Wenn Sie Erstellen Sie eine logbasierte Benachrichtigungsrichtlinie dafür. und verwenden Sie die folgende Abfrage:

resource.type=gce_instance
(
    (
        log_id(cloudaudit.googleapis.com%2Factivity)
        protoPayload.methodName=(beta.compute.instances.insert OR v1.compute.instances.insert)
        protoPayload.status.message=(ZONE_RESOURCE_POOL_EXHAUSTED OR IP_SPACE_EXHAUSTED OR QUOTA_EXCEEDED)
    ) OR (
        log_id(compute.googleapis.com%2Fshielded_vm_integrity)
        severity="ERROR"
    )
)

Fehler im Gastbetriebssystem der VM-Instanz

Dieses Ereignis verfolgt bestimmte Gastbetriebssystemfehler der Compute Engine-VM-Instanz als die in den Logs der seriellen Konsole aufgezeichnet wurden. Die erfassten Fehler sind voll, Datei Systembereitstellung fehlgeschlagen und Startfehler, durch die der Linux-Notfallmodus aktiviert wird.

Damit diese Ereignisse sichtbar sind, müssen Sie das Logging der Ausgabe des seriellen Ports aktivieren: Cloud Logging durch Festlegen von serial-port-logging-enable=true in der VM oder in die Projektmetadaten. Weitere Informationen finden Sie unter Logging für die Ausgabe des seriellen Ports aktivieren und deaktivieren

Wenn Sie Erstellen Sie eine logbasierte Benachrichtigungsrichtlinie dafür. und verwenden Sie die folgende Abfrage:

resource.type=gce_instance
log_id(serialconsole.googleapis.com%2Fserial_port_1_output)
textPayload=~("No space left on device" OR "Failed to mount" OR "You are in emergency mode")

Aktualisierung der verwalteten Instanzgruppe

Mit diesem Ereignistyp können Sie ermitteln, wann Ihre verwaltete Instanzgruppe wurde aktualisiert. Beispielsweise wurden VMs hinzugefügt oder entfernt, oder die Größenbeschränkung wurde aktualisiert. Weitere Informationen finden Sie unter Aktualisierungen der VM-Konfiguration in einer MIG automatisch anwenden.

Wenn Sie Erstellen Sie eine logbasierte Benachrichtigungsrichtlinie dafür. und verwenden Sie die folgende Abfrage:

resource.type=gce_instance_group_manager
log_id(cloudaudit.googleapis.com%2Factivity) operation.first=true
protoPayload.methodName=(beta.compute.instanceGroupManagers.patch OR v1.compute.instanceGroupManagers.patch)

Weitere Informationen finden Sie unter Mit verwalteten Instanzen arbeiten und Fehlerbehebung bei verwalteten Instanzgruppen

Autoscaling für verwaltete Instanzgruppen

Dieses Ereignis verfolgt Skalierungsentscheidungen, die vom Autoscaling einer verwalteten Instanzgruppe getroffen wurden. Diese Entscheidungen können Änderungen an der empfohlenen Größe für eine verwaltete Instanzgruppe, oder eine Statusänderung des Autoscalings selbst. Weitere Informationen finden Sie unter Autoscaling von Instanzgruppen.

Wenn Sie Erstellen Sie eine logbasierte Benachrichtigungsrichtlinie dafür. und verwenden Sie die folgende Abfrage:

resource.type=autoscaler log_id(cloudaudit.googleapis.com%2Fsystem_event)
protoPayload.methodName=(compute.autoscalers.resize OR compute.autoscalers.changeStatus)

Ereignistypen für Personalized Service Health

In diesem Abschnitt werden die Typen von Personalized Service Health beschrieben, die angezeigt werden können. auf einem Dashboard.

Hinweis: Zum Anzeigen von Personalized Service Health-Ereignissen: müssen Sie die Service Health API aktivieren. Informationen zur diese API zu aktivieren, siehe Ereignisse anzeigen: Hinweise

Google Cloud-Vorfall

Bei der Fehlerbehebung empfiehlt es sich, zwischen Fehler aufgrund eines eigenen Dienstes oder eines Google Cloud-Dienst, den Sie verwenden. Wenn Sie Personalized Service Health-Annotationen in einem Dashboard. Störungen oder Dienststatusereignisse, für Google Cloud-Dienste. Für eine Liste der Dienste, die in Service Health, siehe Unterstützte Google-Produkte.

Im Gegensatz zu anderen Ereignistypen werden Google Cloud-Vorfälle nicht durch die Analyse Ihre Logeinträge. Wenn Sie über solche Ereignisse benachrichtigt werden möchten, eine Benachrichtigungsrichtlinie erstellen. Sie können eine vorkonfigurierte Benachrichtigungsrichtlinie auswählen mithilfe der Optionen auf der Seite Service Health-Dashboard. Weitere Informationen Siehe Kurzanleitung: Benachrichtigungen einrichten.

Monitoring erkennt Google Cloud-Vorfälle indem Sie eine Anfrage an die Service Health API senden und dann die auf Vorfälle reagieren, die für die angezeigten Daten relevant sind. Die Anfrage hat die folgende Konfiguration:

• Die Aufzählung Relevance ist auf RELATED, IMPACTED oder PARTIALLY_RELATED. Durch diese Einschränkung wird sichergestellt, zeigt Ereignisse für die Google Cloud-Dienste an, die Ihr Google Cloud-Projekt verwendet.

• Die Aufzählung DetailedState ist nicht auf FALSE_POSITIVE.

Service Health-Anmerkungen werden mit einer Startzeit angezeigt und eine Dauer. Die Dauer wird durch Ändern der Hintergrundfarbe angezeigt. des Diagramms. Kurzinfo zu einem Google Cloud-Vorfall Folgendes identifiziert:

• Der Google Cloud-Dienst.
• Ob der Vorfall offen oder behoben ist
• Datum und Startzeit des Ereignisses.
• Chips, die die Anzahl der betroffenen Produkte und Standorte anzeigen. Wenn Sie die betroffenen Produkte oder Standorte auflisten möchten, platzieren Sie den Mauszeiger auf dem entsprechenden Chip.
• Eine Schaltfläche Ansicht. Wenn diese ausgewählt ist, wird die Detailseite für das Vorfall.

Informationen zum Senden einer Anfrage an den Service Health API, siehe Prüfen Sie mit Service Health, ob Störungen auftreten.

Informationen zur Fehlerbehebung finden Sie unter Häufige Probleme mit Service Health beheben

Ereignistypen für Verfügbarkeitsdiagnosen

In diesem Abschnitt werden die Ereignistypen für Verfügbarkeitsdiagnosen beschrieben, die in einem Dashboard.

Hinweis: Damit diese Ereignistypen verfügbar sind, muss die Verfügbarkeitsdiagnose in der Lage sein, um Fehler zu protokollieren. Sie können Logging aktivieren, indem Sie die Antwort konfigurieren wenn Sie eine Verfügbarkeitsdiagnose erstellen oder ändern. Weitere Informationen zum Erstellen von Verfügbarkeit finden Sie unter Öffentliche Verfügbarkeitsdiagnosen erstellen.

Verfügbarkeitsdiagnose fehlgeschlagen

Mit diesem Ereignistyp können Sie Fehler bei Verfügbarkeitsdiagnosen in konfigurierten Regionen.

Wenn Sie Erstellen Sie eine logbasierte Benachrichtigungsrichtlinie dafür. und verwenden Sie die folgende Abfrage:

log_id(monitoring.googleapis.com%2Fuptime_checks)
(
  resource.type=uptime_url OR resource.type=gce_instance OR
  resource.type=gae_app OR resource.type=k8s_service OR
  resource.type=servicedirectory_service OR resource.type=cloud_run_revision OR
  resource.type=aws_ec2_instance OR resource.type=aws_elb_load_balancer
)
labels.uptime_result_type=UptimeCheckResult
severity=NOTICE

Informationen zur Fehlerbehebung finden Sie unter Fehler beim synthetischen Monitoring und Verfügbarkeitsdiagnosen beheben.

Nächste Schritte

Informationen zum Anzeigen von Ereignissen auf Ihren Dashboards finden Sie unter Ereignisse auf einem Dashboard anzeigen