Fehlerlogs in Cloud Logging aufrufen

Auf dieser Seite wird erläutert, wie Sie Logs in Google Cloud Observability für unterstützte Anfragetypen anzeigen.

Logging

Fehler, die in den folgenden Anfragen ausgelöst werden, werden in Cloud Logging protokolliert.

Fehler werden auch protokolliert, wenn eine Pub/Sub-Nachricht nicht in Pub/Sub veröffentlicht werden kann. Weitere Informationen finden Sie unter Fehlerbehebung bei Pub/Sub-Benachrichtigungen.

Die Protokollierung erfolgt automatisch und muss nicht aktiviert werden. Informationen zum Deaktivieren von Cloud Logging für eine oder alle überwachten Ressourcen finden Sie unter Logausschlüsse.

Logs ansehen

Um Logs anzuzeigen, öffnen Sie den Log-Explorer.

So rufen Sie Logs für Vorgänge mit einem Fehlerstatus auf:

  1. Wechseln Sie in der Google Cloud Console zum Browser der Cloud Healthcare API.

    Zum Cloud Healthcare API-Browser

  2. Wählen Sie ein Dataset aus

  3. Klicken Sie auf den Tab Vorgänge.

  4. Wählen Sie in der Liste der Vorgänge aus der Liste Aktionen die Option Details in Cloud Logging aufrufen aus, um die Details eines fehlerhaften Vorgangs aufzurufen.

Logs filtern

Sie können Logs nach Datenspeichertyp, Region und Dataset filtern.

Wenn Sie beispielsweise Logs für FHIR-Speicher ansehen möchten, klicken Sie in der ersten Liste unter Nach Label oder Textsuche filtern auf Healthcare-FHIR-Speicher. Sie können auch nach Ressourcentyp suchen. Wenn Sie beispielsweise nach healthcare_dicom_store suchen, werden alle Logs angezeigt, die für Vorgänge generiert wurden, bei denen resource.type auf healthcare_dicom_store gesetzt ist.

Für Logfelder wird eine UTF-8-Codierung erzwungen. Zeichen, die keine UTF-8-Zeichen sind, werden durch Fragezeichen ersetzt.

Weitere Informationen zum Log-Explorer finden Sie unter Log-Explorer verwenden.

Mit Cloud Logging nach Fehlerereignissen suchen

Sie können auch Cloud Logging verwenden, um das Audit-Log eines Ereignisses zu finden, das einen Fehler verursacht. So finden Sie ein Fehlerereignis in den Audit-Logs:

  1. Suchen Sie in Cloud Logging nach dem Vorgang, der den Fehler verursacht hat.

  2. Führen Sie den spezifischen Befehl mit den Protokolldetails des Vorgangs erneut aus.

  3. Zeigen Sie die Audit-Logs für das entsprechende Ereignis an. Weitere Informationen zu Audit-Logs finden Sie unter Cloud-Audit-Logs ansehen.

Inhalt der Logs

Die Logeinträge der Cloud Healthcare API enthalten die folgenden Arten von Informationen zum Debuggen von Anfragen:

  • Allgemeine Informationen wie Schweregrad, Projekt-ID, Projektnummer und Zeitstempel
  • jsonPayload enthält den eigentlichen Text des Eintrags. Dieses Feld enthält den Fehlercode, die Fehlermeldung und den Namen der Quelldatei, deren Import den Fehler ausgelöst hat.
  • operation enthält den Typ und die ID des Vorgangs, der den Fehler verursacht hat.
  • resource enthält den Speicherort, das Dataset und den Datenspeicher, die am Fehler beteiligt sind.

Wenn die Anzahl der Fehler einen Schwellenwert überschreitet, wird eine begrenzte Anzahl von Fehlern in Cloud Logging angezeigt. Der Schwellenwert wird basierend auf der Größe der Eingabe dynamisch berechnet.

Wo werden Logs gespeichert?

Google Cloud Observability ist kein regionales Produkt. Logs, die in Google Cloud Observability geschrieben werden, können in einer anderen Region als die Datenspeicher gespeichert werden.

Beispiel für einen DICOM-Importprotokolleintrag

Der folgende Beispiel-Logeintrag zeigt den Fehler empty DICOM instance found, der beim Importieren von gs://DICOM_FILENAME.dcm in projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/dicomStores/DICOM_STORE_ID aufgetreten ist.

 jsonPayload: {
  @type:  "type.googleapis.com/google.cloud.healthcare.logging.ImportDicomLogEntry"
  error: {
   code:  3
   message:  "empty DICOM instance found"
  }
  source:  "gs://DICOM_FILENAME.dcm"
 }
 logName:  "projects/PROJECT_ID/logs/healthcare.googleapis.com%2Foperations"
 operation: {
  id:  "PROJECT_ID"
  producer:  "import_dicom"
 }
 receiveTimestamp:  "TIMESTAMP"
 resource: {
  labels: {
   dataset_id:  "DATASET_ID"
   dicom_store_id:  "DICOM_STORE_ID"
   location:  "LOCATION"
   project_id:  "PROJECT_ID"
  }
  type:  "healthcare_dicom_store"
 }
 severity:  "ERROR"
 timestamp:  "TIMESTAMP"

Beispiel für einen FHIR-Import-Logeintrag

Der folgende Beispiel-Logeintrag zeigt den Fehler cannot import resource, der beim Importieren von gs://FHIR_FILENAME.ndjson in projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/fhirStore/FHIR_STORE_ID aufgetreten ist.

 jsonPayload: {
  @type:  "type.googleapis.com/google.cloud.healthcare.logging.ImportFhirLogEntry"
  error: {
   code:  3
   message:  "cannot import resource Patient/PATIENT_ID, conflicting resource already exists"
  }
  source:  "gs://FHIR_FILENAME.ndjson"
 }
 logName:  "projects/PROJECT_ID/logs/healthcare.googleapis.com%2Foperations"
 operation: {
  id:  "PROJECT_ID"
  producer:  "import_fhir"
 }
 receiveTimestamp:  "TIMESTAMP"
 resource: {
  labels: {
   dataset_id:  "DATASET_ID"
   fhir_store_id:  "FHIR_STORE_ID"
   location:  "LOCATION"
   project_id:  "PROJECT_ID"
  }
  type:  "healthcare_fhir_store"
 }
 severity:  "ERROR"
 timestamp:  "TIMESTAMP"

Beispiel für einen Annotationsimport-Logeintrag

Der folgende Beispiel-Logeintrag zeigt den Fehler failed to parse Cloud Storage object, der beim Importieren von gs://ANNOTATION_FILE.json in projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/annotationStores/ANNOTATION_STORE_ID aufgetreten ist.

jsonPayload: {
  @type:
  "type.googleapis.com/google.cloud.healthcare.logging.ImportAnnotationLogEntry"
  error: {
    code:  3
    message:  "failed to parse Cloud Storage object"
  }
  source:  "gs://ANNOTATION_FILE.json"
}
logName:
"projects/PROJECT_ID/logs/healthcare.googleapis.com%2Fimport_annotations"
operation: {
  id:
  "projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/operations/OPERATION_ID"
  producer:  "healthcare.googleapis.com/ImportAnnotations"
}
receiveTimestamp:  "TIMESTAMP"
resource: {
  labels: {
    annotation_store_id:  "ANNOTATION_STORE_ID"
    dataset_id:  "DATASET_ID"
    location:  "LOCATION"
    project_id:  "PROJECT_ID"
  }
  type:  "healthcare_annotation_store"
}
severity:  "ERROR"
timestamp:  "TIMESTAMP"

Beispiel für einen DICOM-De-Identifizierungs-Logeintrag

Der folgende Logeintrag zeigt den Fehler cannot de-identify dicom instance, der beim De-Identifizieren der DICOM-Instanz INSTANCE_ID im Dataset projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID aufgetreten ist.

 jsonPayload: {
  @type:  "type.googleapis.com/google.cloud.healthcare.logging.DeidentifyLogEntry"
  error: {
   code:  2
   message:  "Failed to process instance INSTANCE_ID"
  }
  resourceName:  "projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID"
 }
 logName:  "projects/PROJECT_ID/logs/healthcare.googleapis.com%2Fdeidentify_dataset"
 operation: {
  id:  "projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/operations/OPERATION_ID"
  producer:  "healthcare.googleapis.com/DeidentifyDataset"
 }
 receiveTimestamp:  "TIMESTAMP"
 resource: {
  labels: {
   dataset_id:  "DATASET_ID"
   location:  "LOCATION"
   project_id:  "PROJECT_ID"
  }
  type:  "healthcare_dataset"
 }
 severity:  "ERROR"
 timestamp:  "TIMESTAMP"

Nächste Schritte