CloudWatch Metric Filters are the recommended way to create custom metrics from Lambda functions. Sending the metrics directly from the lambda function to the CloudWatch api is the main alternative, but it has several disadvantages including, not least, the cost (at scale). It does seem like a cleaner and cheaper approach to log the metics out to CloudWatch Logs and then have a Metric filter extract the metric from the logs.

The main disadvantage this approach seems to have is the lack of support for Dimensions.

Let's say I have a metric I want to record from my executing lambda function called CountIDidSomething, and since this is count the value is always 1.

If I was to use the CloudWatch api to send this metric then I would be able to include dimensions to label it with the name of the lambda function for example.

However, if I use the Metric Filter approach I can't add dimensions. The only alternative I have is to put the name of the lambda function in the name of the metric, but I end up with a large number of custom metrics being created, all representing the same metric but with different names. This seems to go against the purpose of metrics as generic labels for values coming from different sources. where dimensions are used to slice and dice them.

I wanted to see if anyone knew of a better approach to either of these two, or whether I will just have to make do with what I've got.

  • 1
    Sounds like you already have the answer to your question in the question itself... – Tensibai Jan 3 '18 at 13:54
  • I have an approach but I don't much like it. I was hoping someone might know of a better one. – Andy McCluggage Jan 5 '18 at 15:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.