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.
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.
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 aufRELATED
,IMPACTED
oderPARTIALLY_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 aufFALSE_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.
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