Beispiel 1: Abonnementfilter mit Kinesis Data Streams Beispiel 2: Abonnementfilter mit AWS Lambda Beispiel 3: Abonnementfilter mit Amazon Data Firehose

Abonnementfilter auf Kontoebene

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

Sie können eine Abonnementrichtlinie auf Kontoebene einrichten, die eine Teilmenge der Protokollgruppen im Konto umfasst. Die Kontoabonnementrichtlinie kann mit Kinesis Data Streams, Lambda oder Firehose funktionieren. Protokolle, die über eine Abonnementrichtlinie auf Kontoebene an einen Empfangsdienst gesendet werden, sind Base64-kodiert und im GZIP-Format komprimiert.

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¶.

Beispiele

Beispiel 1: Abonnementfilter mit Kinesis Data Streams
Beispiel 2: Abonnementfilter mit AWS Lambda
Beispiel 3: Abonnementfilter mit Amazon Data Firehose

Beispiel 1: Abonnementfilter mit Kinesis Data Streams

Bevor Sie einen 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 Grenzwerte in der 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 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.
Verwenden Sie den On-Demand-Kapazitätsmodus für Ihren Stream in 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.
Schränken Sie Ihr CloudWatch Logs-Abonnement-Filtermuster so ein, dass es der Kapazität Ihres Streams in 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.

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

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

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


$ C:\>  aws kinesis create-stream —stream-name "TestStream" —shard-count 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 verwenden, um das zu überprüfen. StreamDescription StreamStatusEigentum.


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

Das Folgende ist Ausgabebeispiel:


{
    "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"
                }
            }
        ]
    }
}

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.
```
{
  "Statement": {
    "Effect": "Allow",
    "Principal": { "Service": "logs.amazonaws.com" },
    "Action": "sts:AssumeRole",
    "Condition": { 
        "StringLike": { "aws:SourceArn": "arn:aws:logs:region:123456789012:*" } 
     }
   }
}
```

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"
    }
}

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"
    }
  ]
}
```

Ordnen Sie die Berechtigungsrichtlinie mithilfe des folgenden put-role-policyBefehls der Rolle zu:


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

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 undLogGroupToExclude2.
```
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"
```
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 unterVerhinderung der Rekursion von Protokollen. Derzeit ist NOT IN der einzige unterstützte Operator fürselection-criteria.

Sie können den Fluss der Protokollereignisse überprüfen, indem Sie einen Kinesis Data Streams-Shard-Iterator verwenden und den get-records Befehl Kinesis Data Streams verwenden, um einige 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 Kinesis Data Streams Daten zurückgibt.

Sie sollten davon ausgehen, dass die Antwort in einem Datensatz-Array angezeigt wird. Das Attribut Data in einem Kinesis-Data-Streams-Datensatz ist base64-kodiert und im 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_MESSAGE". Manchmal geben CloudWatch Logs Kinesis Data Streams Streams-Datensätze mit dem Typ „CONTROL_MESSAGE“ 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_LEVEL_POLICY“ ist die Filterrichtlinie policyLevel für Abonnements auf Kontoebene.

Beispiel 2: Abonnementfilter mit AWS Lambda

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.

So erstellen Sie eine Abonnementfilterrichtlinie auf Kontoebene für Lambda

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) im AWS Lambda -Entwicklerhandbuch.

Ö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();
        }
    });
};

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

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

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"

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 unterVerhinderung der Rekursion von Protokollen. Derzeit ist NOT IN der einzige unterstützte Operator fürselection-criteria.
(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.

Wenn Sie die Ausgabe der Lambda-Funktion anzeigen möchten, navigieren Sie zu der Lambda-Funktion. Dort wird die Ausgabe unter /aws/lambda/helloworld angezeigt:
```
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

Die wichtigsten Elemente der Datenstruktur sind die folgenden:

messageType

Datennachrichten verwenden den Typ "DATA_MESSAGE". Manchmal geben CloudWatch Logs Kinesis Data Streams Streams-Datensätze mit dem Typ „CONTROL_MESSAGE“ 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_LEVEL_POLICY“ ist die Filterrichtlinie policyLevel für Abonnements auf Kontoebene.

Beispiel 3: Abonnementfilter mit Amazon Data Firehose

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.

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 Limits.

Um einen Abonnementfilter für Firehose zu erstellen

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 my-bucket --create-bucket-configuration LocationConstraint=region
```
Das Folgende ist Ausgabebeispiel:
```
{
    "Location": "/my-bucket"
}
```
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 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"
    } 
}
```

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"
    }
}

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:::my-bucket", 
          "arn:aws:s3:::my-bucket/*" ]
    }
  ]
}

Ordnen Sie die Berechtigungsrichtlinie mithilfe des folgenden put-role-policy Befehls der Rolle zu:


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

Erstellen Sie wie folgt einen Firehose-Ziel-Lieferstream und ersetzen Sie dabei die Platzhalterwerte für RoleARN und BucketARN durch die Rollen- und Bucket-ARNs, die Sie erstellt haben:
```
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:::my-bucket"}'
                    
```
NFirehose verwendet automatisch ein Präfix im UTC-Zeitformat YYYY/MM/DD/HH 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.

Warten Sie ein paar Minuten, bis der Stream aktiv wird. Sie können den describe-delivery-streamBefehl Firehose verwenden, um das DeliveryStreamDescription zu überprüfen. DeliveryStreamStatusEigentum. 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:::my-bucket",
                    "BufferingHints": {
                        "IntervalInSeconds": 300,
                        "SizeInMBs": 5
                    }
                }
            }
        ]
    }
}

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.
```
{
  "Statement": {
    "Effect": "Allow",
    "Principal": { "Service": "logs.amazonaws.com" },
    "Action": "sts:AssumeRole",
    "Condition": { 
         "StringLike": { 
             "aws:SourceArn": "arn:aws:logs:region:123456789012:*"
         } 
     }
  }
}
```


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"
    }
}

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"]
      }
    ]
}
```

Ordnen Sie die Berechtigungsrichtlinie mit dem put-role-policy folgenden Befehl der Rolle zu:


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

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"

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 unterVerhinderung der Rekursion von Protokollen. Derzeit ist NOT IN der einzige unterstützte Operator fürselection-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 'my-bucket' --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 'my-bucket' --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

Warnung JavaScript ist in Ihrem Browser nicht verfügbar oder deaktiviert.

Zur Nutzung der AWS-Dokumentation muss JavaScript aktiviert sein. Weitere Informationen finden auf den Hilfe-Seiten Ihres Browsers.

Dokumentkonventionen

Abonnementfilter auf Gruppenebene protokollieren

Kontoübergreifende, regionsübergreifende Abonnements