Wenn sich der Systemstatus eines Endpunkts ändert, können Sie Logs von Systemdiagnosen für das Load-Balancing abrufen. Mit den Systemdiagnose-Logs können Sie Folgendes:
- Live-Debugging und Fehlerbehebung für den Systemstatus des Endpunkts vornehmen
- Sie erhalten einen Einblick in den Systemstatus des Endpunkts
- Die Logs erfüllen Prüfungs- und Compliance-Zwecke
Mit Systemdiagnosen werden Informationen zur Änderung des Systemzustands in Logging erfasst. Sie aktivieren oder deaktivieren das Logging für jede Systemdiagnose.
Damit Systemdiagnose-Logs in Logging angezeigt werden, dürfen keine Logs ausgeschlossen werden, die sich auf Systemdiagnosen beziehen. Eine Anleitung zum Prüfen, ob die Logs GCE Instance Group
und Network Endpoint Group
zulässig sind, finden Sie unter Ausschlussfilter.
Logging aktivieren und deaktivieren
In diesem Abschnitt wird beschrieben, wie Sie Logging für eine neue oder bestehende Systemdiagnose aktivieren und wie Sie Logging für eine bestehende Systemdiagnose deaktivieren.
Logging für eine neue Systemdiagnose aktivieren
Console
Rufen Sie in der Google Cloud Console die Seite Systemdiagnosen auf.
Klicken Sie auf Systemdiagnose erstellen.
Wählen Sie für Logs Ein aus.
Fahren Sie mit der Einrichtung der Systemdiagnose fort.
gcloud
gcloud compute health-checks create PROTOCOL HEALTH_CHECK_NAME \ --enable-logging
Das Flag --enable-logging
aktiviert das Logging für diese Systemdiagnose.
Terraform
Verwenden Sie die google_compute_health_check
-Ressource, um mit Logging eine Systemdiagnose für verschiedene Protokolle zu erstellen.
Verwenden Sie für einen regionalen Load-Balancer die google_compute_region_health_check
-Ressource.
Informationen zum Anwenden oder Entfernen einer Terraform-Konfiguration finden Sie unter Grundlegende Terraform-Befehle.
Logging für eine vorhandene Systemdiagnose aktivieren
Console
Rufen Sie in der Google Cloud Console die Seite Systemdiagnosen auf.
Klicken Sie auf den Namen Ihrer Systemdiagnose.
Klicken Sie auf
Bearbeiten.Wählen Sie für Logs Ein aus.
Klicken Sie auf Speichern.
gcloud
gcloud compute health-checks update PROTOCOL HEALTH_CHECK_NAME \ --enable-logging
Das Flag --enable-logging
aktiviert das Logging für diese Systemdiagnose.
Logging für eine vorhandene Systemdiagnose aktivieren
Console
Rufen Sie in der Google Cloud Console die Seite Systemdiagnosen auf.
Klicken Sie auf den Namen Ihrer Systemdiagnose.
Klicken Sie auf
Bearbeiten.Wählen Sie für Logs Aus.
Klicken Sie auf Speichern.
gcloud
gcloud compute health-checks update PROTOCOL HEALTH_CHECK_NAME \ --no-enable-logging
Das Flag --no-enable-logging
deaktiviert das Logging für diese Systemdiagnose.
Logs ansehen
Öffnen Sie zum Aufrufen von Logs den Log-Explorer.
Systemdiagnose-Logs werden nach Instanzgruppe oder Netzwerk-Endpunktgruppe indexiert.
Für die Anzeige aller Logs wählen Sie im Menü Ressource je nach Backend-Typ entweder
GCE Instance Group
oderNetwork Endpoint Group
aus.Alternativ können Sie Folgendes in das Feld Abfrage einfügen. Ersetzen Sie
PROJECT_ID
durch die ID Ihres Projekts.logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fhealthchecks"
Sie können den Export von logbasierten Messwerten für Systemdiagnosen von Load-Balancern konfigurieren.
Logs mit Filtern aufrufen
Sie können auch spezifischere Suchanfragen stellen, um Logs abzurufen. Der folgende Filter zeigt beispielsweise alle Logs für eine angegebene IP-Adresse einer Back-End-Instanz an:
logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fhealthchecks" jsonPayload.healthCheckProbeResult.ipAddress="IP_ADDRESS"
Boolesche Logfelder erscheinen normalerweise nur, wenn sie den Wert true
haben.
Wenn ein boolesches Feld einen Wert false
hat, erscheint dieses Feld nicht im Log.
Für Logfelder wird eine UTF-8-Codierung erzwungen. Zeichen, bei denen es sich nicht um UTF-8-Zeichen handelt, werden durch Fragezeichen ersetzt.
Was wird protokolliert?
Logeinträge von Systemdiagnosen enthalten Informationen, die für das Monitoring und die Fehlerbehebung des Status Ihrer Endpunkte hilfreich sind. Folgende Informationen sind in Ihnen enthalten:
- Allgemeine Informationen, die in den meisten Logs angezeigt werden, wie z. B. Schweregrad, Projekt-ID, Projektnummer und Zeitstempel.
- Felder für Systemdiagnosen, die in den folgenden Tabellen beschrieben werden
Status der Systemdiagnose
Ein Endpunkt wird entweder als HEALTHY
oder UNHEALTHY
betrachtet. Das sind die grundlegenden Status. Innerhalb dieser grundlegenden Status gibt es mehrere ausführlichere Status.
Hybrid-NEGs und regionale Internet-NEGs mit verteilten Envoy-Systemdiagnosen unterstützen keine detaillierten Systemzustände.
Die folgende Tabelle zeigt die Zuordnung zwischen grundlegenden und detaillierten Integritätsstatus.
Grundlegender Gesundheitsstatus | Detaillierter Gesundheitsstatus |
---|---|
HEALTHY |
HEALTHY DRAINING
|
UNHEALTHY |
UNKNOWN UNHEALTHY TIMEOUT
|
Statusänderungen ändern nicht immer das Verhalten des Load-Balancers. Betrachten Sie den folgenden Fall:
- Der Server gibt die falsche Antwort zurück, sodass der Endpunkt als
UNHEALTHY
gilt. - Der Server reagiert dann nicht mehr und der neue Zustand ist
TIMEOUT
. - Der Load-Balancer betrachtet den Endpunkt noch als
UNHEALTHY
, da der detaillierte StatusTIMEOUT
dem grundlegenden StatusUNHEALTHY
zugeordnet wird.
Die folgende Tabelle enthält eine Definition für jeden Status.
Ausführlicher Status der Systemdiagnose | Bedeutung | Grundzustand |
---|---|---|
HEALTHY
|
Der Endpunkt ist erreichbar und entspricht den in der Systemdiagnose definierten Anforderungen. | HEALTHY
|
UNHEALTHY
|
Der Endpunkt ist erreichbar, entspricht aber nicht den in der Systemdiagnose definierten Anforderungen. | UNHEALTHY
|
DRAINING
|
Der Endpunkt wird per Drain beendet. Die bestehenden Verbindungen zum Endpunkt können zwar abgeschlossen werden, die neuen Verbindungen werden jedoch abgelehnt. Der Endpunkt wird als HEALTHY betrachtet.
|
HEALTHY
|
TIMEOUT
|
Der Endpunkt ist nicht erreichbar. Je nach Typ der Systemdiagnose kann entweder keine Verbindung zum Endpunkt hergestellt werden oder der Server hat nicht innerhalb des angegebenen Zeitlimits geantwortet. Der Endpunkt wird als UNHEALTHY betrachtet.
|
UNHEALTHY
|
UNKNOWN
|
Das System zur Systemdiagnose erkennt den Endpunkt, sein Zustand ist jedoch nicht bekannt. Der Endpunkt wird als UNHEALTHY betrachtet.
|
UNHEALTHY
|
Es gibt mehrere Systemdiagnosen für jeden Endpunkt. Google Cloud dedupliziert die Logeinträge vor dem Logging, sodass nur eindeutige Logs generiert werden.
Wenn eine Systemdiagnose neu gestartet wird, kann es vorkommen, dass der protokollierte Systemstatus von UNKNOWN
in einen der zuvor aufgeführten bekannten Status geändert wird, obwohl sich der Systemstatus des Endpunkts nicht geändert hat. Google Cloud verwendet Best-Effort-Heuristik, um solche Logeinträge zu unterdrücken.
Wenn Sie den Verbindungsausgleich verwenden, werden Systemdiagnose-Logs nicht mit dem Endpunktstatus DRAINING
generiert. Dies liegt daran, dass Systemdiagnose-Logs die von den Systemdiagnoseprüfungen beobachteten Ergebnisse widerspiegeln und der Verbindungsausgleich die Ergebnisse nicht beeinflusst, die von der Systemdiagnoseprüfung beobachtet werden. Beim Verbindungsausgleich wird der Load-Balancer lediglich darüber informiert, dass der neue Zustand DRAINING
ist. Der Verbindungsausgleich überschreibt quasi den tatsächlichen Zustand des Endpunkts, der von der Systemdiagnose beobachtet wird.
Sie können über die Cloud Logging API mit den Logs interagieren. Die API ermöglicht das interaktive Filtern von Logs mit bestimmten festgelegten Feldern und das Exportieren übereinstimmender Logs für Cloud Logging, Cloud Storage, BigQuery oder Pub/Sub. Weitere Informationen zur Cloud Logging API finden Sie unter Cloud Logging API.
Logeinträge von Systemdiagnosen
Der LogEntry jsonPayload
wird mit einem Feld healthCheckProbeResult
gefüllt, das die folgenden Informationen enthält.
Feld | Typ | Beschreibung |
---|---|---|
ipAddress |
string |
Die primäre interne IP-Adresse, die der primären Netzwerkschnittstelle jeder Backend-VM zugeordnet ist. Dies ist ein für Nutzer lesbarer String. |
healthCheckProtocol |
enum(HealthCheckProtocol) |
Das Systemdiagnoseprotokoll, das für die Systemdiagnose des Endpunkts verwendet wird. Beispiele: TCP, HTTP, HTTPS. |
healthState |
enum(HealthState) |
Aktueller Systemstatus des Endpunkts: HEALTHY oder UNHEALTHY . |
previousHealthState |
enum(HealthState) |
Der vorherige Systemstatus des Endpunkts: HEALTHY oder UNHEALTHY . |
detailedHealthState |
enum(DetailedHealthState) |
Aktueller ausführlicher Systemstatus des Endpunkts.
Eine Liste der möglichen Zustände finden Sie unter Zustand der Systemdiagnose.
Nicht unterstützt für verteilte Envoy-Systemdiagnosen für Hybrid-NEGs und regionale Internet-NEGs. |
previousDetailedHealthState |
enum(DetailedHealthState) |
Vorheriger ausführlicher Systemstatus des Endpunkts.
Eine Liste der möglichen Zustände finden Sie unter Zustand der Systemdiagnose.
Nicht unterstützt für verteilte Envoy-Systemdiagnosen für Hybrid-NEGs und regionale Internet-NEGs. |
probeRequest |
string |
Bei HTTP, HTTPS und HTTP/2 ist dies der URL-Anfragepfad (Feld Bei TCP/SSL ist dies der konfigurierte optionale String, der gesendet wird, sobald die Verbindung für die Systemdiagnose hergestellt wurde (Feld Nicht unterstützt für verteilte Envoy-Systemdiagnosen für Hybrid-NEGs und regionale Internet-NEGs. |
probeCompletionTimestamp |
google.protobuf.Timestamp |
Zeitstempel für den Abschluss der Prüfung. |
connectLatency |
google.protobuf.Duration |
Zeitaufwand für die Einrichtung der Verbindung für verbindungsorientierte Systemdiagnoseprotokolle: TCP, SSL, HTTP, HTTPS, HTTP/2.
Nicht unterstützt für verteilte Envoy-Systemdiagnosen für Hybrid-NEGs und regionale Internet-NEGs. |
responseLatency |
google.protobuf.Duration |
Latenz zwischen Anfrage und Antwort, gemessen vom Prober.
Nicht unterstützt für verteilte Envoy-Systemdiagnosen für Hybrid-NEGs und regionale Internet-NEGs. |
probeResultText |
string |
Beschreibender Text zum Prüfergebnis. Zum Beispiel „Zeitüberschreitung bei der Verbindung“ oder „HTTP-Antwort: Bad Gateway“ o. Ä. oder das Feld ist leer.
Nicht unterstützt für verteilte Envoy-Systemdiagnosen für Hybrid-NEGs und regionale Internet-NEGs. |
probeSourceIp |
string |
Die IP-Adresse, von der die Prüfung zur Systemdiagnose gesendet wurde.
Bei verteilten Envoy-Systemdiagnosen entspricht dies der Proxy-IP-Adresse aus dem Nur-Proxy-Subnetz. |
targetIp |
string |
Die IP-Adresse, die das Ziel der Prüfung ist. Dies kann sich von ipAddress unterscheiden.
Die Ziel-IP-Adresse der Prüfung hängt vom Typ des Load-Balancers ab. Weitere Informationen finden Sie unter
Ziel für Prüfungspakete in der Übersicht über Systemdiagnosen.
|
targetPort |
int |
Der Port, der das Ziel der Prüfung war. Das kann der Standardport der Prüfung sein oder der Port, den Sie beim Erstellen der Systemdiagnose angegeben haben. |
Beispielfilter
In diesem Abschnitt finden Sie Beispiele für gängige Logfilter.
Alle Ergebnisse der Systemdiagnose für eine bestimmte Instanzgruppe
logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fhealthchecks" AND resource.type="gce_instance_group" AND resource.labels.instance_group_name="INSTANCE_GROUP_NAME"
Alle Ergebnisse der Systemdiagnose für eine bestimmte NEG
logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fhealthchecks" AND resource.type="gce_network_endpoint_group" AND resource.labels.network_endpoint_group_id="ENDPOINT_GROUP_ID"
Alle Änderungen der Systemdiagnose für die IP-Adresse 10.128.15.201
der Back-End-Instanz suchen
logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fhealthchecks" jsonPayload.healthCheckProbeResult.ipAddress="10.128.15.201"
Alle Endpunkte, die zuvor den Status HEALTHY hatten, aber jetzt TIMEOUT haben
logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fhealthchecks" jsonPayload.healthCheckProbeResult.previousDetailedHealthState="HEALTHY" jsonPayload.healthCheckProbeResult.detailedHealthState="TIMEOUT"
Systemdiagnose-Logs aus einem bestimmten Zeitraum suchen.
logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fhealthchecks" timestamp>"2019-02-14T02:20:00.0Z" timestamp<"2019-02-14T03:30:00.0Z"
Beschränkungen
- Logs werden nur bei Änderungen des Systemzustands von Endpunkten generiert.
- Legacy-Systemdiagnosen werden nicht unterstützt.
- Zielpools werden nicht unterstützt.
- Logs werden nicht generiert, wenn der Systemstatus des Endpunkts
UNKNOWN
lautet. - Bei VM-Migrationen werden möglicherweise keine Logeinträge angezeigt, wenn der Zustand des Endpunkts in den Status
UNHEALTHY
wechselt. - Logs werden nicht gelöscht, wenn Endpunkte gelöscht werden. Beispiel: Sie beenden eine VM.
Nächste Schritte
- Konzeptionelle Informationen zu Systemdiagnosen.
- Erstellen Sie eine Systemdiagnose.
- Weitere Informationen zu Logging