

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.

# Abonnementfilter auf Kontoebene
<a name="SubscriptionFilters-AccountLevel"></a>

**Wichtig**  
Es besteht die Gefahr, dass bei Abonnementfiltern eine endlose rekursive Schleife entsteht, die zu einem starken Anstieg der Datenerfassung führen kann, wenn sie nicht behoben wird. Um dieses Risiko zu minimieren, empfehlen wir Ihnen, in Ihren Abonnementfiltern auf Kontoebene Auswahlkriterien zu verwenden, um Protokollgruppen auszuschließen, die Protokolldaten aus Ressourcen aufnehmen, die Teil des Workflows für die Abonnementzustellung sind. Weitere Informationen zu diesem Problem und zur Bestimmung der auszuschließenden Protokollgruppen finden Sie unter. [Verhinderung der Rekursion von Protokollen](Subscriptions-recursion-prevention.md)

 Sie können eine Abonnementrichtlinie auf Kontoebene einrichten, die eine Teilmenge der Protokollgruppen im Konto umfasst. Die Kontoabonnementrichtlinie kann mit Amazon Kinesis Data Streams oder Amazon Data Firehose funktionieren. AWS Lambda Protokolle, die über eine Abonnementrichtlinie auf Kontoebene an einen Service gesendet werden, sind Base64-kodiert und im GZIP-Format komprimiert. Dieser Abschnitt enthält Beispiele, denen Sie folgen können, um ein Abonnement auf Kontoebene für Amazon Kinesis Data Streams, Lambda und Firehose zu erstellen. 

**Anmerkung**  
Um eine Liste aller Abonnementfilterrichtlinien in Ihrem Konto anzuzeigen, verwenden Sie den `describe-account-policies` Befehl mit dem Wert von für den Parameter. `SUBSCRIPTION_FILTER_POLICY` `--policy-type` Weitere Informationen finden Sie unter [ describe-account-policies¶](https://docs.aws.amazon.com/cli/latest/reference/logs/describe-account-policies.html).

**Topics**
+ [Beispiel 1: Abonnementfilter mit Amazon Kinesis Data Streams](#DestinationKinesisExample-AccountLevel)
+ [Beispiel 2: Abonnementfilter mit AWS Lambda](#LambdaFunctionExample-AccountLevel)
+ [Beispiel 3: Abonnementfilter mit Amazon Data Firehose](#FirehoseExample-AccountLevel)

## Beispiel 1: Abonnementfilter mit Amazon Kinesis Data Streams
<a name="DestinationKinesisExample-AccountLevel"></a>

Bevor Sie einen Amazon Kinesis Data Streams Streams-Datenstream erstellen, der mit einer Abonnementrichtlinie auf Kontoebene verwendet werden soll, berechnen Sie das Volumen der Protokolldaten, die generiert werden. Vergewissern Sie sich, dass Sie einen -Stream mit einer ausreichenden Anzahl von Shards zur Bearbeitung dieses Volumens erstellen. Wenn ein Stream nicht über genügend Shards verfügt, wird er gedrosselt. Weitere Informationen zu Volumenbeschränkungen für Streams finden Sie unter [Kontingente und Limits](https://docs.aws.amazon.com/streams/latest/dev/service-sizes-and-limits.html) in der Amazon Kinesis Data Streams Streams-Dokumentation.

**Warnung**  
Da die Protokollereignisse mehrerer Protokollgruppen an das Ziel weitergeleitet werden, besteht die Gefahr einer Drosselung. Gedrosselte Zustellungen werden bis zu 24 Stunden lang neu versucht. Nach 24 Stunden werden die fehlgeschlagenen Zustellungen verworfen.   
Um das Risiko der Drosselung zu verringern, können Sie die folgenden Schritte unternehmen:  
Überwachen Sie Ihren Amazon Kinesis Data Streams Streams-Stream mit CloudWatch Metriken. Auf diese Weise können Sie Drosselungen erkennen und Ihre Konfiguration entsprechend anpassen. Die `DeliveryThrottling` Metrik verfolgt beispielsweise die Anzahl der Protokollereignisse, für die CloudWatch Logs bei der Weiterleitung von Daten an das Abonnementziel gedrosselt wurde. Weitere Informationen finden Sie unter [Überwachung mit CloudWatch Metriken](CloudWatch-Logs-Monitoring-CloudWatch-Metrics.md).
Verwenden Sie den On-Demand-Kapazitätsmodus für Ihren Stream in Amazon Kinesis Data Streams. Der On-Demand-Modus passt sich Ihren Workloads sofort an, wenn sie steigen oder sinken. Weitere Informationen finden Sie unter [On-Demand-Modus](https://docs.aws.amazon.com/streams/latest/dev/how-do-i-size-a-stream.html#ondemandmode).
Schränken Sie Ihr CloudWatch Logs-Abonnement-Filtermuster so ein, dass es der Kapazität Ihres Streams in Amazon Kinesis Data Streams entspricht. Wenn Sie zu viele Daten an den Stream senden, müssen Sie möglicherweise die Filtergröße reduzieren oder die Filterkriterien anpassen.

Das folgende Beispiel verwendet eine Abonnementrichtlinie auf Kontoebene, um alle Protokollereignisse an einen Stream in Amazon Kinesis Data Streams weiterzuleiten. Das Filtermuster ordnet alle Protokollereignisse dem Text zu `Test` und leitet sie an den Stream in Amazon Kinesis Data Streams weiter.

**So erstellen Sie eine Abonnementrichtlinie auf Kontoebene für Amazon Kinesis Data Streams**

1. Erstellen Sie einen Ziel--Stream mit dem folgenden Befehl: 

   ```
   $ C:\>  aws kinesis create-stream —stream-name "TestStream" —shard-count 1
   ```

1. Warten Sie einige Minuten, bis der Stream aktiv wird. **Sie können überprüfen, ob der Stream aktiv ist, indem Sie den Befehl [describe-stream](https://docs.aws.amazon.com/cli/latest/reference/kinesis/describe-stream.html) verwenden, um das zu überprüfen. StreamDescription StreamStatus**Eigentum. 

   ```
   aws kinesis describe-stream --stream-name "TestStream"
   ```

   Das Folgende ist eine Beispielausgabe:

   ```
   {
       "StreamDescription": {
           "StreamStatus": "ACTIVE",
           "StreamName": "TestStream",
           "StreamARN": "arn:aws:kinesis:region:123456789012:stream/TestStream",
           "Shards": [
               {
                   "ShardId": "shardId-000000000000",
                   "HashKeyRange": {
                       "EndingHashKey": "EXAMPLE8463463374607431768211455",
                       "StartingHashKey": "0"
                   },
                   "SequenceNumberRange": {
                       "StartingSequenceNumber":
                       "EXAMPLE688818456679503831981458784591352702181572610"
                   }
               }
           ]
       }
   }
   ```

1. Erstellen Sie die IAM-Rolle, die CloudWatch Logs die Erlaubnis erteilt, Daten in Ihren Stream einzufügen. Zunächst müssen Sie eine Vertrauensrichtlinie in einer Datei erstellen (z. B. `~/TrustPolicyForCWL-Kinesis.json`). Verwenden Sie einen Text-Editor, um diese Richtlinie zu erstellen.

   Diese Richtlinie enthält einen globalen Bedingungskontextschlüssel `aws:SourceArn`, um das Confused-Deputy-Problem zu vermeiden. Weitere Informationen finden Sie unter [Confused-Deputy-Prävention](Subscriptions-confused-deputy.md).

   ```
   {
     "Statement": {
       "Effect": "Allow",
       "Principal": { "Service": "logs.amazonaws.com" },
       "Action": "sts:AssumeRole",
       "Condition": { 
           "StringLike": { "aws:SourceArn": "arn:aws:logs:region:123456789012:*" } 
        }
      }
   }
   ```

1. Verwenden Sie den Befehl **create-role**, um die IAM-Rolle zu erstellen und die Datei mit der Vertrauensrichtlinie anzugeben. Notieren Sie den zurückgegebenen Wert **Role.Arn**, da Sie ihn in einem späteren Schritt benötigen:

   ```
   aws iam create-role --role-name CWLtoKinesisRole --assume-role-policy-document file://~/TrustPolicyForCWL-Kinesis.json
   ```

   Es folgt ein Beispiel für die Ausgabe.

   ```
   {
       "Role": {
           "AssumeRolePolicyDocument": {
               "Statement": {
                   "Action": "sts:AssumeRole",
                   "Effect": "Allow",
                   "Principal": {
                       "Service": "logs.amazonaws.com"
                   },
                   "Condition": { 
                       "StringLike": { 
                           "aws:SourceArn": { "arn:aws:logs:region:123456789012:*" }
                       } 
                   }
               }
           },
           "RoleId": "EXAMPLE450GAB4HC5F431",
           "CreateDate": "2023-05-29T13:46:29.431Z",
           "RoleName": "CWLtoKinesisRole",
           "Path": "/",
           "Arn": "arn:aws:iam::123456789012:role/CWLtoKinesisRole"
       }
   }
   ```

1. Erstellen Sie eine Berechtigungsrichtlinie, um zu definieren, welche Aktionen CloudWatch Logs auf Ihrem Konto ausführen kann. Erstellen Sie zunächst eine Berechtigungsrichtlinie in einer Datei (z. B. `~/PermissionsForCWL-Kinesis.json`). Verwenden Sie einen Text-Editor, um diese Richtlinie zu erstellen. Verwenden Sie nicht die IAM-Konsole, um es zu erstellen.

   ```
   {
     "Statement": [
       {
         "Effect": "Allow",
         "Action": "kinesis:PutRecord",
         "Resource": "arn:aws:kinesis:region:123456789012:stream/TestStream"
       }
     ]
   }
   ```

1. Verknüpfen Sie die Berechtigungsrichtlinie mit dem folgenden Befehl [put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html) mit der Rolle:

   ```
   aws iam put-role-policy  --role-name CWLtoKinesisRole  --policy-name Permissions-Policy-For-CWL  --policy-document file://~/PermissionsForCWL-Kinesis.json
   ```

1. Nachdem sich der Stream im Status **Aktiv** befindet und Sie die IAM-Rolle erstellt haben, können Sie die Abonnementfilterrichtlinie für CloudWatch Logs erstellen. Die Richtlinie startet sofort den Fluss von Protokolldaten in Echtzeit zu Ihrem Stream. In diesem Beispiel `ERROR` werden alle Protokollereignisse, die die Zeichenfolge enthalten, gestreamt, mit Ausnahme der Ereignisse in den Protokollgruppen mit dem Namen `LogGroupToExclude1` und`LogGroupToExclude2`.

   ```
   aws logs put-account-policy \
       --policy-name "ExamplePolicy" \
       --policy-type "SUBSCRIPTION_FILTER_POLICY" \
       --policy-document '{"RoleArn":"arn:aws:iam::123456789012:role/CWLtoKinesisRole", "DestinationArn":"arn:aws:kinesis:region:123456789012:stream/TestStream", "FilterPattern": "Test", "Distribution": "Random"}' \
       --selection-criteria 'LogGroupName NOT IN ["LogGroupToExclude1", "LogGroupToExclude2"]' \
       --scope "ALL"
   ```

1. Nachdem Sie den Abonnementfilter eingerichtet haben, leitet CloudWatch Logs alle eingehenden Protokollereignisse, die dem Filtermuster und den Auswahlkriterien entsprechen, an Ihren Stream weiter. 

   Das `selection-criteria` Feld ist optional, aber wichtig, um Protokollgruppen, die zu einer unendlichen Protokollrekursion führen können, aus einem Abonnementfilter auszuschließen. Weitere Informationen zu diesem Problem und zur Bestimmung, welche Protokollgruppen ausgeschlossen werden sollen, finden Sie unter[Verhinderung der Rekursion von Protokollen](Subscriptions-recursion-prevention.md). Derzeit ist NOT IN der einzige unterstützte Operator für`selection-criteria`.

   Sie können den Fluss der Protokollereignisse überprüfen, indem Sie einen Amazon Kinesis Data Streams Streams-Shard-Iterator verwenden und den Amazon Kinesis Data Streams `get-records` Streams-Befehl verwenden, um einige Amazon Kinesis Data Streams Streams-Datensätze abzurufen:

   ```
   aws kinesis get-shard-iterator --stream-name TestStream --shard-id shardId-000000000000 --shard-iterator-type TRIM_HORIZON
   ```

   ```
   {
       "ShardIterator":
       "AAAAAAAAAAFGU/kLvNggvndHq2UIFOw5PZc6F01s3e3afsSscRM70JSbjIefg2ub07nk1y6CDxYR1UoGHJNP4m4NFUetzfL+wev+e2P4djJg4L9wmXKvQYoE+rMUiFq+p4Cn3IgvqOb5dRA0yybNdRcdzvnC35KQANoHzzahKdRGb9v4scv+3vaq+f+OIK8zM5My8ID+g6rMo7UKWeI4+IWiK2OSh0uP"
   }
   ```

   ```
   aws kinesis get-records --limit 10 --shard-iterator "AAAAAAAAAAFGU/kLvNggvndHq2UIFOw5PZc6F01s3e3afsSscRM70JSbjIefg2ub07nk1y6CDxYR1UoGHJNP4m4NFUetzfL+wev+e2P4djJg4L9wmXKvQYoE+rMUiFq+p4Cn3IgvqOb5dRA0yybNdRcdzvnC35KQANoHzzahKdRGb9v4scv+3vaq+f+OIK8zM5My8ID+g6rMo7UKWeI4+IWiK2OSh0uP"
   ```

   Möglicherweise müssen Sie diesen Befehl einige Male verwenden, bevor Amazon Kinesis Data Streams Daten zurückgibt.

   Sie sollten davon ausgehen, dass die Antwort in einem Datensatz-Array angezeigt wird. Das **Datenattribut** in einem Amazon Kinesis Data Streams Streams-Datensatz ist base64-codiert und mit dem GZIP-Format komprimiert. Sie können die Rohdaten über die Befehlszeile mit den folgenden Unix-Befehlen überprüfen:

   ```
   echo -n "<Content of Data>" | base64 -d | zcat
   ```

   Die dekodierten und dekomprimierten base64-Daten sind als JSON mit folgender Struktur formatiert:

   ```
   { 
       "messageType": "DATA_MESSAGE",
       "owner": "123456789012",
       "logGroup": "Example1",
       "logStream": "logStream1",
       "subscriptionFilters": [ 
           "ExamplePolicy" 
       ],
       "logEvents": [ 
           { 
               "id": "31953106606966983378809025079804211143289615424298221568",
               "timestamp": 1432826855000,
               "message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
           },
           { 
               "id": "31953106606966983378809025079804211143289615424298221569",
               "timestamp": 1432826855000,
               "message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}" 
           }, 
           { 
               "id": "31953106606966983378809025079804211143289615424298221570",
               "timestamp": 1432826855000,
               "message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}" 
           } 
       ],
       "policyLevel": "ACCOUNT_LEVEL_POLICY"
   }
   ```

   Die wichtigsten Elemente der Datenstruktur sind die folgenden:  
**messageType**  
Datennachrichten verwenden den Typ "DATA\$1MESSAGE". Manchmal geben CloudWatch Logs Amazon Kinesis Data Streams Streams-Datensätze mit dem Typ „CONTROL\$1MESSAGE“ aus, hauptsächlich um zu überprüfen, ob das Ziel erreichbar ist.  
**owner**  
Die AWS Konto-ID der ursprünglichen Protokolldaten.  
**logGroup**  
Der Name der Protokollgruppe der ursprünglichen Protokolldaten.  
**logStream**  
Der Name des Protokoll-Stream der ursprünglichen Protokolldaten.  
**subscriptionFilters**  
Die Namenliste der Abonnementfilter, die mit den ursprünglichen Protokolldaten übereingestimmt haben.  
**logEvents**  
Die tatsächlichen Protokolldaten, die als Array von Protokollereignis-Datensätzen dargestellt werden. Die "id"-Eigenschaft ist eine eindeutige Kennung für jedes Protokollereignis.  
**Richtlinienebene**  
Die Ebene, auf der die Richtlinie durchgesetzt wurde. „ACCOUNT\$1LEVEL\$1POLICY“ ist die Filterrichtlinie `policyLevel` für Abonnements auf Kontoebene.

## Beispiel 2: Abonnementfilter mit AWS Lambda
<a name="LambdaFunctionExample-AccountLevel"></a>

In diesem Beispiel erstellen Sie eine Abonnementfilterrichtlinie für CloudWatch Logs auf Kontoebene, die Protokolldaten an Ihre AWS Lambda Funktion sendet.

**Warnung**  
Berechnen Sie das Volume der generierten Protokolldaten, bevor Sie die Lambda-Funktion erstellen. Vergewissern Sie sich, dass Sie eine Funktion erstellen, die dieses Volumen bearbeiten kann. Wenn die Funktion das Volumen nicht verarbeiten kann, wird der Log-Stream gedrosselt. Da die Protokollereignisse aller Protokollgruppen oder einer Teilmenge der Protokollgruppen des Kontos an das Ziel weitergeleitet werden, besteht die Gefahr einer Drosselung. Weitere Informationen über Lambda-Limits finden Sie unter [AWS Lambda -Limits](https://docs.aws.amazon.com/lambda/latest/dg/limits.html). 

**So erstellen Sie eine Abonnementfilterrichtlinie auf Kontoebene für Lambda**

1. Erstellen Sie die Funktion. AWS Lambda 

   Stellen Sie sicher, dass Sie die Lambda-Ausführungsrolle eingerichtet haben. Weitere Informationen finden Sie unter [Schritt 2.2: Erstellen einer IAM-Rolle (Ausführungsrolle)](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) im *AWS Lambda -Entwicklerhandbuch*.

1. Öffnen Sie einen Text-Editor, und erstellen Sie eine Datei mit dem Namen `helloWorld.js` mit folgendem Inhalt:

   ```
   var zlib = require('zlib');
   exports.handler = function(input, context) {
       var payload = Buffer.from(input.awslogs.data, 'base64');
       zlib.gunzip(payload, function(e, result) {
           if (e) { 
               context.fail(e);
           } else {
               result = JSON.parse(result.toString());
               console.log("Event Data:", JSON.stringify(result, null, 2));
               context.succeed();
           }
       });
   };
   ```

1. Komprimieren Sie die Datei "helloWorld.js", und speichern Sie sie unter dem Namen `helloWorld.zip`.

1. Verwenden Sie den folgenden Befehl, wobei die Rolle die Lambda-Ausführungsrolle ist, die Sie im ersten Schritt eingerichtet haben:

   ```
   aws lambda create-function \
       --function-name helloworld \
       --zip-file fileb://file-path/helloWorld.zip \
       --role lambda-execution-role-arn \
       --handler helloWorld.handler \
       --runtime nodejs18.x
   ```

1. Erteilen Sie CloudWatch Logs die Erlaubnis, Ihre Funktion auszuführen. Verwenden Sie den folgenden Befehl und ersetzen Sie das Platzhalterkonto durch Ihr eigenes Konto.

   ```
   aws lambda add-permission \
       --function-name "helloworld" \
       --statement-id "helloworld" \
       --principal "logs.amazonaws.com" \
       --action "lambda:InvokeFunction" \
       --source-arn "arn:aws:logs:region:123456789012:log-group:*" \
       --source-account "123456789012"
   ```

1. Erstellen Sie mit dem folgenden Befehl eine Abonnementfilterrichtlinie auf Kontoebene und ersetzen Sie dabei das Platzhalterkonto durch Ihr eigenes Konto. In diesem Beispiel `ERROR` werden alle Protokollereignisse, die die Zeichenfolge enthalten, gestreamt, mit Ausnahme der Ereignisse in den Protokollgruppen mit dem Namen und. `LogGroupToExclude1` `LogGroupToExclude2`

   ```
   aws logs put-account-policy \
       --policy-name "ExamplePolicyLambda" \
       --policy-type "SUBSCRIPTION_FILTER_POLICY" \
       --policy-document '{"DestinationArn":"arn:aws:lambda:region:123456789012:function:helloWorld", "FilterPattern": "Test", "Distribution": "Random"}' \
       --selection-criteria 'LogGroupName NOT IN ["LogGroupToExclude1", "LogGroupToExclude2"]' \
       --scope "ALL"
   ```

   Nachdem Sie den Abonnementfilter eingerichtet haben, leitet CloudWatch Logs alle eingehenden Protokollereignisse, die dem Filtermuster und den Auswahlkriterien entsprechen, an Ihren Stream weiter. 

   Das `selection-criteria` Feld ist optional, aber wichtig, um Protokollgruppen, die zu einer unendlichen Protokollrekursion führen können, aus einem Abonnementfilter auszuschließen. Weitere Informationen zu diesem Problem und zur Bestimmung, welche Protokollgruppen ausgeschlossen werden sollen, finden Sie unter[Verhinderung der Rekursion von Protokollen](Subscriptions-recursion-prevention.md). Derzeit ist NOT IN der einzige unterstützte Operator für`selection-criteria`.

1. (Optional) Führen Sie einen Test mit einem Beispiel-Protokollereignis durch. Geben Sie an der Eingabeaufforderung den folgenden Befehl ein. Damit wird eine einfache Protokollnachricht in den registrierten Stream gestellt.

   Um die Ausgabe Ihrer Lambda-Funktion zu sehen, navigieren Sie zur Lambda-Funktion, wo Sie die Ausgabe in/sehen werden: aws/lambda/helloworld

   ```
   aws logs put-log-events --log-group-name Example1 --log-stream-name logStream1 --log-events "[{\"timestamp\":CURRENT TIMESTAMP MILLIS , \"message\": \"Simple Lambda Test\"}]"
   ```

   Sie sollten davon ausgehen, dass die Antwort mit einem Lambda-Array angezeigt wird. Das Attribut **Data** im Lambda-Datensatz ist base64-kodiert und im GZIP-Format komprimiert. Die tatsächliche Nutzlast, die Lambda erhält, hat folgendes Format: `{ "awslogs": {"data": "BASE64ENCODED_GZIP_COMPRESSED_DATA"} }`. Sie können die Rohdaten über die Befehlszeile mit den folgenden Unix-Befehlen überprüfen:

   ```
   echo -n "<BASE64ENCODED_GZIP_COMPRESSED_DATA>" | base64 -d | zcat
   ```

   Die dekodierten und dekomprimierten base64-Daten sind als JSON mit folgender Struktur formatiert:

   ```
   { 
       "messageType": "DATA_MESSAGE",
       "owner": "123456789012",
       "logGroup": "Example1",
       "logStream": "logStream1",
       "subscriptionFilters": [ 
           "ExamplePolicyLambda" 
       ],
       "logEvents": [ 
           { 
               "id": "31953106606966983378809025079804211143289615424298221568",
               "timestamp": 1432826855000,
               "message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
           },
           { 
               "id": "31953106606966983378809025079804211143289615424298221569",
               "timestamp": 1432826855000,
               "message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}" 
           }, 
           { 
               "id": "31953106606966983378809025079804211143289615424298221570",
               "timestamp": 1432826855000,
               "message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}" 
           } 
       ],
       "policyLevel": "ACCOUNT_LEVEL_POLICY"
   }
   ```
**Anmerkung**  
Der Abonnementfilter auf Kontoebene wird nicht auf die Protokollgruppe der Ziel-Lambda-Funktion angewendet. Dadurch soll eine unendliche Protokollrekursion verhindert werden, die zu einer Erhöhung der Abrechnung der Datenerfassung führen kann. Weitere Informationen zu diesem Problem finden Sie unter. [Verhinderung der Rekursion von Protokollen](Subscriptions-recursion-prevention.md)

   Die wichtigsten Elemente der Datenstruktur sind die folgenden:  
**messageType**  
Datennachrichten verwenden den Typ "DATA\$1MESSAGE". Manchmal geben CloudWatch Logs Amazon Kinesis Data Streams Streams-Datensätze mit dem Typ „CONTROL\$1MESSAGE“ aus, hauptsächlich um zu überprüfen, ob das Ziel erreichbar ist.  
**owner**  
Die AWS Konto-ID der ursprünglichen Protokolldaten.  
**logGroup**  
Der Name der Protokollgruppe der ursprünglichen Protokolldaten.  
**logStream**  
Der Name des Protokoll-Stream der ursprünglichen Protokolldaten.  
**subscriptionFilters**  
Die Namenliste der Abonnementfilter, die mit den ursprünglichen Protokolldaten übereingestimmt haben.  
**logEvents**  
Die tatsächlichen Protokolldaten, die als Array von Protokollereignis-Datensätzen dargestellt werden. Die "id"-Eigenschaft ist eine eindeutige Kennung für jedes Protokollereignis.  
**Richtlinienebene**  
Die Ebene, auf der die Richtlinie durchgesetzt wurde. „ACCOUNT\$1LEVEL\$1POLICY“ ist die Filterrichtlinie `policyLevel` für Abonnements auf Kontoebene.

## Beispiel 3: Abonnementfilter mit Amazon Data Firehose
<a name="FirehoseExample-AccountLevel"></a>

In diesem Beispiel erstellen Sie eine CloudWatch Logs-Abonnementfilterrichtlinie auf Kontoebene, die eingehende Protokollereignisse, die Ihren definierten Filtern entsprechen, an Ihren Amazon Data Firehose-Lieferstream sendet. Daten, die von CloudWatch Logs an Amazon Data Firehose gesendet werden, sind bereits mit GZIP-Komprimierung der Stufe 6 komprimiert, sodass Sie in Ihrem Firehose-Lieferstream keine Komprimierung verwenden müssen. Anschließend können Sie die Dekomprimierungsfunktion in Firehose verwenden, um die Protokolle automatisch zu dekomprimieren. Weitere Informationen finden Sie unter [Mithilfe CloudWatch von Protokollen in Kinesis Data Firehose schreiben](https://docs.aws.amazon.com/firehose/latest/dev/writing-with-cloudwatch-logs.html).

**Warnung**  
Bevor Sie den Firehose erstellen, berechnen Sie das Volumen der Protokolldaten, die generiert werden. Stellen Sie sicher, dass Sie einen Firehose-Stream erstellen, der dieses Volume verarbeiten kann. Wenn der Stream das Volumen nicht bearbeiten kann, wird die Protokoll-Stream gedrosselt. Weitere Informationen zu den Volumenbeschränkungen für Firehose-Streams finden Sie unter [Amazon Data Firehose Data](https://docs.aws.amazon.com/firehose/latest/dev/limits.html) Limits. 

**Um einen Abonnementfilter für Firehose zu erstellen**

1. Erstellen Sie einen Amazon-Simple-Storage-Service-(Amazon S3)-Bucket. Wir empfehlen Ihnen, einen Bucket zu verwenden, der speziell für CloudWatch Logs erstellt wurde. Wenn Sie jedoch einen vorhandenen Bucket verwenden möchten, gehen Sie direkt zu Schritt 2.

   Führen Sie den folgenden Befehl aus, und ersetzen Sie die Platzhalter-Region mit der Region, die Sie verwenden möchten:

   ```
   aws s3api create-bucket --bucket amzn-s3-demo-bucket2 --create-bucket-configuration LocationConstraint=region
   ```

   Das Folgende ist eine Beispielausgabe:

   ```
   {
       "Location": "/amzn-s3-demo-bucket2"
   }
   ```

1. Erstellen Sie die IAM-Rolle, die Amazon Data Firehose die Erlaubnis erteilt, Daten in Ihren Amazon S3 S3-Bucket zu legen.

   Weitere Informationen finden Sie unter [Zugriffskontrolle mit Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html) im *Amazon Data Firehose Developer Guide*.

   Verwenden Sie zunächst einen Text-Editor zum Erstellen einer Vertrauensrichtlinie in einer Datei `~/TrustPolicyForFirehose.json` wie folgt:

   ```
   {
     "Statement": {
       "Effect": "Allow",
       "Principal": { "Service": "firehose.amazonaws.com" },
       "Action": "sts:AssumeRole"
       } 
   }
   ```

1. Verwenden Sie den Befehl **create-role**, um die IAM-Rolle zu erstellen und die Datei mit der Vertrauensrichtlinie anzugeben. Notieren Sie sich den zurückgegebenen **Role.Arn-Wert**, da Sie ihn in einem späteren Schritt benötigen werden:

   ```
   aws iam create-role \
    --role-name FirehosetoS3Role \
    --assume-role-policy-document file://~/TrustPolicyForFirehose.json
   
   {
       "Role": {
           "AssumeRolePolicyDocument": {
               "Statement": {
                   "Action": "sts:AssumeRole",
                   "Effect": "Allow",
                   "Principal": {
                       "Service": "firehose.amazonaws.com"
                   }
               }
           },
           "RoleId": "EXAMPLE50GAB4HC5F431",
           "CreateDate": "2023-05-29T13:46:29.431Z",
           "RoleName": "FirehosetoS3Role",
           "Path": "/",
           "Arn": "arn:aws:iam::123456789012:role/FirehosetoS3Role"
       }
   }
   ```

1. Erstellen Sie eine Berechtigungsrichtlinie, um zu definieren, welche Aktionen Firehose auf Ihrem Konto ausführen kann. Verwenden Sie zunächst einen Text-Editor zum Erstellen einer Berechtigungsrichtlinie in einer Datei `~/PermissionsForFirehose.json`:

   ```
   {
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [ 
             "s3:AbortMultipartUpload", 
             "s3:GetBucketLocation", 
             "s3:GetObject", 
             "s3:ListBucket", 
             "s3:ListBucketMultipartUploads", 
             "s3:PutObject" ],
         "Resource": [ 
             "arn:aws:s3:::amzn-s3-demo-bucket2", 
             "arn:aws:s3:::amzn-s3-demo-bucket2/*" ]
       }
     ]
   }
   ```

1. Verknüpfen Sie die Berechtigungsrichtlinie mit dem folgenden Befehl put-role-policy mit der Rolle:

   ```
   aws iam put-role-policy --role-name FirehosetoS3Role --policy-name Permissions-Policy-For-Firehose --policy-document file://~/PermissionsForFirehose.json
   ```

1. Erstellen Sie wie folgt einen Firehose-Ziel-Lieferstream und ersetzen **Sie dabei die Platzhalterwerte für RoleARN** und **BucketARN** durch die Rolle und den Bucket, die Sie erstellt haben: ARNs 

   ```
   aws firehose create-delivery-stream \
      --delivery-stream-name 'my-delivery-stream' \
      --s3-destination-configuration \
     '{"RoleARN": "arn:aws:iam::123456789012:role/FirehosetoS3Role", "BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket2"}'
   ```

   NFirehose verwendet automatisch ein Präfix im YYYY/MM/DD/HH UTC-Zeitformat für gelieferte Amazon S3 S3-Objekte. Sie können ein zusätzliches Präfix vor dem Zeitformat-Präfix hinzufügen. Wenn das Präfix mit einem Schrägstrich (/) endet, wird es als Ordner im Amazon-S3-Bucket angezeigt.

1. Warten Sie ein paar Minuten, bis der Stream aktiv wird. **Sie können den **describe-delivery-stream**Befehl Firehose verwenden, um das DeliveryStreamDescription zu überprüfen. DeliveryStreamStatus**Eigentum. Beachten Sie außerdem die **DeliveryStreamDescription. DeliveryStreamARN-Wert**, wie Sie ihn in einem späteren Schritt benötigen werden:

   ```
   aws firehose describe-delivery-stream --delivery-stream-name "my-delivery-stream"
   {
       "DeliveryStreamDescription": {
           "HasMoreDestinations": false,
           "VersionId": "1",
           "CreateTimestamp": 1446075815.822,
           "DeliveryStreamARN": "arn:aws:firehose:us-east-1:123456789012:deliverystream/my-delivery-stream",
           "DeliveryStreamStatus": "ACTIVE",
           "DeliveryStreamName": "my-delivery-stream",
           "Destinations": [
               {
                   "DestinationId": "destinationId-000000000001",
                   "S3DestinationDescription": {
                       "CompressionFormat": "UNCOMPRESSED",
                       "EncryptionConfiguration": {
                           "NoEncryptionConfig": "NoEncryption"
                       },
                       "RoleARN": "delivery-stream-role",
                       "BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket2",
                       "BufferingHints": {
                           "IntervalInSeconds": 300,
                           "SizeInMBs": 5
                       }
                   }
               }
           ]
       }
   }
   ```

1. Erstellen Sie die IAM-Rolle, die CloudWatch Logs die Berechtigung erteilt, Daten in Ihren Firehose-Lieferstream aufzunehmen. Verwenden Sie zunächst einen Text-Editor zum Erstellen einer Vertrauensrichtlinie in einer Datei `~/TrustPolicyForCWL.json`:

   Diese Richtlinie enthält einen globalen Bedingungskontextschlüssel `aws:SourceArn`, um das Confused-Deputy-Problem zu vermeiden. Weitere Informationen finden Sie unter [Confused-Deputy-Prävention](Subscriptions-confused-deputy.md).

   ```
   {
     "Statement": {
       "Effect": "Allow",
       "Principal": { "Service": "logs.amazonaws.com" },
       "Action": "sts:AssumeRole",
       "Condition": { 
            "StringLike": { 
                "aws:SourceArn": "arn:aws:logs:region:123456789012:*"
            } 
        }
     }
   }
   ```

1. Verwenden Sie den Befehl **create-role**, um die IAM-Rolle zu erstellen und die Datei mit der Vertrauensrichtlinie anzugeben. Notieren Sie sich den zurückgegebenen **Role.Arn-Wert**, da Sie ihn in einem späteren Schritt benötigen werden:

   ```
   aws iam create-role \
   --role-name CWLtoKinesisFirehoseRole \
   --assume-role-policy-document file://~/TrustPolicyForCWL.json
   
   {
       "Role": {
           "AssumeRolePolicyDocument": {
               "Statement": {
                   "Action": "sts:AssumeRole",
                   "Effect": "Allow",
                   "Principal": {
                       "Service": "logs.amazonaws.com"
                   },
                   "Condition": { 
                        "StringLike": { 
                            "aws:SourceArn": "arn:aws:logs:region:123456789012:*"
                        } 
                    }
               }
           },
           "RoleId": "AAOIIAH450GAB4HC5F431",
           "CreateDate": "2015-05-29T13:46:29.431Z",
           "RoleName": "CWLtoKinesisFirehoseRole",
           "Path": "/",
           "Arn": "arn:aws:iam::123456789012:role/CWLtoKinesisFirehoseRole"
       }
   }
   ```

1. Erstellen Sie eine Berechtigungsrichtlinie, um zu definieren, welche Aktionen CloudWatch Logs auf Ihrem Konto ausführen können. Verwenden Sie zunächst einen Text-Editor zum Erstellen einer Berechtigungsrichtliniendatei (beispielsweise `~/PermissionsForCWL.json`):

   ```
   {
       "Statement":[
         {
           "Effect":"Allow",
           "Action":["firehose:PutRecord"],
           "Resource":[
               "arn:aws:firehose:region:account-id:deliverystream/delivery-stream-name"]
         }
       ]
   }
   ```

1. Verknüpfen Sie die Berechtigungsrichtlinie mit dem Befehl put-role-policy mit der Rolle:

   ```
   aws iam put-role-policy --role-name CWLtoKinesisFirehoseRole --policy-name Permissions-Policy-For-CWL --policy-document file://~/PermissionsForCWL.json
   ```

1. Nachdem sich der Amazon Data Firehose-Lieferstream im aktiven Status befindet und Sie die IAM-Rolle erstellt haben, können Sie die Abonnementfilterrichtlinie CloudWatch Logs auf Kontoebene erstellen. Die Richtlinie startet sofort den Fluss von Protokolldaten in Echtzeit von der ausgewählten Protokollgruppe zu Ihrem Amazon Data Firehose-Lieferstream:

   ```
   aws logs put-account-policy \
       --policy-name "ExamplePolicyFirehose" \
       --policy-type "SUBSCRIPTION_FILTER_POLICY" \
       --policy-document '{"RoleArn":"arn:aws:iam::123456789012:role/CWLtoKinesisFirehoseRole", "DestinationArn":"arn:aws:firehose:us-east-1:123456789012:deliverystream/delivery-stream-name", "FilterPattern": "Test", "Distribution": "Random"}' \
       --selection-criteria 'LogGroupName NOT IN ["LogGroupToExclude1", "LogGroupToExclude2"]' \
       --scope "ALL"
   ```

1. Nachdem Sie den Abonnementfilter eingerichtet haben, leitet CloudWatch Logs die eingehenden Protokollereignisse, die dem Filtermuster entsprechen, an Ihren Amazon Data Firehose-Lieferstream weiter.

   Das `selection-criteria` Feld ist optional, aber wichtig, um Protokollgruppen, die zu einer unendlichen Protokollrekursion führen können, aus einem Abonnementfilter auszuschließen. Weitere Informationen zu diesem Problem und zur Bestimmung, welche Protokollgruppen ausgeschlossen werden sollen, finden Sie unter[Verhinderung der Rekursion von Protokollen](Subscriptions-recursion-prevention.md). Derzeit ist NOT IN der einzige unterstützte Operator für`selection-criteria`.

   Ihre Daten werden in Ihrem Amazon S3 basierend auf dem Zeitpufferintervall angezeigt, das in Ihrem Amazon Data Firehose-Lieferstream festgelegt wurde. Sobald genügend Zeit abgelaufen ist, können Sie die Daten im Amazon-S3-Bucket überprüfen.

   ```
   aws s3api list-objects --bucket 'amzn-s3-demo-bucket2' --prefix 'firehose/'
   {
       "Contents": [
           {
               "LastModified": "2023-10-29T00:01:25.000Z",
               "ETag": "\"a14589f8897f4089d3264d9e2d1f1610\"",
               "StorageClass": "STANDARD",
               "Key": "firehose/2015/10/29/00/my-delivery-stream-2015-10-29-00-01-21-a188030a-62d2-49e6-b7c2-b11f1a7ba250",
               "Owner": {
                   "DisplayName": "cloudwatch-logs",
                   "ID": "1ec9cf700ef6be062b19584e0b7d84ecc19237f87b5"
               },
               "Size": 593
           },
           {
               "LastModified": "2015-10-29T00:35:41.000Z",
               "ETag": "\"a7035b65872bb2161388ffb63dd1aec5\"",
               "StorageClass": "STANDARD",
               "Key": "firehose/2023/10/29/00/my-delivery-stream-2023-10-29-00-35-40-EXAMPLE-7e66-49bc-9fd4-fc9819cc8ed3",
               "Owner": {
                   "DisplayName": "cloudwatch-logs",
                   "ID": "EXAMPLE6be062b19584e0b7d84ecc19237f87b6"
               },
               "Size": 5752
           }
       ]
   }
   ```

   ```
   aws s3api get-object --bucket 'amzn-s3-demo-bucket2' --key 'firehose/2023/10/29/00/my-delivery-stream-2023-10-29-00-01-21-a188030a-62d2-49e6-b7c2-b11f1a7ba250' testfile.gz
   
   {
       "AcceptRanges": "bytes",
       "ContentType": "application/octet-stream",
       "LastModified": "Thu, 29 Oct 2023 00:07:06 GMT",
       "ContentLength": 593,
       "Metadata": {}
   }
   ```

   Die Daten im Amazon-S3-Objekt sind im GZIP-Format komprimiert. Sie können die Rohdaten über die Befehlszeile mit dem folgenden Unix-Befehl überprüfen:

   ```
   zcat testfile.gz
   ```