Example: Count HTTP 4xx codes - Amazon CloudWatch Logs
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Example: Count HTTP 4xx codes

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: Count HTTP 404 codes example.

To create a metric filter using the CloudWatch console
  1. Open the CloudWatch console at https://console.amazonaws.cn/cloudwatch/.

  2. In the navigation pane, choose Log groups.

  3. Choose the name of the log group for the Apache server.

  4. Choose Actions, Create metric filter.

  5. For Filter pattern, enter [ip, id, user, timestamp, request, status_code=4*, size].

  6. (Optional) To test your filter pattern, under Test Pattern, enter one or more log events to use to test the pattern. Each log event must be within one line, because line breaks are used to separate log events in the Log event messages box.

  7. Choose Next, and then for Filter name, type HTTP4xxErrors.

  8. Under Metric details, for Metric namespace, enter MyNameSpace.

  9. For Metric name, enter HTTP4xxErrors.

  10. For Metric value, enter 1. This specifies that the count is incremented by 1 for every log containing a 4xx error.

  11. For Default value enter 0, and then choose Next.

  12. Choose Create metric filter.

To create a metric filter using the Amazon CLI

At a command prompt, run the following command:

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 \ metricName=HTTP4xxErrors,metricNamespace=MyNamespace,metricValue=1,defaultValue=0

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