Disassociate a log group from a CMK - Amazon CloudWatch Logs

"Action": [

"kms:Encrypt*", "kms:Decrypt*", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:Describe*"

"Resource": "*", "Condition": { "ArnLike": {

"kms:EncryptionContext:aws:logs:arn": "arn:aws:logs:region:account-id:*"

} } } ]

}

Finally, add the updated policy using the following put-key-policy command:

aws kms put-key-policy --key-id key-id --policy-name default --policy file://policy.json

Step 3: Associate a log group with a customer managed key

You can associate a customer managed key with a log group when you create it or after it exists.

To ﬁnd whether a log group already has a customer managed key associated, use the following describe-log-groups command:

aws logs describe-log-groups --log-group-name-prefix "log-group-name-prefix"

If the output includes a kmsKeyId ﬁeld, the log group is associated with the key displayed for the value of that ﬁeld.

To associate the customer managed key with a log group when you create it Use the create-log-group command as follows:

aws logs create-log-group --log-group-name my-log-group --kms-key-id "key-arn"

To associate the customer managed key with an existing log group Use the associate-kms-key command as follows:

aws logs associate-kms-key --log-group-name my-log-group --kms-key-id "key-arn"

Step 4: Disassociate a log group from a CMK

To disassociate the customer managed key associated with a log group, use the following disassociate-kms-key command:

aws logs disassociate-kms-key --log-group-name my-log-group

KMS keys and encryption context

AWS KMS keys and encryption context

To enhance the security of your AWS Key Management Service keys and your encrypted log groups, CloudWatch Logs now puts log group ARNs as part of the encryption context used to encrypt your log data. Encryption context is a set of key-value pairs that are used as additional authenticated data. The encryption context enables you to use IAM policy conditions to limit access to your AWS KMS key by AWS account and log group. For more information, see Encryption context and IAM JSON Policy Elements:

Condition.

We recommend that you use diﬀerent customer managed keys for each of your encrypted log groups.

If you have a log group that you encrypted previously and now want to change the log group to use a new customer managed key that works only for that log group, follow these steps.

To convert an encrypted log group to use a customer managed key with a policy limiting it to that log group

1. Enter the following command to ﬁnd the ARN of the log group's current key:

aws logs describe-log-groups

The output includes the following line. Make a note of the ARN. You need to use it in step 7.

..."kmsKeyId": "arn:aws:kms:us-west-2:123456789012:key/01234567-89ab-cdef-0123-456789abcdef"

...

2. Enter the following command to create a new customer managed key:

aws kms create-key

3. Enter the following command to save the new key's policy to a policy.json ﬁle:

aws kms get-key-policy --key-id new-key-id --policy-name default --output text > ./

policy.json

4. Use a text editor to open policy.json and add a Condition expression to the policy:

{ "Version": "2012-10-17", "Id": "key-default-1", "Statement": [

{

"Sid": "Enable IAM User Permissions", "Effect": "Allow",

"Principal": {

"AWS": "arn:aws:iam::ACCOUNT-ID:root"

"Action": "kms:*", "Resource": "*"

}, {

"Effect": "Allow", "Principal": {

"Service": "logs.region.amazonaws.com"

"Action": [

"kms:Encrypt*",

KMS keys and encryption context

5. Enter the following command to add the updated policy to the new customer managed key:

aws kms put-key-policy --key-id new-key-ARN --policy-name default --policy file://

policy.json

6. Enter the following command to associate the policy with your log group:

aws logs associate-kms-key --log-group-name my-log-group --kms-key-id new-key-ARN

CloudWatch Logs now encrypts all new data using the new key.

7. Next, revoke all permissions except Decrypt from the old key. First, enter the following command to retrieve the old policy:

aws kms get-key-policy --key-id old-key-ARN --policy-name default --output text > ./

policy.json

8. Use a text editor to open policy.json and remove all values from the Action list, except for kms:Decrypt*

{ "Version": "2012-10-17", "Id": "key-default-1", "Statement": [

KMS keys and encryption context

9. Enter the following command to add the updated policy to the old key:

aws kms put-key-policy --key-id old-key-ARN --policy-name default --policy file://

policy.json

Concepts

Creating metrics from log events using ﬁlters

You can search and ﬁlter the log data coming into CloudWatch Logs by creating one or more metric ﬁlters. Metric ﬁlters deﬁne the terms and patterns to look for in log data as it is sent to CloudWatch Logs.

CloudWatch Logs uses these metric ﬁlters to turn log data into numerical CloudWatch metrics that you can graph or set an alarm on.

When you create a metric from a log ﬁlter, you can also choose to assign dimensions and a unit to the metric. If you specify a unit, be sure to specify the correct one when you create the ﬁlter. Changing the unit for the ﬁlter later will have no eﬀect.

You can use any type of CloudWatch statistic, including percentile statistics, when viewing these metrics or setting alarms.

NotePercentile statistics are supported for a metric only if none of the metric's values are negative. If you set up your metric ﬁlter so that it can report negative numbers, percentile statistics will not be available for that metric when it has negative numbers as values. For more information, see Percentiles.

Filters do not retroactively ﬁlter data. Filters only publish the metric data points for events that happen after the ﬁlter was created. Filtered results return the ﬁrst 50 lines, which will not be displayed if the timestamp on the ﬁltered results is earlier than the metric creation time.

Contents

• Concepts (p. 73)

• Filter and pattern syntax (p. 74)

• Creating metric ﬁlters (p. 85)

• Listing metric ﬁlters (p. 92)

• Deleting a metric ﬁlter (p. 93)

Concepts

Each metric ﬁlter is made up of the following key elements:

default value

The value reported to the metric ﬁlter during a period when logs are ingested but no matching logs are found. By setting this to 0, you ensure that data is reported during every such period, preventing

"spotty" metrics with periods of no matching data. If no logs are ingested during a one-minute period, then no value is reported.

If you assign dimensions to a metric created by a metric ﬁlter, you can't assign a default value for that metric.

dimensions

Dimensions are the key-value pairs that further deﬁne a metric. You can assign dimensions to the metric created from a metric ﬁlter. Because dimensions are part of the unique identiﬁer for a metric, whenever a unique name/value pair is extracted from your logs, you are creating a new variation of that metric.

Filter and pattern syntax

ﬁlter pattern

A symbolic description of how CloudWatch Logs should interpret the data in each log event. For example, a log entry may contain timestamps, IP addresses, strings, and so on. You use the pattern to specify what to look for in the log ﬁle.

metric name

The name of the CloudWatch metric to which the monitored log information should be published.

For example, you may publish to a metric called ErrorCount.

metric namespace

The destination namespace of the new CloudWatch metric.

metric value

The numerical value to publish to the metric each time a matching log is found. For example, if you're counting the occurrences of a particular term like "Error", the value will be "1" for each occurrence. If you're counting the bytes transferred, you can increment by the actual number of bytes found in the log event.

Filter and pattern syntax

You can create metric ﬁlters to match terms in your log events and convert log data into metrics. When a metric ﬁlter matches a term, it increments the metric's count. For example, you can create a metric ﬁlter that counts the number of times the word ERROR occurs in your log events.

You can assign units and dimensions to metrics. For example, if you create a metric ﬁlter that counts the number of times the word ERROR occurs in your log events, you can specify a dimension that's called ErrorCode to show the total number of log events that contain the word ERROR and ﬁlter data by reported error codes.

NoteWhen you assign a unit to a metric, make sure to specify the correct one. If you change the unit later, your change might not take eﬀect.

Topics

• Using ﬁlter patterns to match terms in log events (p. 74)

• Using metric ﬁlters to match terms and extract values from JSON log events (p. 76)

• Using metric ﬁlters to extract values from space-delimited log events (p. 80)

• Conﬁguring metric values for a metric ﬁlter (p. 82)

• Publishing dimensions with metrics from values in JSON or space-delimited log events (p. 82)

• Using values in log events to increment a metric's value (p. 84)

Using ﬁlter patterns to match terms in log events

Filter patterns make up the syntax that metric ﬁlters use to match terms in log events. Terms can be words, exact phrases, or numeric values. Create ﬁlter patterns with the terms that you want to match.

Filter patterns only return the log events that contain the terms you deﬁne. You can test ﬁlter patterns in the CloudWatch console. The following examples contain code snippets that show how you can use ﬁlter patterns to match terms in your log events.

NoteFilter patterns are case sensitive. Enclose exact phrases and terms that include non-alphanumeric characters in double quotation marks ("").

Using ﬁlter patterns to match terms in log events

Example: Match a single term

The following code snippet shows an example of a single-term ﬁlter pattern that returns all log events where messages contain the word ERROR.

ERROR

The ﬁlter pattern matches log event messages, such as the following:

• [ERROR 400] BAD REQUEST

• [ERROR 401] UNAUTHORIZED REQUEST

• [ERROR 419] MISSING ARGUMENTS

• [ERROR 420] INVALID ARGUMENTS

Example: Match multiple terms

The following code snippet shows an example of a multiple-term ﬁlter pattern that returns all log events where messages contain the words ERROR and ARGUMENTS.

ERROR ARGUMENTS

The ﬁlter returns log event messages, such as the following:

• [ERROR 419] MISSING ARGUMENTS

• [ERROR 420] INVALID ARGUMENTS

The ﬁlter pattern doesn't return the following log event messages because they don't contain both of the terms speciﬁed in the ﬁlter pattern.

• [ERROR 400] BAD REQUEST

• [ERROR 401] UNAUTHORIZED REQUEST

Example: Match single and multiple terms

You can use pattern matching to create ﬁlter patterns that return log events containing single and multiple terms. Place a question mark ("?") before the terms that you want to match. The following code snippet shows an example of a ﬁlter pattern that returns all log events where messages contain the word ERROR or ARGUMENTS and the words ERROR and ARGUMENTS.

?ERROR ?ARGUMENTS

The ﬁlter pattern matches log event messages, such as the following:

• [ERROR 400] BAD REQUEST

• [ERROR 401] UNAUTHORIZED REQUEST

• [ERROR 419] MISSING ARGUMENTS

• [ERROR 420] INVALID ARGUMENTS

Example: Match exact phrases

The following code snippet shows an example of a ﬁlter pattern that returns log events where messages contain the exact phrase INTERNAL SERVER ERROR.

Using metric ﬁlters to match terms and extract values from JSON log events

"INTERNAL SERVER ERROR"

The ﬁlter pattern returns the following log event message:

• [ERROR 500] INTERNAL SERVER ERROR

Example: Include and exclude terms

You can create ﬁlter patterns that return log events where messages include some terms and exclude other terms. Place a minus symbol ("-") before the terms that you want to exclude. The following code snippet shows an example of a ﬁlter pattern that returns log events where messages include the term ERROR and exclude the term ARGUMENTS.

ERROR -ARGUMENTS

The ﬁlter pattern returns log event messages, such as the following:

• [ERROR 400] BAD REQUEST

• [ERROR 401] UNAUTHORIZED REQUEST

The ﬁlter pattern doesn't return the following log event messages because they contain the word ARGUMENTS.

• [ERROR 419] MISSING ARGUMENTS

• [ERROR 420] INVALID ARGUMENTS

Example: Match everything

You can match everything in your log events with double quotation marks. The following code snippet shows an example of a ﬁlter pattern that returns all log events.

" "

Using metric ﬁlters to match terms and extract values from JSON log events

Metric ﬁlters are conﬁgurations that include ﬁlter patterns. You can create metric ﬁlters to match terms in your log events and convert log data into metrics. When your metric ﬁlter matches a term, you can increment the metric's count. Metric ﬁlters only match the terms that you deﬁne in your ﬁlter pattern.

You can test metric ﬁlters in the CloudWatch console. You also can create metric ﬁlters to match terms and extract values from JSON log events. The following examples describe the syntax for metric ﬁlters that match JSON terms containing strings and numeric values.

Example: Metric ﬁlters that match strings

You can create metric ﬁlters to match strings in JSON log events. The following code snippet shows an example of the syntax for string-based metric ﬁlters.

{ PropertySelector EqualityOperator String }

Enclose metric ﬁlters in curly braces ("{}"). String-based metric ﬁlters must contain the following parts:

Using metric ﬁlters to match terms and extract values from JSON log events

• Property selector

Set oﬀ property selectors with a dollar sign followed by a period ("$."). Property selectors are alphanumeric strings that support hyphen ("-") and underscore ("_") characters. Strings don't support scientiﬁc notation. Property selectors point to value nodes in JSON log events. Value nodes can be strings or numbers. Place arrays after property selectors. Arrays contain elements that follow a zero-based ordering system (0 = 1, 1 = 2, and so on). Enclose elements in brackets ("[]"). If a property selector points to an array or object, the metric ﬁlter won't match the log format.

• Equality operator

Set oﬀ equality operators with one of the following symbols: equal ("=") or not equal ("!="). Equality operators return a Boolean value (true or false).

• String

You can enclose strings in double quotation marks (""). Strings that contain types other than alphanumeric characters and the underscore symbol must be placed in double quotation marks. Use the asterisk ("*") as a wild card to match text.

The following code snippet contains an example of a metric ﬁlter showing how you can format a metric ﬁlter to match a JSON term with a string.

{ $.eventType = "UpdateTrail" }

Example: Metric ﬁlters that match numeric values

You can create metric ﬁlters to match numeric values in JSON log events. The following code snippet shows an example of the syntax for metric ﬁlters that match numeric values.

{ PropertySelector NumericOperator Number }

Enclose metric ﬁlters in curly braces ("{}"). Metric ﬁlters that match numeric values must have the following parts:

• Property selector

• Numeric operator

Set oﬀ numeric operators with one of the following symbols: greater than (">"), less than ("<"), equal ("="), not equal ("!="), greater than or equal to (">="), or less than or equal to ("<=").

• Number

You can use integers that contain plus ("+") or minus ("-") symbols and follow scientiﬁc notation. Use the asterisk ("*") as a wild card to match numbers.

The following code snippet contains examples showing how you can format metric ﬁlters to match JSON terms with numeric values.

// Metric filter with greater than symbol { $.bandwidth > 75 }

Using metric ﬁlters to match terms and extract values from JSON log events // Metric filter with less than symbol

{ $.latency < 50 }

// Metric filter with greater than or equal to symbol { $.refreshRate >= 60 }

// Metric filter with less than or equal to symbol { $.responseTime <= 5 }

// Metric filter with equal sign { $.errorCode = 400}

// Metric filter with not equal sign and scientific notation { $.errorCode != 500 }

// Metric filter with scientific notation and plus symbol { $.number[0] = 1e-3 }

// Metric filter with scientific notation and minus symbol { $.number[0] != 1e+3 }

Matching terms in JSON log events

The following examples contain code snippets that show how metric ﬁlters can match terms in a JSON log event.

Example: JSON log event

{ "eventType": "UpdateTrail",

"sourceIPAddress": "111.111.111.111", "arrayKey": [

"value", "another value"

"objectList": [ {

"name": "a", "id": 1 },

{

"name": "b", "id": 2 }

"SomeObject": null }

Note

If you test the example metric ﬁlters with the example JSON log event, you must enter the example JSON log on a single line.

Example: Metric ﬁlter that matches string

The metric ﬁlter matches the string "UpdateTrail" in the property "eventType".

{ $.eventType = "UpdateTrail" }

Example: Metric ﬁlter that matches number

The metric ﬁlter contains a wild card and matches the property "sourceIPAddress" because it doesn't contain a number with the preﬁx "123.123".

{ $.sourceIPAddress != 123.123.* }

Example: Metric ﬁlter that matches element in array

Using metric ﬁlters to match terms and extract values from JSON log events

The metric ﬁlter matches the element "value" in the array "arrayKey".

{ $.arrayKey[0] = "value" }

Example: Metric ﬁlter that matches an object in array

The metric ﬁlter matches the object "id":2 in the array "objectList".

{ $.objectList[1].id = 2 }

Example: Metric ﬁlter that matches JSON logs using IS

You can create metric ﬁlters that match ﬁelds in JSON logs with the IS variable. The IS variable can match ﬁelds that contain the values NULL, TRUE, or FALSE. The following metric ﬁlter returns JSON logs where the value of SomeObject is NULL.

{ $.SomeObject IS NULL }

Example: Metric ﬁlter that matches JSON logs using NOT EXISTS

You can create metric ﬁlters with the NOT EXISTS variable to return JSON logs that don't contain speciﬁc ﬁelds in the log data. The following metric ﬁlter uses NOT EXISTS to return JSON logs that don't contain the ﬁeld SomeOtherObject.

{ $.SomeOtherObject NOT EXISTS }

Note

The variables IS NOT and EXISTS currently aren't supported.

Using compound expressions to match terms in JSON objects

You can use the logical operators AND ("&&") and OR ("||") in metric ﬁlters to create compound expressions that match log events where two or more conditions are true. Compound expressions support the use of parentheses ("()") and the following standard order of operations: () > && > ||. The following examples contain code snippets that show how you can use metric ﬁlters with compound expressions to match terms in a JSON object.

Example: JSON object

{

"user": { "id": 1,

"email": "[email protected]"

"users": [ {

"id": 2,

"email": "[email protected]"

}, {

"id": 3,

"email": "[email protected]"

} ],

"actions": [ "GET", "PUT",

Using metric ﬁlters to extract values from space-delimited log events "DELETE"

"coordinates": [ [0, 1, 2], [4, 5, 6], [7, 8, 9]

] }

Example: Expression that matches using AND (&&)

The metric ﬁlter contains a compound expression that matches "id" in "user" with a numeric value of 1 and "users" in "email" with the string "[email protected]".

{ ($.user.id = 1) && ($.users[0].email = "[email protected]") }

Example: Expression that matches using OR (||)

The metric ﬁlter contains a compound expression that matches "email" in "user" with the string

"[email protected]".

{ $.user.email = "[email protected]" || $.coordinates[0][1] = "nonmatch" &&

$.actions[2] = "nonmatch" }

Example: Expression that doesn't match using AND (&&)

The metric ﬁlter contains a compound expression that doesn't ﬁnd a match because the expression doesn't match the ﬁrst and second coordinates in "coordinates" and the third action in "actions".

{ ($.user.email = "[email protected]" || $.coordinates[0][1] = "nonmatch") &&

$.actions[2] = "nonmatch" }

Example: Expression that doesn't match using OR (||)

The metric ﬁlter contains a compound expression that doesn't ﬁnd a match because the expression doesn't match the ﬁrst property in "users" or the third action in "actions".

在文檔中 Amazon CloudWatch Logs (頁 75-143)