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. # Ereignisse, Protokolle und Prüfpfade Die Überwachung von [DB-Instance-Metriken](db-instance-monitoring.md) [und Betriebssystem-Metriken](os-monitoring.md), die Analyse der Trends und der Vergleich von Metriken mit Basiswerten sowie die Generierung von Warnmeldungen, wenn Werte definierte Schwellenwerte überschreiten, sind alles notwendige und bewährte Methoden, die Ihnen helfen, die Zuverlässigkeit, Verfügbarkeit, Leistung und Sicherheit Ihrer Amazon RDS-DB-Instances zu erreichen und aufrechtzuerhalten. Eine Komplettlösung muss jedoch auch Datenbankereignisse, Protokolldateien und Prüfpfade von MySQL- und MariaDB-Datenbanken überwachen. **Sections** + [Amazon RDS-Ereignisse](rds-events.md) + [Datenbank-Logs](database-logs.md) + [Prüfpfade](audit-trails.md) # Amazon RDS-Ereignisse Ein *Amazon* *RDS-Ereignis* weist auf eine Änderung in der Amazon RDS-Umgebung hin. Wenn sich beispielsweise der Status der DB-Instance von *Starting* auf *Available* ändert, generiert Amazon RDS das Ereignis`RDS-EVENT-0088 The DB instance has been started`. Amazon RDS übermittelt Ereignisse nahezu EventBridge in Echtzeit an Amazon. Sie können über die Amazon RDS-Konsole, den AWS CLI Befehl [describe-events](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/describe-events.html) oder den Amazon RDS-API-Vorgang auf Ereignisse zugreifen. [DescribeEvents](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeEvents.html) Die folgende Bildschirmdarstellung zeigt Ereignisse und Protokolle, die auf der Amazon RDS-Konsole angezeigt werden. ![\[Alarme, Ereignisse und Protokolle, die auf der Amazon RDS-Konsole angezeigt werden\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/amazon-rds-monitoring-alerting/images/alarms-events-logs-rds-console.png) Amazon RDS gibt verschiedene Arten von Ereignissen aus, darunter DB-Instance-Ereignisse, DB-Parametergruppenereignisse, DB-Sicherheitsgruppenereignisse, DB-Snapshot-Ereignisse, RDS-Proxy-Ereignisse und Blau/Grün-Bereitstellungsereignisse. Die Informationen beinhalten: + Quellenname und Quelltyp; zum Beispiel: `"SourceIdentifier": "database-1", "SourceType": "db-instance"` + Datum und Uhrzeit des Ereignisses; zum Beispiel: `"Date": "2022-12-01T09:20:28.595000+00:00"` + Mit dem Ereignis verknüpfte Nachricht, zum Beispiel: `"Message": "Finished updating DB parameter group"` + Kategorie „Ereignis“; zum Beispiel: `"EventCategories": ["configuration change"]` Eine vollständige Referenz finden Sie unter [Amazon RDS-Ereigniskategorien und Ereignismeldungen](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.Messages.html) in der Amazon RDS-Dokumentation. Wir empfehlen Ihnen, Amazon RDS-Ereignisse zu überwachen, da diese Ereignisse auf Statusänderungen bei der Verfügbarkeit von DB-Instances, Konfigurationsänderungen, Änderungen des Read Replica-Status, Sicherungs- und Wiederherstellungsereignisse, Failover-Aktionen, Fehlerereignisse, Änderungen an Sicherheitsgruppen und viele andere Benachrichtigungen hinweisen. Wenn Sie beispielsweise eine Read Replica-DB-Instance eingerichtet haben, um die Leistung und Haltbarkeit Ihrer Datenbank zu verbessern, empfehlen wir Ihnen, Amazon RDS-Ereignisse für die *Read Replica-Ereigniskategorie* zu überwachen, die DB-Instances zugeordnet sind. Dies liegt daran, dass Ereignisse wie z. B. `RDS-EVENT-0057 Replication on the read replica was terminated` darauf hinweisen, dass Ihre Read Replica nicht mehr mit der primären DB-Instance synchronisiert wird. Eine Benachrichtigung an das zuständige Team, dass ein solches Ereignis eingetreten ist, könnte dazu beitragen, das Problem rechtzeitig zu beheben. Amazon EventBridge und weitere AWS-Services Anbieter wie AWS Lambda Amazon Simple Queue Service (Amazon SQS) und Amazon Simple Notification Service (Amazon SNS) können Ihnen helfen, Reaktionen auf Systemereignisse wie Probleme mit der Datenbankverfügbarkeit oder Ressourcenänderungen zu automatisieren. Auf der Amazon RDS-Konsole können Sie Ereignisse der letzten 24 Stunden abrufen. Wenn Sie die AWS CLI oder die Amazon RDS-API verwenden, um Ereignisse anzuzeigen, können Sie Ereignisse der letzten 14 Tage abrufen, indem Sie den Befehl **describe-events** wie folgt verwenden. ``` $ aws rds describe-events --source-identifier database-1 --source-type db-instance { "Events": [ { "SourceIdentifier": "database-1", "SourceType": "db-instance", "Message": "CloudWatch Logs Export enabled for logs [audit, error, general, slowquery]", "EventCategories": [], "Date": "2022-12-01T09:20:28.595000+00:00", "SourceArn": "arn:aws:rds:eu-west-3:111122223333:db:database-1" }, { "SourceIdentifier": "database-1", "SourceType": "db-instance", "Message": "Finished updating DB parameter group", "EventCategories": [ "configuration change" ], "Date": "2022-12-01T09:22:40.413000+00:00", "SourceArn": "arn:aws:rds:eu-west-3:111122223333:db:database-1" } ] } ``` Wenn Sie Ereignisse langfristig speichern möchten, entweder bis zum angegebenen Ablaufzeitraum oder dauerhaft, können Sie [CloudWatch Logs verwenden, um die Informationen über die Ereignisse zu protokollieren](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html), die von Amazon RDS generiert wurden. Um diese Lösung zu implementieren, können Sie ein Amazon SNS SNS-Thema verwenden, um Amazon RDS-Ereignisbenachrichtigungen zu erhalten, und dann eine Lambda-Funktion aufrufen, um das Ereignis in CloudWatch Logs zu protokollieren. 1. Erstellen Sie eine Lambda-Funktion, die bei dem Ereignis aufgerufen wird, und protokollieren Sie die Informationen aus dem Ereignis in CloudWatch Logs. CloudWatch Logs ist in Lambda integriert und bietet eine bequeme Möglichkeit, Ereignisinformationen mithilfe der **Druckfunktion** zu `stdout` protokollieren. 1. Erstellen Sie ein SNS-Thema mit einem Abonnement für eine Lambda-Funktion (setzen Sie **Protocol** auf Lambda) und legen Sie als **Endpoint** den Amazon-Ressourcennamen (ARN) der Lambda-Funktion fest, die Sie im vorherigen Schritt erstellt haben. 1. Konfigurieren Sie Ihr SNS-Thema für den Empfang von Amazon RDS-Ereignisbenachrichtigungen. Eine ausführliche Anleitung finden Sie im [AWS re:POST-Artikel](https://repost.aws/knowledge-center/sns-topics-rds-notifications) darüber, wie Sie Ihr Amazon SNS SNS-Thema dazu bringen können, Amazon RDS-Benachrichtigungen zu erhalten. 1. Erstellen Sie auf der Amazon RDS-Konsole ein neues Event-Abonnement. Stellen Sie **Target** auf den ARN ein und wählen Sie dann das SNS-Thema aus, das Sie zuvor erstellt haben. Stellen Sie den **Quelltyp** und die **Ereigniskategorien so ein,** dass sie Ihren Anforderungen entsprechen. Weitere Informationen finden Sie unter [Abonnieren der Amazon RDS-Ereignisbenachrichtigung](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.Subscribing.html) in der Amazon RDS-Dokumentation. # Datenbankprotokolle MySQL- und MariaDB-Datenbanken generieren Protokolle, auf die Sie zur Prüfung und Fehlerbehebung zugreifen können. Diese Protokolle sind: + [Audit](https://mariadb.com/kb/en/mariadb-audit-plugin-log-format/) — Der Audit-Trail besteht aus einer Reihe von Datensätzen, die die Aktivität des Servers protokollieren. Für jede Clientsitzung wird aufgezeichnet, wer eine Verbindung zum Server hergestellt hat (Benutzername und Host), welche Abfragen ausgeführt wurden, auf welche Tabellen zugegriffen wurde und welche Servervariablen geändert wurden. + [Fehler](https://dev.mysql.com/doc/refman/8.0/en/error-log.html) — Dieses Protokoll enthält die Start- und Shutdown-Zeiten des Servers (`mysqld`) sowie Diagnosemeldungen wie Fehler, Warnungen und Hinweise, die beim Starten und Herunterfahren des Servers sowie während des Serverbetriebs auftreten. + [Allgemein](https://dev.mysql.com/doc/refman/8.0/en/query-log.html) — In diesem Protokoll werden die Aktivitäten von`mysqld`, einschließlich der Verbindungs- und Verbindungsaktivitäten für jeden Client, sowie die von den Clients empfangenen SQL-Abfragen aufgezeichnet. Das allgemeine Abfrageprotokoll kann sehr nützlich sein, wenn Sie einen Fehler vermuten und genau wissen möchten, an was der Client gesendet hat`mysqld`. + [Langsame Abfrage](https://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html) — Dieses Protokoll enthält eine Aufzeichnung von SQL-Abfragen, deren Ausführung lange gedauert hat. Als bewährte Methode sollten Sie [Datenbankprotokolle von Amazon RDS in Amazon CloudWatch Logs veröffentlichen](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.Procedural.UploadtoCloudWatch.html). Mit CloudWatch Logs können Sie eine Echtzeitanalyse der Protokolldaten durchführen, die Daten in einem äußerst langlebigen Speicher speichern und die Daten mit dem CloudWatch Logs-Agenten verwalten. Sie können von der Amazon RDS-Konsole aus auf [Ihre Datenbankprotokolle zugreifen und diese ansehen](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.Procedural.Watching.html). Sie können CloudWatch Logs Insights auch verwenden, um Ihre Protokolldaten in CloudWatch Logs interaktiv zu suchen und zu analysieren. Das folgende Beispiel zeigt eine Abfrage im Auditprotokoll, mit der überprüft wird, wie oft `CONNECT` Ereignisse im Protokoll vorkommen, wer eine Verbindung hergestellt hat und von welchem Client (IP-Adresse) aus die Verbindung hergestellt wurde. Der Auszug aus dem Audit-Protokoll könnte wie folgt aussehen: ``` 20221201 14:07:05,ip-10-22-1-51,rdsadmin,localhost,821,0,CONNECT,,,0,SOCKET 20221201 14:07:05,ip-10-22-1-51,rdsadmin,localhost,821,0,DISCONNECT,,,0,SOCKET 20221201 14:12:20,ip-10-22-1-51,rdsadmin,localhost,822,0,CONNECT,,,0,SOCKET 20221201 14:12:20,ip-10-22-1-51,rdsadmin,localhost,822,0,DISCONNECT,,,0,SOCKET 20221201 14:17:35,ip-10-22-1-51,rdsadmin,localhost,823,0,CONNECT,,,0,SOCKET 20221201 14:17:35,ip-10-22-1-51,rdsadmin,localhost,823,0,DISCONNECT,,,0,SOCKET 20221201 14:22:50,ip-10-22-1-51,rdsadmin,localhost,824,0,CONNECT,,,0,SOCKET 20221201 14:22:50,ip-10-22-1-51,rdsadmin,localhost,824,0,DISCONNECT,,,0,SOCKET ``` Die Log Insights-Beispielabfrage zeigt, dass `localhost` alle 5 Minuten eine `rdsadmin` Verbindung zur Datenbank hergestellt wurde, also insgesamt 22 Mal, wie in der folgenden Abbildung dargestellt. Diese Ergebnisse deuten darauf hin, dass die Aktivität auf interne Amazon RDS-Prozesse wie das Überwachungssystem selbst zurückzuführen ist. ![\[Bericht Log Insights\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/amazon-rds-monitoring-alerting/images/log-insights.png) Protokollereignisse enthalten häufig wichtige Meldungen, die Sie zählen möchten, z. B. Warnungen oder Fehler zu Vorgängen im Zusammenhang mit MySQL- und MariaDB-DB-Instances. Wenn beispielsweise ein Vorgang fehlschlägt, kann ein Fehler auftreten, der wie folgt in der Fehlerprotokolldatei aufgezeichnet wird:. `ERROR 1114 (HY000): The table zip_codes is full` Möglicherweise möchten Sie diese Einträge überwachen, um den Trend Ihrer Fehler zu verstehen. Sie können [benutzerdefinierte CloudWatch Metriken aus Amazon RDS-Protokollen erstellen, indem Sie Filter verwenden](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html), um die automatische Überwachung von Amazon RDS-Datenbankprotokollen zu aktivieren, um ein bestimmtes Protokoll auf bestimmte Muster zu überwachen und bei Verstößen gegen das erwartete Verhalten einen Alarm auszulösen. Erstellen Sie [beispielsweise](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CountOccurrencesExample.html) einen Metrikfilter für die Protokollgruppe`/aws/rds/instance/database-1/error`, der das Fehlerprotokoll überwacht und nach [einem bestimmten Muster](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html) sucht, z. `ERROR` B. Stellen Sie das **Filtermuster** auf `ERROR` und den **Metrikwert** auf`1`. Der Filter erkennt jeden Protokolldatensatz, der das Schlüsselwort enthält`ERROR`, und erhöht die Anzahl für jedes Protokollereignis, das den Wert „FEHLER“ enthält, um 1. Nachdem Sie den Filter erstellt haben, können Sie einen Alarm einrichten, der Sie benachrichtigt, falls Fehler im MySQL- oder MariaDB-Fehlerprotokoll entdeckt werden. Weitere Informationen zur Überwachung des Logs für langsame Abfragen und des Fehlerprotokolls durch die Erstellung eines CloudWatch Dashboards und die Verwendung von CloudWatch Logs Insights finden Sie im Blogbeitrag [Erstellen eines CloudWatch Amazon-Dashboards zur Überwachung von Amazon RDS und Amazon Aurora MySQL.](https://aws.amazon.com/blogs/database/creating-an-amazon-cloudwatch-dashboard-to-monitor-amazon-rds-and-amazon-aurora-mysql/) # Audit-Trails Der Audit-Trail (oder Audit-Log) bietet eine sicherheitsrelevante, chronologische Aufzeichnung der Ereignisse in Ihrem. AWS-Konto Es umfasst Ereignisse für Amazon RDS, die dokumentarische Nachweise über die Abfolge der Aktivitäten liefern, die sich auf Ihre Datenbank oder Ihre Cloud-Umgebung ausgewirkt haben. In Amazon RDS for MySQL oder MariaDB beinhaltet die Verwendung des Audit-Trails: + Überwachen des Audit-Logs der DB-Instance + Überwachung von Amazon RDS-API-Aufrufen AWS CloudTrail Für eine Amazon RDS-DB-Instance umfassen die Prüfungsziele in der Regel: + Aktivierung der Rechenschaftspflicht für Folgendes: + Änderungen, die am Parameter oder an der Sicherheitskonfiguration vorgenommen wurden + Aktionen, die in einem Datenbankschema, einer Tabelle oder Zeile ausgeführt werden, oder Aktionen, die sich auf bestimmte Inhalte auswirken + Erkennung und Untersuchung von Eindringversuchen + Erkennung und Untersuchung verdächtiger Aktivitäten + Erkennung von Autorisierungsproblemen, z. B. um Verstöße gegen Zugriffsrechte durch reguläre oder privilegierte Benutzer zu identifizieren Der Datenbank-Audit-Trail versucht, die folgenden typischen Fragen zu beantworten: *Wer hat sensible Daten in Ihrer Datenbank eingesehen oder geändert? Wann ist das passiert? Von wo aus hat ein bestimmter Benutzer auf die Daten zugegriffen? Haben privilegierte Benutzer ihre uneingeschränkten Zugriffsrechte missbraucht?* Sowohl MySQL als auch MariaDB implementieren die Audit-Trail-Funktion der DB-Instance mithilfe des MariaDB-Audit-Plugins. Dieses Plugin zeichnet Datenbankaktivitäten auf, z. B. Benutzer, die sich an der Datenbank anmelden, und Abfragen, die in der Datenbank ausgeführt werden. Der Datensatz der Datenbankaktivität wird in einer Protokolldatei gespeichert. Für den Zugriff auf das Audit-Protokoll muss die DB-Instance eine benutzerdefinierte Optionsgruppe mit der Option `MARIADB_AUDIT_PLUGIN` verwenden. Weitere Informationen finden Sie unter [MariaDB Audit Plugin-Unterstützung für MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.Options.AuditPlugin.html) in der Amazon RDS-Dokumentation. Die Datensätze im Audit-Log werden in einem bestimmten Format gespeichert, das vom Plugin definiert wird. Weitere Informationen zum Audit-Log-Format finden Sie in der [MariaDB Server-Dokumentation](https://mariadb.com/kb/en/mariadb-audit-plugin-log-format/). Der AWS Cloud Prüfpfad für Ihr AWS Konto wird vom Dienst bereitgestellt. [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) CloudTrail erfasst API-Aufrufe für Amazon RDS als Ereignisse. Alle Amazon RDS-Aktionen werden protokolliert. CloudTrail bietet eine Aufzeichnung der Aktionen in Amazon RDS, die von einem Benutzer, einer Rolle oder einem anderen AWS Service ausgeführt wurden. Zu den Ereignissen gehören Aktionen, die in der AWS Management Console AWS CLI, und AWS SDKs und ausgeführt wurden APIs. ## Beispiel In einem typischen Audit-Szenario müssen Sie möglicherweise AWS CloudTrail Trails mit dem Datenbank-Audit-Log und der Amazon RDS-Ereignisüberwachung kombinieren. Möglicherweise haben Sie ein Szenario, in dem die Datenbankparameter Ihrer Amazon RDS-DB-Instance (z. B.`database-1`) geändert wurden und Ihre Aufgabe darin besteht, herauszufinden, wer die Änderung vorgenommen hat, was geändert wurde und wann die Änderung vorgenommen wurde. Gehen Sie wie folgt vor, um die Aufgabe zu erledigen: 1. Führen Sie die Amazon RDS-Ereignisse auf, die mit der Datenbank-Instance passiert sind, `database-1` und ermitteln Sie, ob es in der Kategorie`configuration change`, die die Meldung enthält, ein Ereignis gibt`Finished updating DB parameter group`. ``` $ aws rds describe-events --source-identifier database-1 --source-type db-instance { "Events": [ { "SourceIdentifier": "database-1", "SourceType": "db-instance", "Message": "Finished updating DB parameter group", "EventCategories": [ "configuration change" ], "Date": "2022-12-01T09:22:40.413000+00:00", "SourceArn": "arn:aws:rds:eu-west-3:111122223333:db:database-1" } ] } ``` 1. Identifizieren Sie, welche DB-Parametergruppe die DB-Instance verwendet: ``` $ aws rds describe-db-instances --db-instance-identifier database-1 --query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups]' [ [ "database-1", "mariadb", [ { "DBParameterGroupName": "mariadb10-6-test", "ParameterApplyStatus": "pending-reboot" } ] ] ] ``` 1. [Verwenden Sie den AWS CLI , um nach CloudTrail Ereignissen in der Region zu suchen](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events-cli.html), in der `database-1` es bereitgestellt wird, in dem Zeitraum rund um das in Schritt 1 entdeckte Amazon RDS-Ereignis und wo`EventName=ModifyDBParameterGroup`. ``` $ aws cloudtrail --region eu-west-3 lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=ModifyDBParameterGroup --start-time "2022-12-01, 09:00 AM" --end-time "2022-12-01, 09:30 AM" { "eventVersion": "1.08", "userIdentity": { "accountId": "111122223333", "accessKeyId": "AKIAIOSFODNN7EXAMPLE", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AIDACKCEVSQ6C2EXAMPLE", "arn": "arn:aws:iam::111122223333:role/Role1", "accountId": "111122223333", "userName": "User1" } } }, "eventTime": "2022-12-01T09:18:19Z", "eventSource": "rds.amazonaws.com", "eventName": "ModifyDBParameterGroup", "awsRegion": "eu-west-3", "sourceIPAddress": "AWS Internal", "userAgent": "AWS Internal", "requestParameters": { "parameters": [ { "isModifiable": false, "applyMethod": "pending-reboot", "parameterName": "innodb_log_buffer_size", "parameterValue": "8388612" }, { "isModifiable": false, "applyMethod": "pending-reboot", "parameterName": "innodb_write_io_threads", "parameterValue": "8" } ], "dBParameterGroupName": "mariadb10-6-test" }, "responseElements": { "dBParameterGroupName": "mariadb10-6-test" }, "requestID": "fdf19353-de72-4d3d-bf29-751f375b6378", "eventID": "0bba7484-0e46-4e71-93a8-bd01ca8386fe", "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "111122223333", "eventCategory": "Management", "sessionCredentialFromConsole": "true" } ``` Das CloudTrail Ereignis zeigt, dass `User1` mit der Rolle `Role1` aus dem AWS Konto 111122223333 die DB-Parametergruppe geändert wurde`mariadb10-6-test`, die von der DB-Instance am verwendet wurde. `database-1` `2022-12-01 at 09:18:19 h` Zwei Parameter wurden geändert und auf die folgenden Werte gesetzt: + `innodb_log_buffer_size = 8388612` + `innodb_write_io_threads = 8` ## Zusätzliche Funktionen CloudTrail und Funktionen für CloudWatch Protokolle Sie können Betriebs- und Sicherheitsvorfälle der letzten 90 Tage beheben, indem Sie den **Ereignisverlauf** auf der CloudTrail Konsole aufrufen. Um den Aufbewahrungszeitraum zu verlängern und zusätzliche Abfragefunktionen zu nutzen, können Sie [AWS CloudTrail Lake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html) verwenden. Mit AWS CloudTrail Lake können Sie Ereignisdaten bis zu sieben Jahre lang in einem Ereignisdatenspeicher speichern. **Darüber hinaus unterstützt der Service komplexe SQL-Abfragen, die eine umfassendere und besser anpassbare Ansicht von Ereignissen bieten als die Ansichten, die durch einfache Schlüsselwert-Suchen im Ereignisverlauf bereitgestellt werden.** Um Ihre Prüfpfade zu überwachen, Alarme einzustellen und Benachrichtigungen zu erhalten, wenn bestimmte Aktivitäten auftreten, müssen Sie die [Konfiguration so konfigurieren, dass die Protokollaufzeichnungen CloudTrail an Logs gesendet werden](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/monitor-cloudtrail-log-files-with-cloudwatch-logs.html). CloudWatch Nachdem die Protokolldatensätze als CloudWatch Protokolle gespeichert wurden, können Sie Metrikfilter definieren, um Protokollereignisse anhand von Begriffen, Ausdrücken oder Werten auszuwerten und Metrikfiltern Metrikfiltern Metriken zuzuweisen. Darüber hinaus können Sie CloudWatch Alarme erstellen, die gemäß den von Ihnen angegebenen Schwellenwerten und Zeiträumen generiert werden. Sie können beispielsweise Alarme konfigurieren, die Benachrichtigungen an die verantwortlichen Teams senden, damit diese die entsprechenden Maßnahmen ergreifen können. Sie können auch so konfigurieren CloudWatch , dass als Reaktion auf einen Alarm automatisch eine Aktion ausgeführt wird.