Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Grundlegendes zu Konzepten für geplante Abfragen

Bevor Sie geplante Abfragen erstellen, sollten Sie sich mit diesen Schlüsselkonzepten vertraut machen, die sich darauf auswirken, wie Ihre Abfragen ausgeführt werden und wo Ergebnisse geliefert werden.

IAM-Rollentrennung

Für geplante Abfragen sind zwei separate IAM-Rollen erforderlich: eine für die Ausführung von Abfragen und eine weitere für die Bereitstellung von Ergebnissen an Ziele wie Amazon S3-Buckets, EventBridge Amazon-Event-Busse oder Lookup-Tabellen. Wenn Sie wissen, warum diese Trennung besteht, können Sie Berechtigungen richtig konfigurieren und die damit verbundenen Sicherheits- und Betriebsvorteile nutzen.

Die Architektur mit zwei Rollen verteilt die Verantwortlichkeiten zwischen Datenzugriff und Datenbereitstellung. Die Rolle zur Abfrageausführung greift auf Ihre Protokolldaten zu und führt Abfragen aus, während die Zielzustellungsrolle die Ergebnisse an das von Ihnen gewählte Ziel schreibt. Diese Trennung folgt dem Prinzip der geringsten Rechte — jede Rolle hat nur die Berechtigungen, die sie für ihre spezifische Funktion benötigt.

Diese Trennung bietet praktische Vorteile für Ihren Betrieb. Aus Sicherheitsgründen gilt: Wenn Sie ändern müssen, wo Ergebnisse geliefert werden, ändern Sie nur die Zielübermittlungsrolle, ohne die Berechtigungen zur Abfrageausführung zu ändern. Aus Konformitäts- und Auditgründen können Sie eindeutig nachverfolgen, welche Rolle auf vertrauliche Protokolldaten zugreift und welche Rolle in externe Systeme schreibt. Auf diese Weise können Sie leichter nachweisen, dass Ihre Infrastruktur für die Protokollanalyse den bewährten Sicherheitsmethoden folgt.

Cross-region und kontoübergreifende Nutzung

Eine geplante Abfrage wird in einer bestimmten Region erstellt und in dieser Region ausgeführt. Sie können jedoch Protokollgruppen abfragen und Ergebnisse für Regionen und Konten bereitstellen. Sie müssen ein oder mehrere AWS Konten als Überwachungskonten einrichten und sie mit mehreren Quellkonten verknüpfen. Ein Überwachungskonto ist ein zentrales AWS Konto, das aus Quellkonten generierte Observability-Daten einsehen und mit ihnen interagieren kann. Ein Quellkonto ist ein individuelles AWS Konto, das Observabilitätsdaten für die darin enthaltenen Ressourcen generiert. Quellkonten teilen ihre Beobachtbarkeits-Daten mit dem Überwachungskonto. Sie können also geplante Abfragen vom Überwachungskonto aus einrichten, indem Sie die Protokollgruppen aller verknüpften Konten verwenden.

Alternativer Ansatz: Verwenden Sie die Zentralisierung von CloudWatch Protokollen, um Protokolldaten aus mehreren Konten und Regionen in ein zentrales Überwachungskonto zu replizieren. Auf diese Weise können Sie geplante Abfragen in einer einzigen Region erstellen, die auf alle Ihre zentralen Protokolle zugreifen. Dadurch werden regionsübergreifende Abfragen vermieden und die Verwaltung der IAM-Berechtigungen vereinfacht.

Zeitplanausdrücke und Umgang mit Zeitzonen

Der von Ihnen definierte Zeitplan bestimmt, wann Ihre Abfrage ausgeführt wird und wie oft sie ausgeführt wird. Die Auswahl des richtigen Zeitplanausdrucks wirkt sich darauf aus, wann Sie Ergebnisse erhalten und wie viele Daten Sie abfragen. Wenn Sie die Ausdruckstypen verstehen, können Sie zwischen Einfachheit und Präzision wählen.

Cron-Ausdrücke ermöglichen eine präzise Steuerung des Zeitpunkts, sodass Sie genaue Uhrzeiten, Wochentage oder Monatstage angeben können. Verwenden Sie Cron-Ausdrücke, wenn Abfragen zu bestimmten Geschäftszeiten ausgeführt oder an Betriebszeiten angepasst werden müssen. In der Konsole können Sie Abfragen auch mithilfe einfacher Kalenderoptionen planen.

Alle geplanten Abfragen werden in UTC ausgeführt, unabhängig von Ihrer lokalen Zeitzone oder dem Standort Ihrer AWS Ressourcen. Dies ist besonders wichtig, wenn Sie Abfragen für Geschäftszeiten oder für zeitkritische Analysen planen. Wenn Ihr Unternehmen beispielsweise in US Eastern Time tätig ist und Sie einen täglichen Bericht um 9 Uhr ET wünschen, müssen Sie den UTC-Offset berücksichtigen (14:00 UTC während der Sommerzeit, andernfalls 13:00 UTC). Planen Sie Ihre Zeitplanausdrücke unter Berücksichtigung der UTC, um sicherzustellen, dass Abfragen zu den vorgesehenen Zeiten ausgeführt werden.

Auswahl einer Abfragesprache

Geplante Abfragen unterstützen drei verschiedene Abfragesprachen. Ihre Wahl wirkt sich sowohl darauf aus, wie Sie Abfragen schreiben, als auch darauf, wie einfach Ihr Team sie verwalten kann. Die richtige Sprache hängt von Ihren Analyseanforderungen und den vorhandenen Fähigkeiten Ihres Teams ab.

Wenn Sie hauptsächlich Protokolldaten filtern und aggregieren, bietet CloudWatch Logs Insights Query Language die einfachste Syntax. Bei komplexen Datentransformationen, bei denen Sie Daten in mehreren Schritten umformen oder anreichern müssen, erleichtert der Pipeline-Ansatz von PPL die Nachvollziehbarkeit der Logik. Wenn Sie Verknüpfungen oder komplexe Aggregationen ähnlich wie bei Datenbankoperationen durchführen müssen, bietet SQL eine vertraute Syntax, die datenbankerfahrene Teams schnell übernehmen können.

Zielauswahl und Anwendungsfälle

Wohin Sie die Abfrageergebnisse senden, bestimmt, was Sie mit ihnen machen können. Diese Wahl beeinflusst Ihren gesamten Downstream-Workflow — unabhängig davon, ob Sie Langzeitanalysen erstellen, automatische Antworten auslösen oder beides. Wenn Sie die Stärken der einzelnen Zieltypen kennen, können Sie die richtige Architektur für Ihren Anwendungsfall entwerfen.

Amazon S3-Ziele sind für die Speicherung und Stapelverarbeitung optimiert. Wenn Sie Abfrageergebnisse über Monate oder Jahre aufbewahren, Trends im Laufe der Zeit analysieren oder Daten in Analyseplattformen einspeisen müssen, bietet Amazon S3 kostengünstigen Speicher mit unbegrenzter Aufbewahrung. EventBridge Ziele sind für die Automatisierung in Echtzeit optimiert. Wenn Abfrageergebnisse sofortige Aktionen auslösen sollen — wie das Senden von Warnmeldungen, das Starten von Workflows oder das Aktualisieren von Systemen —, werden Ergebnisse in EventBridge Form von Ereignissen geliefert, auf die Ihre Anwendungen sofort reagieren können. Standardmäßig werden alle Abfrageabschlussereignisse automatisch als Ereignisse an den Standardereignisbus gesendet, was die Integration mit nachgelagerten Verarbeitungssystemen, Lambda-Funktionen oder anderen ereignisgesteuerten Architekturen ermöglicht. Ergebnisse werden nur dann an Zielen veröffentlicht, wenn die Abfrage erfolgreich ausgeführt wurde. Die Ziele der Lookup-Tabelle sind so optimiert, dass Referenzdaten immer auf dem neuesten Stand sind. Ein Ziel einer Nachschlagetabelle füllt oder aktualisiert die angegebene Nachschlagetabelle bei jeder geplanten Ausführung automatisch mit den Abfrageergebnissen, sodass andere Abfragen mit dem Befehl auf die neuesten Daten verweisen können. lookup

Format und Struktur der Abfrageergebnisse

Geplante Abfragen liefern Ergebnisse im JSON-Format, aber jeder Zieltyp erhält eine andere Nutzlast. Bei einem Lookup-Tabellenziel werden die Abfrageergebnisse zum Inhalt der Lookup-Tabelle, und jeder Durchlauf ersetzt diesen Inhalt. Weitere Informationen finden Sie unter Konfiguration der Ziele von Lookup-Tabellen für geplante Abfragen.

Amazon S3-Ziele erhalten die Ergebniszeilen der Abfrage. Jedes Objekt enthält ein JSON-Array mit einem Eintrag für jede Zeile in der Ergebnismenge, und jeder Eintrag ordnet die Ausgabefeldnamen der Abfrage ihren Werten zu. Das Objekt enthält keine Abfrage-Metadaten oder Abfragestatistiken, und das @ptr Feld wird weggelassen, auch wenn die Abfrage es anfordert, da dieses Feld nur in der Konsole verwendet werden kann.

EventBridge Ziele erhalten Abfrage-Metadaten, einschließlich der Abfragestatistiken, aber keine Ergebniszeilen. Um die Zeilen einer abgeschlossenen Abfrage abzurufen, rufen Sie GetQueryResults mit dem Wert von queryId aus dem Ereignis auf.

Das folgende Beispiel zeigt das Ereignis, das CloudWatch Logs veröffentlicht, EventBridge wenn eine geplante Abfrage abgeschlossen ist.

{
    "version": "0",
    "id": "be72061b-eca2-e068-a7e1-83e01d6fe807",
    "detail-type": "Scheduled Query Completed",
    "source": "aws.logs",
    "account": "123456789012",
    "time": "2025-11-18T11:31:48Z",
    "region": "us-east-1",
    "resources": [
        "arn:aws:logs:us-east-1:123456789012:scheduled-query:477b4380-b098-474e-9c5e-e10a8cc2e6e7"
    ],
    "detail": {
        "queryId": "2038fd57-ab4f-4018-bb2f-61d363f4a004",
        "queryString": "fields @timestamp, @message, @logStream\n| filter @message like /ERROR/\n| sort @timestamp desc\n| limit 10000",
        "logGroupIdentifiers": [
            "/aws/lambda/my-function"
        ],
        "status": "Complete",
        "startTime": 1763465460,
        "statistics": {
            "recordsMatched": 1842,
            "recordsScanned": 48325,
            "estimatedRecordsSkipped": 0,
            "bytesScanned": 12081250,
            "estimatedBytesSkipped": 0,
            "logGroupsScanned": 1,
            "resultCount": 1842
        }
    }
}

Diese Abfrage aggregiert nicht und sie hat weniger Zeilen als 10.000 zurückgegeben, sodass jedes limit der 1.842 übereinstimmenden Protokollereignisse zu einer Ausgabezeile wurde recordsMatched und resultCount identisch ist. Eine Abfrage, die aggregiert, oder eine Abfrage, deren Ergebnismenge um gekürzt wird, ergibt einen Wertlimit, der kleiner als ist. resultCount recordsMatched Weitere Informationen finden Sie unter Grundlegendes zu RecordsScanned, RecordsMatched und ResultCount.

Zu den wichtigsten Elementen gehören:

In der folgenden Tabelle werden die einzelnen Felder des statistics Objekts beschrieben. Die API-Definitionen dieser Felder finden Sie unter QueryStatistics.

Grundlegendes zu RecordsScanned, RecordsMatched und ResultCount

Drei der Abfragestatistiken zählen verschiedene Dinge, und ein direkter Vergleich kann irreführend sein. Jeder misst eine andere Phase der Abfrageverarbeitung:

Jede Stufe schränkt die Daten ein. Ein Befehl wie stats fasst viele Protokollereignisse in einer einzigen Ausgabezeile zusammen und resultCount kann daher viel kleiner als recordsMatched sein. Eine große recordsMatched Zahl mit einer kleinen Zahl resultCount bedeutet nicht, dass Zeilen in der Ergebnismenge fehlen.

Beispiel — Aggregation

Die folgende Abfrage zählt die Fehlermeldungen in jedem Log-Stream einer Loggruppe über einen Zeitraum von einer Stunde.

filter @message like /ERROR/
| stats count(*) as errorCount by @logStream

Wenn die Abfrage 1.500.000 Protokollereignisse liest, 24.318 davon enthaltenERROR, und die entsprechenden Protokollereignisse aus 12 Protokollströmen stammen, wird die Abfrage mit den folgenden Statistiken abgeschlossen.

"statistics": {
    "recordsMatched": 24318,
    "recordsScanned": 1500000,
    "estimatedRecordsSkipped": 0,
    "bytesScanned": 450000000,
    "estimatedBytesSkipped": 0,
    "logGroupsScanned": 1,
    "resultCount": 12
}

statserzeugt eine Zeile für jeden Log-Stream, also 12 und resultCount recordsMatched 24.318. Die 12 Werte von errorCount ergeben zusammen 24.318.

Beispiel — Filter Post-aggregation

Die folgende Abfrage speichert nur die Log-Streams, die mehr als 1.000 Fehler verursacht haben.

filter @message like /ERROR/
| stats count(*) as errorCount by @logStream
| filter errorCount > 1000

Der letzte filter Befehl wird nach der Gruppierung ausgeführt, sodass Zeilen aus der Ergebnismenge entfernt werden, anstatt Ereignisse aus dem Scan zu protokollieren. Wenn 3 der 12 Log-Streams errorCount mehr als 1.000 haben, dann resultCount ist 3 statt 12. recordsScannedund ändern bytesScanned Sie nicht, da die Abfrage in beiden Fällen dieselben Protokolldaten liest.

Beispiel — Limit

Ein limit Befehl reduziert resultCount ohne jegliche Aggregation. Die folgende Abfrage gibt die 100 neuesten Fehlermeldungen zurück.

filter @message like /ERROR/
| sort @timestamp desc
| limit 100

Wenn die Abfrage dieselben 1.500.000 Protokollereignisse scannt und mit denselben 24.318 übereinstimmt, resultCount ist 100, da die Ergebnismenge auf 100 Zeilen limit begrenzt wird. In der Konsole wird für diese Beziehung angezeigt, dass 100 von 24.318 Datensätzen übereinstimmen.

Jede Statistik beantwortet eine andere Frage.