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. # Automatisieren der Protokollanalyse mit geplanten Abfragen Mit geplanten Abfragen können Sie die Ausführung von CloudWatch Logs Insights-Abfragen nach einem regelmäßigen Zeitplan automatisieren. Anstatt Abfragen zur Analyse Ihrer Protokolldaten manuell auszuführen, können Sie geplante Abfragen so konfigurieren, dass sie automatisch ausgeführt werden und Ergebnisse an Ziele wie Amazon S3 S3-Buckets oder Amazon EventBridge Event Buses liefern. Diese Automatisierung ist ideal, um regelmäßige Berichte zu erstellen, Trends zu überwachen oder nachgelagerte Prozesse auf der Grundlage von Protokollanalyseergebnissen auszulösen. Geplante Abfragen unterstützen alle drei in CloudWatch Logs Insights verfügbaren Abfragesprachen: + [**Logs Insights-Abfragesprache (Logs Insights QL)**](CWL_AnalyzeLogData_LogsInsights.md) + [**OpenSearch Sprache für die Verarbeitung per Service Piped (PPL)**](CWL_AnalyzeLogData_PPL.md) + [**OpenSearch Strukturierte Abfragesprache für Dienste (SQL)**](CWL_AnalyzeLogData_SQL.md) **Topics** + [Grundlegendes zu Konzepten für geplante Abfragen](scheduled-queries-concepts.md) + [Referenz zum Ausdruck „Zeitplan“](scheduled-queries-schedule-reference.md) + [Best Practices](scheduled-queries-best-practices.md) + [Erste Schritte mit geplanten Abfragen](scheduled-queries-getting-started.md) + [Konfiguration von S3-Zielen für geplante Abfragen](scheduled-queries-s3-destination.md) + [Problembehandlung bei geplanten Abfragen](scheduled-queries-troubleshooting.md) # 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 Geplante Abfragen erfordern zwei separate IAM-Rollen: eine für die Ausführung von Abfragen und eine weitere für die Übermittlung von Ergebnissen an Amazon S3 oder Amazon EventBridge Event Buses. Wenn Sie verstehen, warum diese Trennung existiert, können Sie Berechtigungen korrekt konfigurieren und die damit verbundenen Sicherheits- und Betriebsvorteile nutzen. Die Architektur mit zwei Rollen verteilt die Zuständigkeiten zwischen Datenzugriff und Datenbereitstellung. Die Rolle zur Abfrageausführung greift auf Ihre Protokolldaten zu und führt Abfragen aus, während die Rolle für die Zielzustellung 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. **Rolle zur Abfrageausführung** Ermöglicht CloudWatch Logs, CloudWatch Logs Insights-Abfragen in Ihrem Namen auszuführen. Diese Rolle benötigt Berechtigungen, um auf Ihre Protokollgruppen zuzugreifen und Abfragen auszuführen, benötigt jedoch keinen Zugriff auf Zielressourcen. Erforderliche Berechtigungen: + `logs:StartQuery` + `logs:StopQuery` + `logs:GetQueryResults` + `logs:DescribeLogGroups` + `logs:Unmask`wenn Daten demaskiert werden müssen **Für KMS-verschlüsselte Protokollgruppen:** `kms:Decrypt` und `kms:DescribeKey` Berechtigungen für den KMS-Schlüssel, der zum Verschlüsseln der Protokollgruppen verwendet wird. Diese Berechtigungen müssen ebenfalls hinzugefügt werden. **Anforderung einer Vertrauensbeziehung:** Die Rolle zur Abfrageausführung muss eine Vertrauensrichtlinie enthalten, die es dem CloudWatch Logs-Dienst (`logs.amazonaws.com`) ermöglicht, die Rolle zu übernehmen. Ohne diese Vertrauensstellung schlagen geplante Abfragen fehl und führen zu Berechtigungsfehlern. Beispiel für eine Vertrauensrichtlinie für die Rolle zur Abfrageausführung: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "logs.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` Beispiel für eine Berechtigungsrichtlinie für die Rolle zur Abfrageausführung: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:StartQuery", "logs:StopQuery", "logs:GetQueryResults", "logs:DescribeLogGroups" ], "Resource": "*" } ] } ``` **Rolle „Zielzustellung“** Ermöglicht CloudWatch Logs, Abfrageergebnisse an das von Ihnen gewählte Ziel zu senden. Diese Rolle benötigt nur Berechtigungen für den spezifischen Zieldienst und folgt dabei dem Prinzip der geringsten Rechte. Die erforderlichen Berechtigungen variieren je nach Zieltyp. **Anforderung einer Vertrauensbeziehung:** Die Zielzustellungsrolle muss auch eine Vertrauensrichtlinie enthalten, die es dem CloudWatch Logs-Dienst (`logs.amazonaws.com`) ermöglicht, die Rolle zu übernehmen. Beispiel für eine Berechtigungsrichtlinie für die S3-Zielzustellungsrolle: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject" ], "Resource": "arn:aws:s3:::your-scheduled-query-results-bucket/*" } ] } ``` Diese Trennung bietet praktische Vorteile für Ihren Betrieb. Wenn Sie aus Sicherheitsgründen ändern müssen, wo Ergebnisse geliefert werden, ändern Sie nur die Zielzustellungsrolle, ohne die Berechtigungen zur Abfrageausführung zu ändern. Aus Gründen der Einhaltung von Vorschriften und Prüfungen können Sie eindeutig nachverfolgen, welche Rolle auf sensible Protokolldaten zugreift und welche Rolle in externe Systeme schreibt. Auf diese Weise können Sie leichter nachweisen, dass Ihre Protokollanalyse-Infrastruktur den bewährten Sicherheitsmethoden entspricht. ## Regions- 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 alle Regionen und Konten bereitstellen. Sie müssen ein oder mehrere AWS Konten als *Überwachungskonten* einrichten und diese mit mehreren *Quellkonten* verknüpfen. Ein Überwachungskonto ist ein zentrales AWS Konto, das aus Quellkonten generierte Beobachtbarkeitsdaten einsehen und mit ihnen interagieren kann. Ein Quellkonto ist ein AWS Einzelkonto, das Beobachtbarkeitsdaten 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. **Abfragen von regionsübergreifenden Protokollgruppen** Ihre geplante Abfrage kann auf Protokollgruppen in jeder Region zugreifen. Geben Sie Protokollgruppen in ihrem vollständigen ARN-Format an:`arn:aws:logs:region:account-id:log-group:log-group-name`. Die Rolle zur Abfrageausführung benötigt `logs:StartQuery` und `logs:GetQueryResults` verfügt über Berechtigungen für Protokollgruppen in allen Zielregionen. **Wichtig** Bei der Abfrage von Protokollgruppen oder der Bereitstellung von Ergebnissen über Regionen hinweg überschreiten Protokolldaten regionale Grenzen. Berücksichtigen Sie dabei Folgendes: **Anforderungen an den Datenstandort** — Stellen Sie sicher, dass die regionsübergreifende Datenübertragung den Datenverwaltungsrichtlinien und gesetzlichen Anforderungen Ihres Unternehmens entspricht **Kosten für die Datenübertragung — Für** die regionsübergreifende Datenübertragung fallen zusätzliche Gebühren an **Netzwerklatenz** — Bei Abfragen, die auf Protokollgruppen in entfernten Regionen zugreifen, kann es zu einer höheren Latenz kommen Für optimale Leistung und Kosteneffizienz sollten Sie geplante Abfragen in derselben Region wie Ihre primären Protokollgruppen erstellen. **Alternativer Ansatz:** Verwenden Sie die [Zentralisierung von CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CloudWatchLogs_Centralization.html), um Protokolldaten aus mehreren Konten und Regionen in ein zentrales Monitoring-Konto zu replizieren. Auf diese Weise können Sie geplante Abfragen in einer einzigen Region erstellen, die auf alle Ihre zentralen Protokolle zugreifen, wodurch regionsübergreifende Abfragen vermieden und die Verwaltung der IAM-Berechtigungen vereinfacht wird. ## Zeitplanausdrücke und Zeitzonenbehandlung 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. Das Verständnis der Ausdruckstypen hilft Ihnen, zwischen Einfachheit und Präzision zu wählen. Cron-Ausdrücke ermöglichen eine präzise Steuerung des Timings, sodass Sie genaue Uhrzeiten, Wochentage oder Wochentage angeben können. Verwenden Sie Cron-Ausdrücke, wenn Abfragen zu bestimmten Geschäftszeiten ausgeführt oder mit betrieblichen Zeitplänen abgestimmt werden müssen. In der Konsole können Sie Abfragen auch mithilfe einfacher Kalenderoptionen planen. **Cron-Ausdrücke** Führen Sie Abfragen zu bestimmten Zeiten aus. Format:`cron(minute hour day-of-month month day-of-week year)`. Beispiele: + `cron(0 9 * * ? *)`- Jeden Tag um 9:00 Uhr UTC + `cron(0 18 ? * MON-FRI *)`- Wochentags um 18:00 Uhr UTC + `cron(0 0 1 * ? *)`- Erster Tag eines jeden Monats um Mitternacht UTC + `cron(0 12 ? * SUN *)`- Jeden Sonntag um 12:00 Uhr UTC + `cron(30 8 1 1 ? *)`- 1. Januar um 8:30 Uhr UTC 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 zeitkritische Analysen planen. Wenn Ihr Unternehmen beispielsweise in der US-Ostzeit 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, 13:00 UTC andernfalls). Denken Sie bei der Planung Ihrer Zeitplanausdrücke an die UTC-Zeit, um sicherzustellen, dass Abfragen zu den vorgesehenen Zeiten ausgeführt werden. ## Wählen Sie eine 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 die CloudWatch Logs Insights Query Language die einfachste Syntax. Bei komplexen Datentransformationen, bei denen Sie Daten in mehreren Schritten umformen oder anreichern müssen, macht der Pipeline-Ansatz von PPL die Logik einfacher nachvollziehbar. Wenn Sie Verknüpfungen oder komplexe Aggregationen durchführen müssen, die Datenbankoperationen ähneln, bietet SQL eine vertraute Syntax, die datenbankerfahrene Teams schnell anwenden können. **CloudWatch Logs Insights Query Language (CWLI)** Speziell für die Protokollanalyse mit intuitiver Syntax entwickelt. Am besten geeignet für: + Textbasierte Protokollanalyse und Filterung + Aggregationen und Statistiken von Zeitreihen + Teams, die noch keine Erfahrung mit Protokollanalyse haben **OpenSearch Service Piped Processing Language (PPL)** Pipeline-basierte Abfragesprache mit leistungsstarken Funktionen zur Datentransformation. Am besten geeignet für: + Komplexe Datentransformationen und Anreicherung + Mehrstufige Datenverarbeitungs-Workflows + Teams, die mit der Verarbeitung auf Pipeline-Basis vertraut sind **OpenSearch Service Structured Query Language (SQL)** Standard-SQL-Syntax für vertraute Abfragen im Datenbankstil. Am besten geeignet für: + Komplexe Verknüpfungen und Aggregationen + Business Intelligence und Berichterstattung + Teams mit langjähriger SQL-Erfahrung ## Zielauswahl und Anwendungsfälle Wohin Sie Abfrageergebnisse senden, bestimmt, was Sie mit ihnen machen können. Diese Wahl beeinflusst Ihren gesamten nachgelagerten Workflow — unabhängig davon, ob Sie Langzeitanalysen erstellen, automatisierte 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 S3-Ziele sind für Speicherung und Stapelverarbeitung optimiert. Wenn Sie Abfrageergebnisse monatelang oder jahrelang aufbewahren, Trends im Zeitverlauf analysieren oder Daten in Analyseplattformen einspeisen müssen, bietet Amazon S3 kostengünstigen Speicherplatz mit unbegrenzter Aufbewahrung. EventBridge Ziele sind für die Automatisierung in Echtzeit optimiert. Wenn Abfrageergebnisse sofortige Aktionen auslösen sollen, z. B. das Senden von Benachrichtigungen, das Starten von Workflows oder das Aktualisieren von Systemen, werden die Ergebnisse EventBridge als Ereignisse angezeigt, auf die Ihre Anwendungen sofort reagieren können. Standardmäßig werden alle Abfrageabschlussereignisse automatisch als Ereignisse an den Standard-Event-Bus gesendet, was die Integration mit Downstream-Verarbeitungssystemen, Lambda-Funktionen oder anderen ereignisgesteuerten Architekturen ermöglicht. Ergebnisse werden nur dann an Ziele veröffentlicht, wenn die Abfrage erfolgreich ausgeführt wurde. **Amazon-S3-Ziele** Speichern Sie Abfrageergebnisse als JSON-Dateien für die langfristige Aufbewahrung und Stapelverarbeitung. Am besten geeignet für: + Historische Analyse und Datenarchivierung + Integration mit Data Lakes und Analyseplattformen + Konformitäts- und Prüfanforderungen + Kostengünstige Speicherung großer Ergebnismengen **EventBridge Destinationen** Senden Sie Abfrageergebnisse als Ereignisse für die Verarbeitung und Automatisierung in Echtzeit. Sie können Abfrageergebnisse mit der im Ereignis gesendeten queryId nur bis zu 30 Tage abrufen, da wir die Ergebnisse für 30 Tage speichern. Am besten geeignet für: + Auslösen automatisierter Antworten auf Abfrageergebnisse + Integration mit serverlosen Workflows und Lambda-Funktionen + Warn- und Benachrichtigungssysteme in Echtzeit + Ereignisgesteuerte Architekturen und Microservices ## Format und Struktur der Abfrageergebnisse Für Amazon S3 S3-Ziele — Abfrageergebnisse werden im JSON-Format mit derselben Struktur wie die GetQueryResults API-Antwort geliefert. Für Amazon hilft Ihnen das EventBridge Verständnis des Formats der geplanten Abfrageergebnisse bei der Gestaltung nachgelagerter Verarbeitungs- und Integrationsworkflows. Abfrageergebnisse werden im JSON-Format mit der folgenden Struktur geliefert: ``` { "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, @log\n| sort @timestamp desc\n| limit 10000", "logGroupIdentifiers": [ "/aws/lambda/my-function" ], "status": "Complete", "startTime": 1763465460, "statistics": { "recordsMatched": 0, "recordsScanned": 0, "estimatedRecordsSkipped": 0, "bytesScanned": 0, "estimatedBytesSkipped": 0, "logGroupsScanned": 1 } } } ``` Zu den wichtigsten Elementen gehören: + `statistics`- Leistungskennzahlen für Abfragen, einschließlich übereinstimmender, gescannter, verarbeiteter Byte und geschätzter übersprungener Daten + `startTime`— Wann die Ausführung der Abfrage gestartet wurde (Unix-Zeitstempel) + `queryString`- Die eigentliche Abfrage, die ausgeführt wurde + `queryId`- Abfrage-ID der Abfrage, mit der Ergebnisse abgerufen werden können + `logGroupIdentifiers`- Liste der Protokollgruppen, die abgefragt wurden + `status`- Ausführungsstatus abfragen (Abgeschlossen, Fehlgeschlagen usw.) # Referenz zum Ausdruck „Zeitplan“ Verwenden Sie diese Referenztabellen, um Zeitplanausdrücke für Ihre geplanten Abfragen zu erstellen. Alle Uhrzeiten sind in UTC angegeben. **Syntax von Cron-Ausdrücken** Format: `cron(minute hour day-of-month month day-of-week year)` | Anwendungsfall | Cron-Ausdruck | Description | Verwenden Sie Wann | | --- | --- | --- | --- | | Tagespläne | cron(0 9 \$1 \$1 ? \$1) | Jeden Tag um 9:00 Uhr UTC | Tägliche Berichte | | | cron(0 \$1/6 \$1 \$1 ? \$1) | Alle 6 Stunden (00:00, 06:00, 12:00, 18:00 UTC) | Häufige Überwachung | | | cron(30 2 \$1 \$1 ? \$1) | Jeden Tag um 2:30 Uhr UTC | Analyse außerhalb der Spitzenzeiten | | Geschäftszeiten | cron(0 9-17 ? \$1 MON-FRI \$1) | Jede Stunde von 9 Uhr bis 17 Uhr, Montag bis Freitag UTC | Überwachung von Unternehmen | | | cron(0 18 ? \$1 MON-FRI \$1) | Wochentags um 18:00 Uhr UTC | Ende des Geschäftstages | | | cron(0 8,12,17 ? \$1 MON-FRI \$1) | 8 Uhr, 12 Uhr und 17 Uhr an Wochentagen UTC | Wichtige Geschäftszeiten | | Wöchentliche Zeitpläne | cron(0 12 ? \$1 SUN \$1) | Jeden Sonntag um 12 Uhr UTC | Wöchentliche Zusammenfassungen | | | cron(0 9 ? \$1 MON \$1) | Jeden Montag um 9:00 Uhr UTC | Berichte zum Wochenstart | | | cron(0 23 ? \$1 FRI \$1) | Jeden Freitag um 23:00 Uhr UTC | Aufräumen am Wochenende | | Monatliche Zeitpläne | cron(0 0 1 \$1 ? \$1) | Erster Tag eines jeden Monats um Mitternacht UTC | Monatliche Berichte | | | cron(0 9 L \$1 ? \$1) | Letzter Tag jedes Monats um 9:00 Uhr UTC | Verarbeitung zum Monatsende | | | cron(0 10 1 1,4,7,10 ? \$1) | Erster Tag jedes Quartals um 10:00 Uhr UTC | Vierteljährliche Analyse | | Hohe Frequenz | cron(\$1/15 \$1 \$1 \$1 ? \$1) | Alle 15 Minuten | Überwachung in Echtzeit | | | cron(0,30 \$1 \$1 \$1 ? \$1) | Alle 30 Minuten (um :00 Uhr und :30 Uhr) | Häufige Kontrollen | | | cron(0 \$1/2 \$1 \$1 ? \$1) | Alle 2 Stunden | Regelmäßige Intervalle | | Sonderfälle | cron(30 8 1 1 ? \$1) | 1. Januar um 8:30 Uhr UTC | Jahresberichte | | | cron(0 6 \$1 \$1 SAT,SUN \$1) | Am Wochenende um 6:00 Uhr UTC | Bearbeitung am Wochenende | | | cron(0 0 ? \$1 MON\$11 \$1) | Jeden ersten Montag im Monat um Mitternacht UTC | Monatliche Planung | **Feldverweis auf den Cron-Ausdruck** | Feld | Werte | Platzhalter | Beispiele | | --- | --- | --- | --- | | Minute (1.) | 0-59 | \$1 , - / | 0(Höhepunkt der Stunde), \$1/15 (alle 15 Minuten), 0,30 (zweimal pro Stunde) | | Stunde (2.) | 0-23 | \$1 , - / | 9(9 Uhr), \$1/2 (alle 2 Stunden), 9-17 (Geschäftszeiten) | | Day-of-month (3.) | 1-31, L, W | \$1 , - / ? | 1(1. Tag), L (letzter Tag), ? (bei Verwendung day-of-week) | | Monat (4.) | 1-12 oder JAN-DEC | \$1 , - / | 1(Januar)JAN, 1,4,7,10 (vierteljährlich) | | Day-of-week (5.) | 1-7 oder SUN-SAT | \$1 , - / ? \$1 L | MON-FRI(wochentags)SUN,, MON\$11 (1. Montag) | | Jahr (6.) | 1970-2199 | \$1 , - / | \$1(jedes Jahr), 2024 (bestimmtes Jahr), 2024-2026 (Bereich) | **Platzhalterzeichen und Sonderausdrücke** **`*` (Sternchen)** Entspricht allen Werten im Feld. Beispiel: `*` Im Stundenfeld bedeutet das jede Stunde. **`?`(Fragezeichen)** Kein spezifischer Wert. Wird in day-of-month oder verwendet day-of-week, wenn der andere Wert angegeben ist. Beispiel: Verwenden Sie `?` in day-of-month, wenn Sie `MON-FRI` in angeben day-of-week. **`-` (Bindestrich)** Wertebereich. Beispiel: `MON-FRI` (Montag bis Freitag), `9-17` (9 Uhr bis 17 Uhr). **`,`(Komma)** Mehrere spezifische Werte. Beispiel: `MON,WED,FRI` (Montag, Mittwoch, Freitag), `8,12,17` (8 Uhr, Mittag, 17 Uhr). **`/`(Schrägstrich)** Schrittwerte oder Inkremente. Beispiel: `0/15` In Minuten bedeutet alle 15 Minuten ab Minute 0 (0, 15, 30, 45). `*/2`in Stunden bedeutet alle 2 Stunden. **`L`(zuletzt)** Letzter Tag des Monats oder letztes Vorkommen des Wochentags. Beispiel: `L` In day-of-month bedeutet letzter Tag des Monats. `FRIL`bedeutet letzten Freitag im Monat. **`W`(Wochentag)** Nächster Wochentag. Beispiel: `15W` bedeutet, dass der Wochentag dem 15. des Monats am nächsten liegt. **`#`(n-tes Vorkommen)** N-tes Vorkommen eines Wochentags in einem Monat. Beispiel: `MON#1` bedeutet ersten Montag im Monat, `FRI#2` bedeutet zweiten Freitag im Monat. **Allgemeine Muster und bewährte Verfahren** + **Für Geschäftsanwendungen:** Nutzung `MON-FRI` und Geschäftszeiten (z. B.`9-17`), um zu vermeiden, dass Anfragen an Wochenenden oder außerhalb der Geschäftszeiten laufen. + **Für die Überwachung mit hoher Frequenz:** Verwenden Sie Inkremente wie `*/15` (alle 15 Minuten), beachten Sie jedoch die Grenzwerte für die Parallelität von Abfragen. + **Aus Gründen der Ressourceneffizienz:** Planen Sie ressourcenintensive Abfragen außerhalb der Spitzenzeiten und verwenden Sie dabei frühe Morgenzeiten wie UTC. `2-6` + **Für monatliche Berichte: Verwenden Sie diese Option** `L` für den letzten Tag des Monats oder für bestimmte Daten, z. B. `1` für den ersten Tag, um ein einheitliches Timing zu gewährleisten. # Best Practices Halten Sie sich an die folgenden bewährten Methoden, um zuverlässige und effiziente geplante Abfragevorgänge sicherzustellen: **Optimierung von Abfragen** + Testen Sie Abfragen vor der Planung manuell, um Leistung und Ergebnisse zu überprüfen + Verwenden Sie zu Beginn Ihrer Abfrage Filterindizes, um die Datenverarbeitung zu reduzieren + Begrenzen Sie Zeitbereiche, um Timeouts bei Protokollgruppen mit hohem Volumen zu vermeiden + Berücksichtigen Sie die Komplexität der Abfragen und die Zeitlimits für die Ausführung **Planung des Zeitplans** + Vermeiden Sie sich überschneidende Ausführungen, indem Sie sicherstellen, dass Abfragen vor der nächsten geplanten Ausführung abgeschlossen sind + Berücksichtigen Sie bei der Festlegung von Zeitbereichen Verzögerungen bei der Protokollaufnahme + Verwenden Sie Cron-Ausdrücke für bestimmte Zeiten + Verteilen Sie die Zeitpläne, um sicherzustellen, dass Sie das Limit für die Parallelität von Abfragen nicht überschreiten **Überwachung und Wartung** + Überwachen Sie den Ausführungsverlauf regelmäßig, um Ausfälle oder Leistungsprobleme zu identifizieren + Überprüfen und aktualisieren Sie die IAM-Rollen regelmäßig, um die Sicherheit zu gewährleisten + Testen Sie den Zugriff auf das Ziel, bevor Sie es in der Produktion einsetzen **Autorisierung** + Alle Abfragen APIs für geplante Abfragen autorisieren für die geplante Abfrageressource und nicht für die Ressourcen, die für die Eingabe benötigt werden, wie z. B. Protokollgruppen. Richten Sie die IAM-Richtlinien entsprechend ein + Verwalten Sie die Autorisierung von Protokollgruppen mithilfe der Ausführungsrolle, die in der APIs # Erste Schritte mit geplanten Abfragen Wenn Sie eine geplante Abfrage erstellen, konfigurieren Sie mehrere wichtige Komponenten, die definieren, wie Ihre Abfrage ausgeführt wird und wohin die Ergebnisse geliefert werden. Wenn Sie sich mit diesen Komponenten vertraut machen, können Sie eine effektive automatisierte Protokollanalyse einrichten. Jede geplante Abfrage besteht aus den folgenden Schlüsselkomponenten: **Konfiguration der Abfrage** Die CloudWatch Logs Insights-Abfragezeichenfolge, die Zielprotokollgruppen und die Abfragesprache, die für die Analyse verwendet werden sollen. **Ausdruck zeitlich planen** Ein Cron-Ausdruck oder ein Frequenzkalender, der definiert, wann die Abfrage ausgeführt wird. Sie können Zeitzoneneinstellungen angeben, um sicherzustellen, dass Abfragen zur richtigen Ortszeit ausgeführt werden. Die Konsole zeigt eine für Menschen lesbare Beschreibung Ihres Zeitplans an, z. B. „Führen Sie die Abfrage jeden Dienstag um 15:10 Uhr für einen Zeitraum von 5 Minuten aus, mit sofortiger Wirkung auf UTC, bis auf unbestimmte Zeit“. **Zeitraum** Der Lookback-Zeitraum für jede Abfrageausführung, definiert durch einen Abstand zwischen der Startzeit und der Ausführungszeit. Dies bestimmt, wie viele historische Daten bei jeder Abfrageausführung analysiert werden. **Vorschau des Ausführungsplans** Die Konsole zeigt die nächsten drei geplanten Abfrageläufe mit genauen Datums- und Uhrzeitangaben an (z. B. 2025/10/28 15:10, UTC; 2025/11/04 15:10, UTC; 2025/11/11 15:10, UTC), sodass Sie überprüfen können, ob der Zeitplan korrekt konfiguriert ist. **Ziele** Wo Abfrageergebnisse nach erfolgreicher Ausführung geliefert werden. Zu den unterstützten Zielen gehören Amazon S3 S3-Buckets, und standardmäßig werden Ergebnismetadaten an den Standard-Event-Bus gesendet. **Rolle „Ausführung“** Eine IAM-Rolle, von der CloudWatch Logs annimmt, um die Abfrage auszuführen und Ergebnisse an die angegebenen Ziele zu liefern. Stellen Sie vor dem Erstellen von geplanten Abfragen sicher, dass Sie die erforderlichen Berechtigungen und Ressourcen konfiguriert haben. # Eine geplante Abfrage erstellen Erstellen Sie eine geplante Abfrage, die automatisch CloudWatch Logs Insights-Abfragen ausführt und Ergebnisse an die von Ihnen ausgewählten Ziele liefert. ## Voraussetzungen Bevor Sie eine geplante Abfrage erstellen, stellen Sie sicher, dass Sie über Folgendes verfügen: + **Protokollgruppen** — Eine oder mehrere Protokollgruppen, die die Daten enthalten, die Sie analysieren möchten + **Ausführungs-IAM-Rolle** — Eine IAM-Rolle mit den folgenden Berechtigungen: + `logs:StartQuery`— Berechtigung zum Starten von CloudWatch Logs Insights-Abfragen + `logs:GetQueryResults`- Erlaubnis zum Abrufen von Abfrageergebnissen + `logs:DescribeLogGroups`- Berechtigung zum Zugriff auf Protokollgruppeninformationen. Dies ist nur für präfixbasierte Protokollgruppen zur Erkennung von Protokollgruppen erforderlich + **Zielberechtigungen** — Zusätzliche IAM-Berechtigungen für das von Ihnen gewählte Ziel: + Für Amazon S3 S3-Ziele: `s3:PutObject` + **Für AWS CLI und API-Nutzung** — Konfigurierte AWS Anmeldeinformationen mit Berechtigungen zum Aufrufen von CloudWatch Logs APIs Ausführliche Beispiele für IAM-Richtlinien finden Sie unter[Identitäts- und Zugriffsmanagement für Amazon CloudWatch Logs](auth-and-access-control-cwl.md). Beachten Sie außerdem, dass Sie pro Konto nur 1000 geplante Abfragen haben können. ------ #### [ Console ] **Um eine geplante Abfrage zu erstellen (Konsole)** 1. Die CloudWatch Logs-Konsole zu [https://us-east-1.console.aws.amazon.com/cloudwatch/Hause öffnen? region=us-east-1](https://us-east-1.console.aws.amazon.com/cloudwatch/home?region=us-east-1#logsV2:logs-insights) \$1logsV2: Logs-Einblicke. 1. **Wählen Sie im Navigationsbereich Logs Insights aus.** 1. Wählen Sie **Geplante Abfrage erstellen** aus. 1. Gehen Sie im Abschnitt **Abfragedefinition** wie folgt vor: 1. Wählen Sie **unter Abfragesprache** die zu verwendende Abfragesprache aus der Liste aus. 1. Geben Sie als **Abfragezeichenfolge** Ihre CloudWatch Logs Insights-Abfrage in das Feld ein. 1. Wählen Sie für **Protokollgruppen** die abzufragenden Protokollgruppen aus der Liste aus. 1. Gehen Sie im Abschnitt **Einrichtung des Zeitplans** wie folgt vor: 1. Konfigurieren Sie für den **Ausdruck Schedule**, wann die Abfrage ausgeführt wird. Wählen Sie aus vordefinierten Optionen oder geben Sie einen benutzerdefinierten Cron-Ausdruck ein. 1. Geben Sie **unter Gültig bei der Erstellung** an, wann der Zeitplan aktiv wird. Wählen Sie mithilfe des YYYY/MM/DD Formats, ob der Start sofort oder an einem bestimmten Datum und zu einer bestimmten Uhrzeit erfolgen soll. 1. Geben Sie **unter Zeitraum** den Lookback-Zeitraum für jede Abfrageausführung an. Geben Sie die Dauer in Minuten ein, die definiert, wie weit die Abfrage von der Ausführungszeit zurückliegt. 1. Geben **Sie für Auf unbestimmte Zeit fortsetzen** an, wann der Zeitplan endet. Wählen Sie mithilfe des Formats, ob die Ausführung auf unbestimmte Zeit oder bis zu einem bestimmten Datum und einer bestimmten Uhrzeit erfolgen YYYY/MM/DD soll. 1. In der Konsole werden die nächsten drei geplanten Abfrageläufe basierend auf Ihrer Konfiguration angezeigt. Dabei werden die genauen Datums- und Uhrzeitangaben in UTC angezeigt, zu denen die Abfrage ausgeführt wird. 1. Im Abschnitt **Abfrageergebnisse an S3 senden — optional** (wenn Sie das S3-Ziel verwenden): 1. Wählen Sie für **S3-Bucket** **Dieses Konto** aus, wenn sich der Ziel-Bucket in demselben AWS Konto befindet, oder wählen Sie Anderes **Konto aus, wenn sich der Bucket in einem anderen** AWS Konto befindet, und geben Sie die Konto-ID des Kontos, das den Bucket besitzt, als Eingabe ein. 1. Geben Sie für **Amazon S3 S3-URI** den Amazon S3 S3-Bucket und das Präfix ein, in dem die Ergebnisse gespeichert werden (z. B.`s3://my-bucket/query-results/`). Wenn Sie **Dieses Konto** ausgewählt haben, können Sie **Amazon S3 durchsuchen wählen, um zu einem vorhandenen Amazon S3 S3-Standort** zu navigieren und diesen auszuwählen. 1. (Optional) Geben Sie für den **KMS-Schlüssel-ARN** den ARN eines vom Kunden verwalteten AWS KMS Schlüssels ein, um die Abfrageergebnisse mit SSE-KMS zu verschlüsseln. Der Schlüssel muss sich in derselben AWS Region wie der Amazon S3-Ziel-Bucket befinden. 1. Wählen Sie im Abschnitt **IAM-Rolle für die Veröffentlichung von Abfrageergebnissen in Amazon S3** eine der folgenden Optionen aus: 1. Wählen Sie **Neue Rolle mit Standardberechtigungen automatisch erstellen**, um automatisch eine IAM-Rolle mit den erforderlichen Berechtigungen einzurichten, damit CloudWatch Logs Abfrageergebnisse an Amazon S3 liefern kann. 1. Wählen Sie **Bestehende Rolle verwenden**, um eine bestehende IAM-Rolle mit den erforderlichen Richtlinien für CloudWatch Logs auszuwählen, um Abfrageergebnisse an Amazon S3 zu liefern. Verwenden Sie das Suchfeld, um die entsprechende IAM-Rolle aus der Liste zu finden und auszuwählen. 1. Wählen Sie im Abschnitt **IAM-Rolle für die geplante Abfrageausführung** eine der folgenden Optionen aus: 1. Wählen Sie **Neue Rolle mit Standardberechtigungen automatisch erstellen**, um automatisch eine IAM-Rolle mit den für CloudWatch Logs erforderlichen Berechtigungen einzurichten, um geplante Abfragen auszuführen. 1. Wählen Sie „**Bestehende Rolle verwenden**“, um eine bestehende IAM-Rolle mit den erforderlichen Richtlinien für CloudWatch Logs auszuwählen, um geplante Abfragen auszuführen. Verwenden Sie das Suchfeld, um die entsprechende IAM-Rolle aus der Liste zu finden und auszuwählen. 1. Wählen Sie **Zeitplan erstellen**, um die geplante Abfrage zu erstellen. ------ #### [ AWS CLI ] **Um eine geplante Abfrage zu erstellen (AWS CLI)** + Verwenden Sie den `create-scheduled-query` Befehl, um eine neue geplante Abfrage zu erstellen: ``` aws logs create-scheduled-query \ --name "ErrorAnalysisQuery" \ --query-language "CWLI" \ --query-string "fields @timestamp, @message | filter @message like /ERROR/ | stats count() by bin(5m)" \ --schedule-expression "cron(8 * * * ? *)" \ --execution-role-arn "arn:aws:iam::123456789012:role/CloudWatchLogsScheduledQueryRole" \ --log-group-identifiers "/aws/lambda/my-function" "/aws/apigateway/my-api" \ --state "ENABLED" ``` ------ #### [ API ] **Um eine geplante Abfrage (API) zu erstellen** + Verwenden Sie die `CreateScheduledQuery` Aktion, um eine neue geplante Abfrage zu erstellen. Im folgenden Beispiel wird eine geplante Abfrage erstellt, die jede Stunde ausgeführt wird: ``` { "name": "ErrorAnalysisQuery", "queryLanguage": "CWLI", "queryString": "fields @timestamp, @message | filter @message like /ERROR/ | stats count() by bin(5m)", "scheduleExpression": "cron(8 * * * ? *)", "executionRoleArn": "arn:aws:iam::123456789012:role/CloudWatchLogsScheduledQueryRole", "logGroupIdentifiers": ["/aws/lambda/my-function", "/aws/apigateway/my-api"], "state": "ENABLED" } ``` ------ Nachdem Sie die geplante Abfrage erstellt haben, können Sie sie auf der Seite **Geplante Abfragen** und mithilfe der ListScheduledQueries API anzeigen und verwalten. Dort werden alle Ihre geplanten Abfragen mit ihren Namen, Erstellungsdaten, dem Status der letzten Ausführung, der Uhrzeit der letzten Auslösung und der Wiederholungshäufigkeit angezeigt. # Geplante Abfragen anzeigen und verwalten Die folgenden Informationen sind für jede Abfrage verfügbar: **Name** Der eindeutige Name, den Sie der geplanten Abfrage zugewiesen haben. Wählen Sie den Namen aus, um den detaillierten Verlauf der Konfiguration und Ausführung anzuzeigen. **Erstellungsdatum** Das Datum, an dem die geplante Abfrage erstellt wurde, wird im YYYY-MM-DD Format angezeigt. **Status der letzten Ausführung** Der Ausführungsstatus des letzten Abfragelaufs. Mögliche Werte sind: + **Abgeschlossen** — Die Abfrage wurde erfolgreich ausgeführt und die Ergebnisse wurden an alle konfigurierten Ziele übermittelt. + **Fehlgeschlagen** — Die Ausführung der Abfrage oder die Übermittlung der Ergebnisse ist fehlgeschlagen. Einzelheiten zu den Fehlern finden Sie im Ausführungsverlauf. + **Ungültige Abfrage** — Die Abfrage ist ungültig und weist syntaktische Probleme auf + **Timeout** — Das Zeitlimit für die Abfrage wurde überschritten. Bei einer Abfrage wird das Timeout automatisch nach 60 Minuten überschritten **Zeitpunkt des letzten Auslösens** Datum und Uhrzeit der letzten Ausführung der Abfrage, angezeigt im YYYY-MM-DD Format HH:MM:SS. Zeigt **Nie** an, wenn die Abfrage noch nicht ausgeführt wurde. **Alle werden wiederholt** Die Häufigkeit des Zeitplans für die Abfrage. Zeigt **Benutzerdefiniert** für Abfragen an, die Cron-Ausdrücke oder spezifische Häufigkeitsbeschreibungen für einfachere Zeitpläne verwenden. Die Seite **Geplante Abfragen** bietet einen Überblick über all Ihre geplanten Abfragen und zeigt deren aktuellen Status und Ausführungsverlauf an, sodass Sie all Ihre geplanten Abfragen von einem zentralen Ort aus anzeigen, überwachen und verwalten können. Verwenden Sie diese Informationen, um die Abfrageleistung zu überwachen, Probleme zu identifizieren und Ihre automatisierten Protokollanalyse-Workflows zu verwalten. ------ #### [ Console ] **So zeigen Sie geplante Abfragen an (Konsole)** 1. Die CloudWatch Logs-Konsole zu [https://us-east-1.console.aws.amazon.com/cloudwatch/Hause öffnen? region=us-east-1](https://us-east-1.console.aws.amazon.com/cloudwatch/home?region=us-east-1#logsV2:logs-insights) \$1logsV2: Logs-Einblicke. 1. ****Wählen Sie in der CloudWatch Logs-Konsole die Optionen Geplante Abfrage und Geplante Abfragen anzeigen aus.**** ------ #### [ AWS CLI ] **Um geplante Abfragen aufzulisten (AWS CLI)** + Verwenden Sie den `list-scheduled-queries` Befehl, um alle geplanten Abfragen aufzulisten: ``` aws logs list-scheduled-queries --max-results 10 ``` ------ #### [ API ] **Um geplante Abfragen aufzulisten (API)** + Verwenden Sie die `ListScheduledQueries` Aktion, um alle geplanten Abfragen abzurufen: ``` { "maxResults": 10 } ``` ------ In der Kopfzeile der Seite **Geplante Abfragen** wird die Gesamtzahl der geplanten Abfragen in Ihrem Konto angezeigt, sodass Sie Ihre Nutzung verfolgen und Ihre automatisierten Protokollanalyse-Workflows effektiv verwalten können. # Den Verlauf der Ausführung geplanter Abfragen anzeigen Verwenden Sie den Ausführungsverlauf, um die Leistung Ihrer geplanten Abfragen zu überwachen und Probleme bei der Abfrageausführung oder Ergebnislieferung zu beheben. In der Ausführungshistorie wird der Status der einzelnen Abfrageläufe angezeigt, einschließlich erfolgreicher Ausführungen, Fehlschläge und Ergebnisse der Zielverarbeitung. Sie können diese Informationen verwenden, um Muster zu identifizieren, Probleme zu diagnostizieren und zu überprüfen, ob Ihre Abfragen erwartungsgemäß ausgeführt werden. ------ #### [ Console ] **So zeigen Sie den Ausführungsverlauf an (Konsole)** 1. Wählen Sie in der CloudWatch Protokollkonsole die Optionen **Geplante Abfrage** und **Geplante Abfragen anzeigen** aus. 1. Wählen Sie die geplante Abfrage aus, die Sie untersuchen möchten. 1. Wählen Sie die Registerkarte **Execution history (Ausführungsverlauf)**. ------ #### [ AWS CLI ] **Um den Ausführungsverlauf anzuzeigen (AWS CLI)** 1. Verwenden Sie den `get-scheduled-query-history` Befehl, um den Ausführungsverlauf für eine geplante Abfrage abzurufen: ``` aws logs get-scheduled-query-history \ --identifier "DailyErrorMonitoring" \ --start-time 1743379200 \ --end-time 1743465600 \ --max-results 10 ``` 1. Um nach dem Ausführungsstatus zu filtern, fügen Sie den folgenden `--execution-statuses` Parameter hinzu: ``` aws logs get-scheduled-query-history \ --identifier "DailyErrorMonitoring" \ --start-time 1743379200 \ --end-time 1743465600 \ --max-results 1 \ --execution-statuses "SUCCEEDED" ``` ------ #### [ API ] **Um den Ausführungsverlauf (API) anzuzeigen** + Verwenden Sie die `GetScheduledQueryHistory` Aktion, um den Ausführungsverlauf abzurufen: ``` { "identifier": "DailyErrorMonitoring", "startTime": 1743379200, "endTime": 1743465600, "maxResults": 10, "executionStatuses": ["SUCCEEDED", "FAILED"] } ``` ------ In der Ausführungshistorie wird Folgendes angezeigt: + **Ausführungsstatus** — Wird ausgeführt, Abgeschlossen, Fehlgeschlagen, Timeout oder InvalidQuery + **Ausgelöste Zeit** — Wann die Abfrage ausgeführt wurde + **Ziele** — Verarbeitungsstatus für jedes konfigurierte Ziel, einschließlich S3 und EventBridge + **Fehlermeldungen** — Einzelheiten zu Fehlern bei der Abfrageausführung oder Zielverarbeitung # Aktualisierung einer geplanten Abfrage Ändern Sie Ihre Konfiguration für geplante Abfragen, um die Abfragezeichenfolge, den Zeitplan, die Ziele oder die Ausführungsrolle entsprechend Ihren Anforderungen zu ändern. Sie können jeden Aspekt einer geplanten Abfrage aktualisieren, einschließlich der Abfragezeichenfolge, des Zeitplanausdrucks, der Ziele und der Ausführungsrolle. Änderungen werden sofort für future Ausführungen wirksam. ------ #### [ Console ] **Um eine geplante Abfrage zu aktualisieren (Konsole)** 1. Wählen Sie in der CloudWatch Protokollkonsole die Optionen **Geplante Abfrage** und **Geplante Abfragen anzeigen** aus. 1. Wählen Sie die geplante Abfrage aus, die Sie aktualisieren möchten. 1. Wählen Sie **Bearbeiten** aus. 1. Ändern Sie die Konfiguration nach Bedarf. 1. Wählen Sie **Änderungen speichern ** aus. ------ #### [ AWS CLI ] **Um eine geplante Abfrage zu aktualisieren (AWS CLI)** + Verwenden Sie den `update-scheduled-query` Befehl, um eine bestehende geplante Abfrage zu ändern: ``` aws logs update-scheduled-query \ --identifier "arn:aws:logs:us-east-1:111122223333:scheduled-query:5e0c0228-1c29-4d26-904f-59f1f1ba3c8f" \ --description "Monitor for ERROR level logs daily" \ --query-language "LogsQL" \ --query-string "fields @timestamp, @message | filter @message like /ERROR/" \ --log-group-identifiers "/aws/lambda/my-function-1" "/aws/lambda/my-function-2" ``` ------ #### [ API ] **Um eine geplante Abfrage (API) zu aktualisieren** 1. Verwenden Sie die `UpdateScheduledQuery` Aktion, um die Konfiguration der geplanten Abfrage zu ändern: ``` { "identifier": "arn:aws:logs:us-east-1:111122223333:scheduled-query:5e0c0228-1c29-4d26-904f-59f1f1ba3c8f", "queryString": "fields @timestamp, @message | filter @message like /WARNING|ERROR/ | stats count() by bin(5m)", "scheduleExpression": "cron(0 */2 * * ? *)", "state": "ENABLED" } ``` 1. Um mehrere Konfigurationsparameter gleichzeitig zu aktualisieren: ``` { "identifier": "arn:aws:logs:us-east-1:111122223333:scheduled-query:5e0c0228-1c29-4d26-904f-59f1f1ba3c8f", "queryString": "fields @timestamp, @message, @level | filter @level = 'ERROR'", "scheduleExpression": "cron(0 8,12,16 * * ? *)", "executionRoleArn": "arn:aws:iam::111122223333:role/UpdatedScheduledQueryRole", "logGroupIdentifiers": ["/aws/lambda/my-function", "/aws/lambda/another-function"], "destinationConfiguration": { "s3Configuration": { "destinationIdentifier": "s3://111122223333-sqn-results-bucket/processed-results", "roleArn": "arn:aws:iam::111122223333:role/Admin" } } } ``` ------ # Konfiguration von S3-Zielen für geplante Abfragen Konfigurieren Sie Amazon S3 als Ziel, um Ihre geplanten Abfrageergebnisse als JSON-Dateien zur langfristigen Aufbewahrung und Analyse zu speichern. Wenn Sie Amazon S3 als Ziel verwenden, werden Abfrageergebnisse als JSON-Dateien im angegebenen Bucket und Präfix gespeichert. Diese Option ist ideal für die Archivierung von Ergebnissen, die Durchführung von Batch-Analysen oder die Integration mit anderen AWS Diensten, die S3-Daten verarbeiten. Sie können Abfrageergebnisse an einen Amazon S3 S3-Bucket in demselben AWS Konto wie die geplante Abfrage oder an einen Bucket in einem anderen AWS Konto senden. Optional können Sie Abfrageergebnisse auch mit einem vom Kunden verwalteten AWS KMS Schlüssel (SSE-KMS) verschlüsseln. ## Ergebnisse an einen Amazon S3 S3-Bucket im selben Konto senden Wenn sich der Amazon S3 S3-Ziel-Bucket in demselben AWS Konto wie die geplante Abfrage befindet, können Sie den Bucket direkt von der Konsole aus suchen und auswählen. **So konfigurieren Sie ein Amazon S3 S3-Ziel mit demselben Konto (Konsole)** 1. Wählen **Sie im Abschnitt Abfrageergebnisse an S3 senden** für **S3-Bucket** die Option **Dieses** Konto aus. 1. Geben Sie für **Amazon S3-URI** den Amazon S3 S3-Bucket und das Präfix ein, in dem die Ergebnisse gespeichert werden (z. B.`s3://my-bucket/query-results/`), oder wählen Sie **Amazon S3 durchsuchen**, um zu navigieren und einen vorhandenen Amazon S3 S3-Standort auszuwählen. 1. (Optional) Um Ergebnisse mit einem vom Kunden verwalteten AWS KMS Schlüssel zu verschlüsseln, geben Sie den ARN des AWS KMS Schlüssels in das Feld **KMS-Schlüssel-ARN** ein. Der Schlüssel muss sich in derselben AWS Region wie der Amazon S3-Ziel-Bucket befinden. Wenn Sie keinen AWS KMS Schlüssel angeben, gelten die Standard-Verschlüsselungseinstellungen des Buckets. 1. Wählen Sie im Abschnitt **IAM-Rolle für die Veröffentlichung von Abfrageergebnissen in Amazon S3** die Option **Neue Rolle mit Standardberechtigungen automatisch erstellen** aus, um die erforderlichen Berechtigungen automatisch einzurichten, oder wählen Sie **Bestehende Rolle verwenden**, um eine bestehende IAM-Rolle mit den erforderlichen Richtlinien auszuwählen. Die IAM-Rolle für die Zielzustellung erfordert die folgenden Berechtigungen: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::my-bucket/prefix/*", "Condition": { "StringEquals": { "aws:ResourceAccount": "111122223333" } } } ] } ``` ## Ergebnisse an einen Amazon S3 S3-Bucket in einem anderen Konto senden Sie können geplante Abfrageergebnisse an einen Amazon S3 S3-Bucket in einem anderen AWS Konto senden. Wenn Sie einen kontoübergreifenden Bucket verwenden, müssen Sie den Amazon S3 S3-URI und die Konto-ID des Kontos angeben, das den Bucket besitzt. **So konfigurieren Sie ein kontoübergreifendes Amazon S3 S3-Ziel (Konsole)** 1. Wählen Sie im Abschnitt **Abfrageergebnisse an S3 senden** für **S3-Bucket** die Option **Anderes Konto** aus und geben Sie die Konto-ID des Kontos, das den Bucket besitzt, als Eingabe ein. 1. Geben Sie für **Amazon S3 S3-URI** die vollständige Amazon S3 S3-URI des Ziel-Buckets und das Präfix im anderen Konto ein (z. B.`s3://cross-account-bucket/query-results/`). 1. (Optional) Um Ergebnisse mit einem vom Kunden verwalteten AWS KMS Schlüssel zu verschlüsseln, geben Sie den ARN des AWS KMS Schlüssels in das Feld **KMS-Schlüssel-ARN** ein. Der Schlüssel muss sich in derselben AWS Region wie der Amazon S3-Ziel-Bucket befinden. 1. Wählen Sie im Abschnitt **IAM-Rolle für die Veröffentlichung von Abfrageergebnissen in Amazon S3** die Option **Neue Rolle mit Standardberechtigungen automatisch erstellen** aus, um die erforderlichen Berechtigungen automatisch einzurichten, oder wählen Sie **Bestehende Rolle verwenden**, um eine bestehende IAM-Rolle mit den erforderlichen Richtlinien auszuwählen. Für die kontoübergreifende Lieferung sind Genehmigungen auf beiden Seiten erforderlich. Die IAM-Rolle für die Zielzustellung im Quellkonto erfordert die folgenden Berechtigungen: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::cross-account-bucket/prefix/*", "Condition": { "StringEquals": { "aws:ResourceAccount": "123456789012" } } } ] } ``` Die Amazon S3 S3-Bucket-Richtlinie im Zielkonto muss der IAM-Rollenberechtigung des Quellkontos die Berechtigung zum Schreiben von Objekten gewähren: ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowScheduledQueryRolePutObject", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/my-s3-delivery-role" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::cross-account-bucket/prefix/*" } ] } ``` ## Verschlüsseln von Ergebnissen mit einem vom Kunden verwalteten Schlüssel AWS KMS Sie können optional einen vom Kunden verwalteten AWS KMS Schlüssel angeben, um Abfrageergebnisse zu verschlüsseln, die mit SSE-KMS an Amazon S3 übermittelt werden. Der AWS KMS Schlüssel kann sich in demselben Konto wie die geplante Abfrage oder in einem anderen Konto befinden. Wenn Sie einen AWS KMS Schlüssel angeben, verwendet die geplante Abfrage diesen Schlüssel, um Ergebnisse über SSE-KMS zu verschlüsseln. Wenn Sie keinen AWS KMS Schlüssel angeben, gelten die Standardverschlüsselungseinstellungen des Buckets. Wenn der Bucket mit der standardmäßigen SSE-KMS-Verschlüsselung unter Verwendung eines vom Kunden verwalteten Schlüssels konfiguriert ist, muss die IAM-Rolle für die Zielzustellung dennoch über `kms:GenerateDataKey` Berechtigungen für diesen Schlüssel verfügen. Für die IAM-Rolle für die Zielzustellung ist eine `kms:GenerateDataKey` Genehmigung für den Schlüssel erforderlich. AWS KMS Das folgende Beispiel zeigt die erforderlichen Berechtigungen für ein Amazon S3 S3-Ziel mit einem vom Kunden verwalteten AWS KMS Schlüssel: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::my-bucket/prefix/*", "Condition": { "StringEquals": { "aws:ResourceAccount": "111122223333" } } }, { "Effect": "Allow", "Action": "kms:GenerateDataKey", "Resource": "arn:aws:kms:us-east-1:111122223333:key/key-id", "Condition": { "StringEquals": { "kms:ViaService": "s3.us-east-1.amazonaws.com" }, "StringLike": { "kms:EncryptionContext:aws:s3:arn": "arn:aws:s3:::my-bucket*" } } } ] } ``` Wenn sich der AWS KMS Schlüssel in einem anderen Konto als der IAM-Rolle für die Zielzustellung befindet, muss die AWS KMS Schlüsselrichtlinie im Konto, das den Schlüssel besitzt, der Rolle explizit Zugriff gewähren: ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowScheduledQueryRoleToEncrypt", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/my-s3-delivery-role" }, "Action": "kms:GenerateDataKey", "Resource": "*", "Condition": { "StringEquals": { "kms:ViaService": "s3.us-east-1.amazonaws.com" }, "StringLike": { "kms:EncryptionContext:aws:s3:arn": "arn:aws:s3:::my-bucket*" } } } ] } ``` **Anmerkung** Wenn sich der AWS KMS Schlüssel und die IAM-Rolle für die Zielzustellung in demselben Konto befinden, reicht die IAM-Identitätsrichtlinie allein aus, wenn die AWS KMS Schlüsselrichtlinie die Standardanweisung „IAM-Richtlinien aktivieren“ enthält. Eine ausdrückliche Erteilung der AWS KMS Schlüsselrichtlinie ist nur erforderlich, wenn die Schlüsselrichtlinie nicht an IAM delegiert wird. Die IAM-Rolle für die Veröffentlichung von Abfrageergebnissen in Amazon S3 muss getrennt von der IAM-Rolle für die geplante Abfrageausführung konfiguriert werden. Diese Trennung ermöglicht eine differenzierte Zugriffskontrolle, bei der die Ausführungsrolle Abfragen ausführen kann, während die Amazon S3 S3-Rolle speziell die Ergebnislieferung übernimmt. Beide Rollen müssen eine Vertrauensrichtlinie enthalten, die es dem CloudWatch Logs-Service (`logs.amazonaws.com`) ermöglicht, die Rolle zu übernehmen. # Problembehandlung bei geplanten Abfragen Verwenden Sie diese Themen zur Problembehandlung, um häufig auftretende Probleme mit geplanten Abfragen zu lösen. ## Die Ausführung der Abfrage schlägt aufgrund von Berechtigungsfehlern fehl Beheben Sie Berechtigungsfehler, die verhindern, dass geplante Abfragen ausgeführt oder Ergebnisse an Ziele übermittelt werden. Berechtigungsfehler treten auf, wenn der Ausführungsrolle die erforderlichen Berechtigungen zum Lesen aus Protokollgruppen oder zum Schreiben in Zielressourcen fehlen. **Um Berechtigungsfehler zu beheben** 1. Stellen Sie sicher, dass die Ausführungsrolle über die `logs:DescribeLogGroups` Berechtigungen `logs:StartQuery``logs:GetQueryResults`, und für die Zielprotokollgruppen verfügt. 1. Stellen Sie sicher, dass die Ausführungsrolle über Schreibberechtigungen für die Zielressourcen (z. B. `s3:PutObject` für S3-Buckets) verfügt. 1. Vergewissern Sie sich, dass die Vertrauensrichtlinie CloudWatch Logs erlaubt, die Ausführungsrolle zu übernehmen. Die Rolle sollte dem Prinzipal (`logs.amazonaws.com`) des Protokolldienstes in ihrer Vertrauensrichtlinie vertrauen. Zu den häufigsten Ursachen gehören fehlende IAM-Berechtigungen, falsche Ressourcen ARNs in der Richtlinie oder Probleme mit der Konfiguration der Vertrauensrichtlinie. Um Berechtigungsfehler zu vermeiden, sollten Sie bei der Erstellung von Ausführungsrollen und Testberechtigungen das Prinzip der geringsten Rechte verwenden, bevor Sie geplante Abfragen in der Produktion bereitstellen. ## Zeitlimit für Abfragen überschritten Beheben Sie Timeoutfehler, die auftreten, wenn geplante Abfragen das maximale Ausführungszeitlimit überschreiten. Abfrage-Timeouts treten auf, wenn die Abfrage mehr als 60 Minuten benötigt, um den angegebenen Datenbereich zu verarbeiten, was häufig auf große Datenmengen oder eine komplexe Abfragelogik zurückzuführen ist. **Um Timeout-Fehler zu beheben** 1. Reduzieren Sie den Zeitbereich, indem Sie den Startzeitversatz verringern, um weniger Daten pro Ausführung zu verarbeiten. 1. Optimieren Sie die Abfrage, indem Sie zu Beginn der Abfrage Filter hinzufügen, um die Menge der verarbeiteten Daten zu reduzieren. Verwenden Sie Filterindizes, um die Größe des Datenscans zu reduzieren. 1. Erwägen Sie, komplexe Abfragen in einfachere, zielgerichtetere Abfragen aufzuteilen. Zu den häufigsten Ursachen gehören die Abfrage großer Zeitbereiche, die Verarbeitung von Protokollgruppen mit hohem Volumen oder die Verwendung komplexer Aggregationen ohne angemessene Filterung. Um Zeitüberschreitungen zu vermeiden, testen Sie Abfragen manuell in CloudWatch Logs Insights mit Ihrem erwarteten Datenvolumen und optimieren Sie die Leistung vor der Planung. ## Die Zielverarbeitung schlägt fehl Beheben Sie Fehler, die auftreten, wenn geplante Abfrageergebnisse nicht an die konfigurierten Ziele übermittelt werden können. Fehler bei der Zielverarbeitung treten auf, wenn auf den Amazon S3 S3-Ziel-Bucket oder EventBridge Event-Bus nicht zugegriffen werden kann oder der Zielbus falsch konfiguriert ist. **Um Fehler zu beheben, bei denen Abfrageergebnisse nicht im Ziel veröffentlicht werden** 1. Stellen Sie sicher, dass der angegebene Amazon S3 S3-Bucket existiert und darauf zugegriffen werden kann. 1. Überprüfen Sie, ob die Zielkonfiguration korrekt ist URIs. 1. Stellen Sie sicher, dass die Ausführungsrolle über die erforderlichen Berechtigungen verfügt, um in das Ziel zu schreiben. Zu den häufigsten Ursachen gehören gelöschte oder umbenannte Zielressourcen, falsche Ziele URIs oder Probleme mit der Netzwerkkonnektivität. Überprüfen Sie die Zielkonfigurationen regelmäßig und überwachen Sie die Verfügbarkeit der Zielressourcen, um Zielausfälle zu vermeiden. ## Ungültige Abfragefehler Beheben Sie Syntax- und Logikfehler in geplanten Abfragezeichenfolgen, die eine erfolgreiche Ausführung verhindern. Ungültige Abfragefehler treten auf, wenn die Abfragezeichenfolge Syntaxfehler enthält, auf nicht vorhandene Felder verweist oder Funktionen der Abfragesprache verwendet, die nicht unterstützt werden. **Um ungültige Abfragefehler zu beheben** 1. Testen Sie Ihre Abfrage manuell in CloudWatch Logs Insights, um Syntax und Logik zu überprüfen. 1. Überprüfen Sie, ob alle Protokollfelder, auf die verwiesen wird, in Ihren Zielprotokollgruppen vorhanden sind. 1. Stellen Sie sicher, dass die von Ihnen verwendeten Abfragesprachenfunktionen für geplante Abfragen unterstützt werden. Zu den häufigsten Ursachen gehören Tippfehler in Feldnamen, falsche Abfragesyntax oder die Verwendung von Abfragefunktionen, die in der Umgebung für die geplante Ausführung nicht unterstützt werden. Um ungültige Abfragefehler zu vermeiden, sollten Sie Abfragen vor der Planung immer interaktiv testen und Feldnamen mithilfe von Felderkennungsfunktionen überprüfen. ## Fehler bei der Parallelität von Abfragen Im Folgenden sind einige wichtige Punkte zu beachten, wenn Parallelitätsfehler auftreten, da geplante Abfragen dasselbe Kontingent verwenden wie Cloudwatch Logs Insights-Abfragen. Es wird empfohlen, Ihre Zeitpläne zu verteilen, um zu vermeiden, dass das Parallelitätslimit überschritten wird. + **Kontingent:** Sie können bis zu 100 CloudWatch Logs Insights-Abfragen gleichzeitig pro AWS Konto ausführen. + **Dashboards:** Zu CloudWatch Dashboards hinzugefügte Abfragen werden ebenfalls auf dieses Parallelitätslimit angerechnet, da sie ausgeführt werden, wenn das Dashboard geladen oder aktualisiert wird. + **OpenSearch Service PPL/SQL:** Sie können bis zu 15 PPL- oder SQL-Abfragen gleichzeitig OpenSearch pro Konto ausführen. OpenSearch AWS + **Kontoübergreifende Abfragen:** Das Kontingent für Parallelität gilt sowohl für einzelne als auch für kontenübergreifende Abfragen. Bei Verwendung CloudWatch kontenübergreifender Observability werden Abfragen, die in einem Überwachungskonto für ein verknüpftes Quellkonto initiiert wurden, ebenfalls auf die Parallelitätsgrenze des Überwachungskontos angerechnet. + **Protokollgruppen mit seltenem Zugriff:** Für Protokollgruppen der Klasse der Logs mit seltenem Zugriff ist die maximale Anzahl gleichzeitiger Logs Insights-Abfragen auf fünf begrenzt.