Amazon CloudWatch Logs
User Guide

Example: Find and Count 400-level into 4xx Metric

As in the previous example, you might want to monitor your web service access logs and monitor the HTTP response code levels. For example, you might want to monitor all of the HTTP 400-level errors. However, you might not want to specify a new metric filter for every return code.

The following example demonstrates how to create a metric that includes all 400-level HTTP code responses from an access log using the Apache access log format from the Example: Counting HTTP 404 Responses example.

To create a metric filter using the CloudWatch console

  1. Open the CloudWatch console at

  2. If necessary, change the region. From the navigation bar, select the region that meets your needs. For more information, see Regions and Endpoints in the Amazon Web Services General Reference.

  3. In the navigation pane, click Logs.

  4. In the contents pane, select a log group, and then click Create Metric Filter.

  5. On the Define Logs Metric Filter screen, in the Filter Pattern field, enter [ip, id, user, timestamp, request, status_code=4*, size].

  6. To test your filter pattern, in the Select Log Data to Test list, select the log group you want to test the metric filter against, and then click Test Pattern.

  7. Under Results, CloudWatch Logs displays a message showing how many occurrences of the filter pattern were found in the log file.


    To see detailed results, click Show test results.

  8. Click Assign Metric, and then on the Create Metric Filter and Assign a Metric screen, in the Filter Name field, enter HTTP4xxErrors.

  9. Under Metric Details, in the Metric Namespace field, enter YourNameSpace.

  10. In the Metric Name field, enter HTTP4xxErrors, and then click Create Filter.

To create a metric filter using the AWS CLI

  • At a command prompt, remove the backslashes (\) and type this all on one line:

    % aws logs put-metric-filter \
      --log-group-name MyApp/access.log \
      --filter-name HTTP4xxErrors \
      --filter-pattern '[ip, id, user, timestamp, request, status_code=4*, size]' \
      --metric-transformations \

You can use the following data in put-event calls to test this rule. If you did not remove the monitoring rule in the previous example, you will generate two different metrics. - - [24/Sep/2013:11:49:52 -0700] "GET /index.html HTTP/1.1" 404 287 - - [24/Sep/2013:11:49:52 -0700] "GET /index.html HTTP/1.1" 404 287 - - [24/Sep/2013:11:50:51 -0700] "GET /~test/ HTTP/1.1" 200 3 - - [24/Sep/2013:11:50:51 -0700] "GET /favicon.ico HTTP/1.1" 404 308 - - [24/Sep/2013:11:50:51 -0700] "GET /favicon.ico HTTP/1.1" 404 308 - - [24/Sep/2013:11:51:34 -0700] "GET /~test/index.html HTTP/1.1" 200 3