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 Gruppenebene protokollieren
Sie können einen Abonnementfilter mit Amazon Kinesis Data Streams oder Amazon Data Firehose verwenden. AWS Lambda Protokolle, die über einen Abonnementfilter an einen Service gesendet werden, sind Base64-codiert und im GZIP-Format komprimiert. Dieser Abschnitt enthält Beispiele, anhand derer Sie einen CloudWatch Logs-Abonnementfilter erstellen können, der Protokolldaten an Firehose, Lambda und Kinesis Data Streams sendet.
Anmerkung
Wenn Sie Ihre Protokolldaten durchsuchen möchten, finden Sie weitere Informationen unter Filter- und Mustersyntax.
Beispiele
Beispiel 1: Abonnementfilter mit Kinesis Data Streams
Im folgenden Beispiel wird ein Abonnementfilter einer Protokollgruppe zugeordnet, die AWS CloudTrail Ereignisse enthält. Der Abonnementfilter überträgt jede protokollierte Aktivität, die mit „Root“ AWS -Anmeldeinformationen ausgeführt wird, an einen Stream in Kinesis Data Streams mit dem Namen "“RootAccess. Weitere Informationen zum Senden von AWS CloudTrail Ereignissen an CloudWatch Logs finden Sie unter Senden von CloudTrail Ereignissen an CloudWatch Logs im AWS CloudTrail Benutzerhandbuch.
Anmerkung
Bevor Sie den -Stream erstellen, berechnen Sie das Volumen der generierten Protokolldaten. Vergewissern Sie sich, dass Sie einen -Stream mit einer ausreichenden Anzahl von Shards zur Bearbeitung dieses Volumens erstellen. Wenn der Stream nicht über genügend Shards verfügt, wird der Protokoll-Stream gedrosselt. Weitere Informationen zu den Volumenlimits bei Streams finden Sie unter Kontingente und Limits.
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:
-
Geben Sie
random
andistribution
, wann Sie den Abonnementfilter mit PutSubscriptionFilteroder erstellen put-subscription-filter. Standardmäßig erfolgt die Verteilung des Streamfilters nach Protokolldatenströmen, was zu einer Drosselung führen kann. -
Überwachen Sie Ihren Stream mithilfe von Metriken CloudWatch . Auf diese Weise können Sie etwaige Drosselungen erkennen und Ihre Konfiguration entsprechend anpassen. Die
DeliveryThrottling
Metrik kann beispielsweise verwendet werden, um die Anzahl der Protokollereignisse nachzuverfolgen, für die CloudWatch Logs bei der Weiterleitung von Daten an das Abonnementziel gedrosselt wurde. Weitere Informationen zur Überwachung 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 zum On-Demand-Kapazitätsmodus finden Sie unter On-Demand-Modus.
-
Schränken Sie Ihr CloudWatch 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.
So erstellen Sie einen Abonnementfilter für Kinesis Data Streams
-
Erstellen Sie einen Ziel--Stream mit dem folgenden Befehl:
$
C:\>
aws kinesis create-stream --stream-name "RootAccess" --shard-count 1 -
Warten Sie, bis der -Stream "Aktiv" wird (dies kann einige Minuten dauern). Sie können den folgenden Kinesis Data Streams Streams-Befehl describe-stream verwenden, um das zu überprüfen. StreamDescription StreamStatusEigenschaft. Notieren Sie sich außerdem den ARN Wert StreamDescription.Stream, da Sie ihn in einem späteren Schritt benötigen werden:
aws kinesis describe-stream --stream-name "RootAccess"
Das Folgende ist Ausgabebeispiel:
{ "StreamDescription": { "StreamStatus": "ACTIVE", "StreamName": "RootAccess", "StreamARN": "arn:aws:kinesis:us-east-1:123456789012:stream/RootAccess", "Shards": [ { "ShardId": "shardId-000000000000", "HashKeyRange": { "EndingHashKey": "340282366920938463463374607431768211455", "StartingHashKey": "0" }, "SequenceNumberRange": { "StartingSequenceNumber": "49551135218688818456679503831981458784591352702181572610" } } ] } }
-
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. Verwenden Sie nicht die IAM Konsole, um ihn 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 Rolle zu erstellen, und geben Sie IAM dabei die Vertrauensrichtliniendatei an. 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": "AAOIIAH450GAB4HC5F431", "CreateDate": "2015-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 können. 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/RootAccess" } ] } -
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 den Abonnementfilter CloudWatch Logs erstellen. Der Abonnementfilter startet sofort den Fluss der Echtzeit-Protokolldaten aus der gewählten Protokollgruppe an den -Stream:
aws logs put-subscription-filter \ --log-group-name "CloudTrail/logs" \ --filter-name "RootAccess" \ --filter-pattern "{$.userIdentity.type = Root}" \ --destination-arn "arn:aws:kinesis:
region
:123456789012:stream/RootAccess" \ --role-arn "arn:aws:iam::123456789012
:role/CWLtoKinesisRole
" -
Nachdem Sie den Abonnementfilter eingerichtet haben, leitet CloudWatch Logs alle eingehenden Protokollereignisse, die dem Filtermuster entsprechen, an Ihren Stream weiter. Sie können überprüfen, ob dies auch geschieht, indem Sie einen Kinesis-Data-Streams-Shard-Iterator aufrufen und mit dem Kinesis-Data-Streams-Befehl „get-records“ einige Kinesis-Data-Streams-Datensätze abrufen:
aws kinesis get-shard-iterator --stream-name RootAccess --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"
Beachten Sie, dass Sie diesen Befehl möglicherweise mehrmals aufrufen müssen, 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 mit Base64 dekodierten und dekomprimierten Daten werden wie JSON folgt formatiert:
{ "owner": "111111111111", "logGroup": "CloudTrail/logs", "logStream": "111111111111_CloudTrail/logs_us-east-1", "subscriptionFilters": [ "Destination" ], "messageType": "DATA_MESSAGE", "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\"}" } ] }
Die Schlüsselelemente in der oben genannten Datenstruktur sind folgende:
- 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.
- messageType
-
Datennachrichten verwenden den Typ MESSAGE "DATA_“. 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.
- 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.
Beispiel 2: Abonnementfilter mit AWS Lambda
In diesem Beispiel erstellen Sie einen CloudWatch Logs-Abonnementfilter, der Protokolldaten an Ihre AWS Lambda Funktion sendet.
Anmerkung
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 nicht über genügend Volumen verfügt, wird der Protokoll-Stream gedrosselt. Weitere Informationen über Lambda-Limits finden Sie unter AWS Lambda -Limits.
So erstellen Sie einen Abonnementfilter für Lambda
-
Erstellen Sie die AWS Lambda Funktion.
Stellen Sie sicher, dass Sie die Lambda-Ausführungsrolle eingerichtet haben. Weitere Informationen finden Sie unter Schritt 2.2: Eine IAM Rolle (Ausführungsrolle) erstellen 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 \ --rolelambda-execution-role-arn
\ --handler helloWorld.handler \ --runtime nodejs12.x -
Erteilen Sie CloudWatch Logs die Erlaubnis, Ihre Funktion auszuführen. Verwenden Sie den folgenden Befehl, und ersetzen Sie den Platzhalter für das Konto mit Ihrem eigenen Konto und den Platzhalter für die Protokollgruppe mit der zu verarbeitenden Protokollgruppe:
aws lambda add-permission \ --function-name "
helloworld
" \ --statement-id "helloworld
" \ --principal "logs.amazonaws.com" \ --action "lambda:InvokeFunction" \ --source-arn "arn:aws:logs:region
:123456789123
:log-group:TestLambda
:*" \ --source-account "123456789012
" -
Erstellen Sie einen Abonnementfilter mit den folgenden Befehl, und ersetzen Sie den Platzhalter für das Konto mit Ihrem eigenen Konto und den Platzhalter für die Protokollgruppe mit der zu verarbeitenden Protokollgruppe:
aws logs put-subscription-filter \ --log-group-name
myLogGroup
\ --filter-name demo \ --filter-pattern "" \ --destination-arn arn:aws:lambda:region
:123456789123
:function:helloworld -
(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 sehen werden: in /aws/lambda/helloworld
aws logs put-log-events --log-group-name
myLogGroup
--log-stream-namestream1
--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 mit Base64 dekodierten und dekomprimierten Daten werden wie folgt formatiert: JSON
{ "owner": "123456789012", "logGroup": "CloudTrail", "logStream": "123456789012_CloudTrail_us-east-1", "subscriptionFilters": [ "Destination" ], "messageType": "DATA_MESSAGE", "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\"}" } ] }
Die Schlüsselelemente in der oben genannten Datenstruktur sind folgende:
- 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.
- messageType
-
Datennachrichten verwenden den Typ MESSAGE "DATA_“. Manchmal können CloudWatch Logs Lambda-Datensätze mit dem Typ MESSAGE "CONTROL_“ ausgeben, hauptsächlich um zu überprüfen, ob das Ziel erreichbar ist.
- 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.
Beispiel 3: Abonnementfilter mit Amazon Data Firehose
In diesem Beispiel erstellen Sie ein CloudWatch Logs-Abonnement, das alle eingehenden 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.
Anmerkung
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
amzn-s3-demo-bucket2
--create-bucket-configuration LocationConstraint=region
Das Folgende ist Ausgabebeispiel:
{ "Location": "/
amzn-s3-demo-bucket2
" } -
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 Rolle zu erstellen, und geben Sie IAM dabei die Vertrauensrichtliniendatei an. Notieren Sie den zurückgegebenen Wert Role.Arn, da Sie ihn in einem späteren Schritt benötigen:
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": "AAOIIAH450GAB4HC5F431", "CreateDate": "2015-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:::
amzn-s3-demo-bucket2
", "arn:aws:s3:::amzn-s3-demo-bucket2
/*" ] } ] } -
Ordnen Sie die Berechtigungsrichtlinie mithilfe des folgenden put-role-policy Befehls der Rolle zu:
aws iam put-role-policy --role-name
FirehosetoS3Role
--policy-namePermissions-Policy-For-Firehose
--policy-documentfile://~/PermissionsForFirehose
.json -
Erstellen Sie wie folgt einen Firehose-Ziel-Lieferstream und ersetzen Sie dabei die Platzhalterwerte für Rolle ARN und Bucket ARN durch die Rolle und den BucketARNs, 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:::amzn-s3-demo-bucket2
"}'Beachten Sie, dass Firehose automatisch ein Präfix im YYYY/MM/DD/HH UTC Zeitformat für gelieferte Amazon S3 S3-Objekte verwendet. 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, bis der Stream aktiv wird (dies kann einige Minuten dauern). Sie können den describe-delivery-streamBefehl Firehose verwenden, um das DeliveryStreamDescription zu überprüfen. DeliveryStreamStatusEigentum. Beachten Sie außerdem die DeliveryStreamDescription. DeliveryStreamARNWert, da 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 } } } ] } } -
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
:*" } } } } -
Verwenden Sie den Befehl create-role, um die Rolle zu erstellen, und geben Sie IAM dabei die Vertrauensrichtliniendatei an. Notieren Sie den zurückgegebenen Wert Role.Arn, da Sie ihn in einem späteren Schritt benötigen:
aws iam create-role \ --role-name
CWLtoKinesisFirehoseRole
\ --assume-role-policy-documentfile://~/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-namePermissions-Policy-For-CWL
--policy-documentfile://~/PermissionsForCWL.json
-
Nachdem sich der Amazon Data Firehose-Lieferstream im aktiven Zustand befindet und Sie die IAM Rolle erstellt haben, können Sie den CloudWatch Logs-Abonnementfilter erstellen. Der Abonnementfilter startet sofort den Fluss von Protokolldaten in Echtzeit von der ausgewählten Protokollgruppe zu Ihrem Amazon Data Firehose-Lieferstream:
aws logs put-subscription-filter \ --log-group-name "CloudTrail" \ --filter-name "Destination" \ --filter-pattern "{$.userIdentity.type = Root}" \ --destination-arn "
arn:aws:firehose:
" \ --role-arn "region
:123456789012
:deliverystream/my-delivery-streamarn:aws:iam::
"123456789012
:role/CWLtoKinesisFirehoseRole -
Nachdem Sie den Abonnementfilter eingerichtet haben, leitet CloudWatch Logs alle eingehenden Protokollereignisse, die dem Filtermuster entsprechen, an Ihren Amazon Data Firehose-Lieferstream weiter. 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": "2015-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/2015/10/29/00/my-delivery-stream-2015-10-29-00-35-40-7cc92023-7e66-49bc-9fd4-fc9819cc8ed3", "Owner": { "DisplayName": "cloudwatch-logs", "ID": "1ec9cf700ef6be062b19584e0b7d84ecc19237f87b6" }, "Size": 5752 } ] }
aws s3api get-object --bucket '
amzn-s3-demo-bucket2
' --key 'firehose/2015/10/29/00/my-delivery-stream-2015-10-29-00-01-21-a188030a-62d2-49e6-b7c2-b11f1a7ba250' testfile.gz{ "AcceptRanges": "bytes", "ContentType": "application/octet-stream", "LastModified": "Thu, 29 Oct 2015 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