Logs aus Cloud Storage in Cloud Logging importieren

Last reviewed 2024-01-02 UTC

In dieser Referenzarchitektur wird beschrieben, wie Sie Logs, die zuvor in Cloud Storage exportiert wurden, wieder in Cloud Logging importieren können.

Diese Referenzarchitektur richtet sich an Entwickler und Entwickler, einschließlich DevOps, Site Reliability Engineers (SREs) und Sicherheitsprüfer, die den Logimportjob konfigurieren und ausführen möchten. In diesem Dokument wird davon ausgegangen, dass Sie mit dem Ausführen von Cloud Run-Jobs und mit der Verwendung von Cloud Storage und Cloud Logging vertraut sind.

Architektur

Das folgende Diagramm zeigt, wie Google Cloud-Dienste in dieser Referenzarchitektur verwendet werden:

Workflow-Diagramm für den Logimport von Cloud Storage nach Cloud Logging

Dieser Workflow umfasst die folgenden Komponenten:

  • Cloud Storage-Bucket: Enthält die zuvor exportierten Logs, die Sie nach Cloud Logging importieren möchten. Da diese Logs zuvor exportiert wurden, werden sie im erwarteten Exportformat organisiert.
  • Cloud Run-Job: Führt den Importlogprozess aus:
    • Die Objekte, die Logeinträge aus Cloud Storage speichern.
    • Findet exportierte Logs für die angegebene Log-ID im angeforderten Zeitraum, basierend auf der Organisation der exportierten Logs im Cloud Storage-Bucket.
    • Konvertiert die Objekte in LogEntry-Strukturen der Cloud Logging API. Mehrere LogEntry-Strukturen werden in Batches zusammengefasst, um die Nutzung der Cloud Logging API-Kontingente zu reduzieren. Die Architektur verarbeitet bei Bedarf Kontingentfehler.
    • Die konvertierten Logeinträge werden in Cloud Logging geschrieben. Wenn Sie den gleichen Job mehrmals ausführen, können doppelte Einträge auftreten. Weitere Informationen finden Sie unter Importjob ausführen.
  • Cloud Logging: Nimmt die konvertierten Logeinträge auf und speichert sie. Die Logeinträge werden wie unter Routing und Speicher beschrieben verarbeitet.
    • Es gelten die Kontingente und Limits für Logging, einschließlich der Kontingente und Limits der Cloud Logging API sowie einer Aufbewahrungsdauer von 30 Tagen. Diese Referenzarchitektur ist für die Verwendung der Standardschreibkontingente mit einem einfachen Wiederholungsmechanismus konzipiert. Wenn Ihr Schreibkontingent niedriger als die Standardeinstellung ist, schlägt die Implementierung möglicherweise fehl.
    • Die importierten Logs sind nicht in den logbasierten Messwerten enthalten, da ihre Zeitstempel in der Vergangenheit liegen. Wenn Sie jedoch ein Label verwenden, zeichnet der Zeitstempel die Importzeit auf und die Logs sind in den Messwertdaten enthalten.
  • BigQuery: Verwendet SQL, um analytische Abfragen für importierte Logs auszuführen (optional). Diese Architektur ändert die Log-IDs, um Audit-Logs aus Cloud Storage zu importieren, Sie müssen diese Umbenennung berücksichtigen, wenn Sie die importierten Logs abfragen.

Anwendungsfall

Sie können diese Architektur bereitstellen, wenn Ihre Organisation zusätzliche Loganalysen für Untersuchungen von Vorfällen oder andere Audits früherer Ereignisse benötigt. Beispielsweise können Sie im Rahmen des Datenbankzugriffs-Audits die Verbindungen zu Ihren Datenbanken im ersten Quartal des letzten Jahres analysieren.

Designalternativen

In diesem Abschnitt werden Alternativen zum Standarddesign beschrieben, die in diesem Referenzarchitekturdokument beschrieben werden.

Aufbewahrungsdauer und importierte Logs

Cloud Logging erfordert, dass eingehende Logeinträge einen Zeitstempel haben, der die Aufbewahrungsdauer von 30 Tagen nicht überschreitet. Importierte Logeinträge mit Zeitstempeln, die älter als 30 Tage sind, werden nicht gespeichert.

Mit dieser Architektur wird der im Cloud Run-Job festgelegte Zeitraum validiert, um das Importieren von Logs zu verhindern, die älter als 29 Tage sind, sodass eine Sicherheitsspanne von einem Tag verbleibt.

Wenn Sie Logs importieren möchten, die älter als 29 Tage sind, müssen Sie die folgenden Änderungen am Implementierungscode vornehmen und dann ein neues Container-Image erstellen, das in der Cloud Run-Job-Konfiguration verwendet werden soll.

  • 30-tägige Validierung des Zeitraums entfernen
  • Ursprünglichen Zeitstempel als Nutzerlabel zum Logeintrag hinzufügen
  • Setzen Sie das Zeitstempellabel des Logeintrags zurück, damit es mit dem aktuellen Zeitstempel aufgenommen werden kann.

Wenn Sie diese Änderung anwenden möchten, müssen Sie das Feld labels anstelle des Feldes timestamp in Ihrer Loganalyse-Abfragen verwenden. Weitere Informationen zu Abfragen und Beispielen für Log Analytics finden Sie unter Beispiel-SQL-Abfragen.

Designaspekte

Die folgenden Richtlinien können dabei helfen, eine Architektur zu entwickeln, die die Anforderungen Ihrer Organisation erfüllt.

Kostenoptimierung

Die Kosten für den Import von Logs mithilfe dieser Referenzarchitektur hängen von mehreren Faktoren ab.

Sie verwenden die folgenden kostenpflichtigen Komponenten von Google Cloud:

Berücksichtigen Sie folgende Faktoren, die die Kosten erhöhen können:

  • Logduplizierung: Führen Sie den Importjob nicht mehrmals mit derselben Konfiguration aus, um zusätzliche Logspeicherkosten zu vermeiden.
  • Speicher in zusätzlichen Zielen: Um zusätzliche Kosten für den Logspeicher zu vermeiden, deaktivieren Sie die Routingrichtlinien am Zielprojekt, um zu verhindern, dass Logspeicher an zusätzlichen Standorten gespeichert oder Logs an andere Ziele weitergeleitet werden, z. B. Pub/Sub oder BigQuery.
  • Zusätzliche CPU und Arbeitsspeicher: Wenn der Importjob das Zeitlimit überschreitet, müssen Sie möglicherweise die CPU-Leistung und den Arbeitsspeicher des Importjobs in Ihrer Importjobkonfiguration erhöhen. Wenn Sie diese Werte erhöhen, können höhere Cloud Run-Kosten entstehen.
  • Zusätzliche Aufgaben: Wenn die erwartete Anzahl von Logs pro Tag innerhalb des Zeitraums importiert werden soll, müssen Sie möglicherweise die Anzahl der Aufgaben in der Importjobkonfiguration erhöhen. Der Job teilt den Zeitraum gleichmäßig auf die Aufgaben auf, sodass jede Aufgabe die gleiche Anzahl von Tagen aus dem Bereich verarbeitet. Wenn Sie die Anzahl der Aufgaben erhöhen, können höhere Cloud Run-Kosten entstehen.
  • Speicherklasse: Wenn die Speicherklasse Ihres Cloud Storage-Buckets kein Standard ist, z. B. Nearline, Durable Reduced Availability (DRA) oder Coldline, können zusätzliche Kosten anfallen.
  • Datenverkehr zwischen verschiedenen Standorten: Konfigurieren Sie den Importjob so, dass er am selben Speicherort wie der Cloud Storage-Bucket ausgeführt wird, aus dem Sie die Logs importieren. Andernfalls können Kosten für ausgehenden Netzwerktraffic anfallen.

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen, einschließlich Cloud Run-Jobs.

Operative Effizienz

In diesem Abschnitt werden Überlegungen zum Verwalten von Analyseabfragen nach der Bereitstellung der Lösung beschrieben.

Lognamen und Abfragen

Logs werden in dem Projekt gespeichert, das im Feld logName des Logeintrags definiert ist. Damit die Logs in das ausgewählte Projekt importiert werden, ändert diese Architektur das Feld logName jedes importierten Logs. Die Importlogs werden im Standard-Log-Bucket des ausgewählten Projekts gespeichert, das die Log-ID imported_logs hat (es sei denn, das Projekt hat eine Logrouting-Richtlinie, die das Speicherziel ändert). Der ursprüngliche Wert des logName-Felds wird im Feld labels mit dem Schlüssel original_logName beibehalten.

Bei der Abfrage der importierten Logs muss der Speicherort des ursprünglichen logName-Werts berücksichtigt werden. Weitere Informationen zu Log Analytics-Abfragen und -Beispielen finden Sie unter Beispiel-SQL-Abfragen.

Leistungsoptimierung

Wenn die Menge der zu importierenden Logs die Cloud Run-Kapazitätslimits überschreitet, kann der Job zu einer Zeitüberschreitung führen, bevor der Import abgeschlossen ist. Um einen unvollständigen Datenimport zu vermeiden, sollten Sie den Wert tasks im Importjob erhöhen. Durch Erhöhung der CPU- und Arbeitsspeicherressourcen können Sie auch die Aufgabenleistung verbessern, wenn Sie die Anzahl der Aufgaben erhöhen.

Bereitstellung

Informationen zum Bereitstellen dieser Architektur finden Sie unter Job zum Importieren von Logs aus Cloud Storage in Cloud Logging bereitstellen.

Weitere Informationen

Beitragende

Autor: Leonid Yankulin | Developer Relations Engineer

Weitere Beitragende: