Abonnementfilter auf Gruppenebene protokollieren - CloudWatch Amazon-Protokolle

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 AWS Lambda, Amazon Data Firehose oder Amazon OpenSearch Service verwenden. 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.

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
  1. Erstellen Sie einen Ziel--Stream mit dem folgenden Befehl:

    $ C:\> aws kinesis create-stream --stream-name "RootAccess" --shard-count 1
  2. 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 Wert StreamDescription.streamArn, 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" } } ] } }
  3. Erstellen Sie die IAM-Rolle, die CloudWatch Logs die Berechtigung 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 zum Erstellen nicht die IAM-Konsole.

    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:*" } } } }
  4. 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": "AAOIIAH450GAB4HC5F431", "CreateDate": "2015-05-29T13:46:29.431Z", "RoleName": "CWLtoKinesisRole", "Path": "/", "Arn": "arn:aws:iam::123456789012:role/CWLtoKinesisRole" } }
  5. 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 zum Erstellen nicht die IAM-Konsole.

    { "Statement": [ { "Effect": "Allow", "Action": "kinesis:PutRecord", "Resource": "arn:aws:kinesis:region:123456789012:stream/RootAccess" } ] }
  6. 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
  7. Nachdem sich der Stream im Status Aktiv befindet und Sie die IAM-Rolle erstellt haben, können Sie den CloudWatch Protokoll-Abonnementfilter 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"
  8. 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 dekodierten und dekomprimierten base64-Daten sind als JSON mit folgender Struktur 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 "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.

    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
  1. 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: Erstellen einer IAM-Rolle (Ausführungsrolle) im AWS Lambda -Entwicklerhandbuch.

  2. Ö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(); } }); };
  3. Komprimieren Sie die Datei "helloWorld.js", und speichern Sie sie unter dem Namen helloWorld.zip.

  4. 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 nodejs12.x
  5. 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"
  6. 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
  7. (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-name stream1 --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:

    { "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 "DATA_MESSAGE". Manchmal können CloudWatch Logs Lambda-Datensätze mit dem Typ „CONTROL_MESSAGE“ 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 CloudWatch Protokolle an Firehose senden.

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
  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 Ausgabebeispiel:

    { "Location": "/amzn-s3-demo-bucket2" }
  2. 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" } }
  3. 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 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" } }
  4. 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/*" ] } ] }
  5. 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
  6. 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"}'

    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.

  7. 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. 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 } } } ] } }
  8. 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:*" } } } }
  9. 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 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" } }
  10. Erstellen Sie eine Berechtigungsrichtlinie, um zu definieren, welche Aktionen CloudWatch Logs auf Ihrem Konto ausführen kann. 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"] } ] }
  11. 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
  12. 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:region:123456789012:deliverystream/my-delivery-stream" \ --role-arn "arn:aws:iam::123456789012:role/CWLtoKinesisFirehoseRole"
  13. 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

Beispiel 4: Abonnementfilter mit Amazon OpenSearch Service

In diesem Beispiel erstellen Sie ein CloudWatch Logs-Abonnement, das eingehende Protokollereignisse, die Ihren definierten Filtern entsprechen, an Ihre OpenSearch Service-Domain sendet.

Um einen Abonnementfilter für OpenSearch Service zu erstellen
  1. Erstellen Sie eine OpenSearch Dienstdomäne. Weitere Informationen finden Sie unter OpenSearch Dienstdomänen erstellen

  2. Öffnen Sie die CloudWatch Konsole unter https://console.aws.amazon.com/cloudwatch/.

  3. Wählen Sie im Navigationsbereich Protokollgruppen aus.

  4. Wählen Sie den Namen der Protokollgruppe aus.

  5. Wählen Sie Aktionen, Abonnementfilter, Amazon OpenSearch Service-Abonnementfilter erstellen.

  6. Wählen Sie aus, ob Sie zu einem Cluster in diesem Konto oder einem anderen Konto streamen möchten.

    • Wenn Sie Dieses Konto ausgewählt haben, wählen Sie die Domain aus, die Sie in Schritt 1 erstellt haben.

    • Wenn Sie Anderes Konto ausgewählt haben, geben Sie ARN und Endpunkt dieser Domain ein.

  7. Wenn Sie ein anderes Konto gewählt haben, geben Sie den Domänen-ARN und den Endpunkt an.

  8. Wählen Sie für Lambda IAM Execution Role die IAM-Rolle aus, die Lambda bei der Ausführung von Serviceaufrufen verwenden soll. OpenSearch Die von Ihnen gewählte IAM-Rolle muss die folgenden Anforderungen erfüllen:

    • Es muss lambda.amazonaws.com im Verhältnis stehen.

    • Die Richtlinie muss Folgendes umfassen:

      { "Version": "2012-10-17", "Statement": [{ "Action": [ "es:*" ], "Effect": "Allow", "Resource": "arn:aws:es:region:account-id:domain/target-domain-name/*" }] }
    • Wenn die OpenSearch Zieldienstdomäne VPC-Zugriff verwendet, muss der IAM-Rolle auch die Richtlinie angehängt sein. AWSLambdaVPCAccessExecutionRole Diese von Amazon verwaltete Richtlinie gewährt Lambda Zugriff auf die VPC des Kunden, sodass Lambda auf den Endpunkt in der OpenSearch VPC schreiben kann.

  9. Wählen Sie ein Protokollformat.

  10. Geben Sie unter Filtermuster für Abonnements die Begriffe oder das Muster ein, nach denen Sie in Ihren Protokollereignissen suchen möchten. Dadurch wird sichergestellt, dass Sie nur die Daten, die Sie interessieren, an Ihren OpenSearch Servicecluster senden. Weitere Informationen finden Sie unter Filtermustersyntax für metrische Filter.

  11. (Optional) Wählen Sie unter Select log data to test (Zu testende Protokolldaten auswählen) einen Protokoll-Stream und anschließend Test pattern (Muster testen) aus, um zu überprüfen, ob Ihr Suchfilter die erwarteten Ergebnisse zurückgeben.

  12. Wählen Sie dann Start Streaming (Streamen starten).