feat(iot): add Action to capture CloudWatch metrics

[yamatatsu]

I'm trying to implement aws-iot L2 Constructs.

This PR is one of steps after following PR:

• feat(iot): add the TopicRule L2 construct #16681 (comment)

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[gitpod-io]

[skinny85]

Looks great as usual, @yamatatsu! A few minor comments.

[skinny85]

Can't we use the Metric class from the CloudWatch module instead of all these separate props here?

[yamatatsu]

@skinny85
I thought it too. But if using Metric class, we will not be able to use substitution templates.
So I think it is better that we provide fromMetric() method.

[skinny85]

Interesting... what's the problem that prevents using Metric with substitution templates?

[yamatatsu]

@skinny85
I had envisioned using Metric class as following.

const metric = new cloudwatch.Metric({
  namespace: 'test-namespace',
  metricName: 'test-name',
  unit: cloudwatch.Unit.COUNT,
});
new CloudWatchPutMetricAction(metric, {
  metricValue: '${temperature}',
  metricTimestamp: '${timestamp}',
});

In above case, I predicted that users might think "I cannot use substitution templates in namespace, metricName and unit".

Hmmm🤔. As I was writing this, I realized that there was nothing preventing from using substitution templates in properties besides unit as following.

const metric = new cloudwatch.Metric({
  namespace: '${namespace}',
  metricName: '${topic(2)}',
});

I'm a little uncomfortable with it, in that substitution templates are written in Metric class props. How about?

And unit cannot be used with substitution templates because unit is enum in Metric.

[skinny85]

How common it is to use a dynamic Unit, do you think?

We can work around it by having something like:

new CloudWatchPutMetricAction(metric, {
  dynamicUnit: `${sth}`,
});

It is a little bit awkward, I agree.

[yamatatsu]

I think it's a pretty rare case that a unit is used dynamically.

For just one thing, How about this?
We keep current props, and we provide metric() method like metric-filter.ts.
Because, in many case, CloudWatchPutMetricAction will generate new custom metric for example temperature, weight and moisture. And alerms will be created with this metrics.
So I think users maybe will want metric after they make the topic rules.

[skinny85]

OK, sounds good.

[skinny85]

Use the Metric.grantPutMetricData() method instead.

[yamatatsu]

cool!

Pull request has been modified.

[skinny85]

Looks great @yamatatsu!

[mergify]

Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildProject89A8053A-LhjRyN9kxr8o
• Commit ID: 12773ba
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[mergify]

Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).