MetricFilter should expose its metric definition via a metric property.

[sam-goodwin]

Say you create a MetricFilter:

new logs.MetricFilter(this, 'MetricFilter', {
  filterPattern: logs.FilterPattern.exists('$.myMetric'),
  metricNamespace,
  metricName,
  metricValue: '$.myMetric',
  logGroup
});

This filter should expose a property for the metric it defines.

// I want to call
const metric = metricFilter.metric()

// instead of
const metric = new cloudwatch.Metric({
  metricName,
  namespace: metricNamespace,
  statistic: cloudwatch.Statistic.Maximum
})

[eladb]

👍 Our convention is to expose metric() methods on AWS constructs.

[rix0rrr]

Yep, that's a good idea.

[michaelday008]

While this change is being made, is it possible to link the metric filter to the alarm?

In the UI, I can look at any metric filter on a log group, and click the "create alarm" button and then when looking at the log filters, the attached alarm will show.

Using CDK, this seems to be created in a disconnected fashion so when I go into the UI and look at the metric filter it doesn't show the alarm. I have to go to the alarms page and see them and it can be difficult to make the connection that this metric filter will result in an alarm.

[michaelwiles]

So I've run into this "issue" as well...

Fundamentally it's a bit clunky that in order to create a metric when you have a metric filter you make sure that metric names are the same.

This is the non intuitive or hard to figure out aspect of how it is now.

It would be nice to have some more explicit solution though I'm not sure what it would look like...

Part of the challenge is that in order to create a metric from a metric filter you need a bit more information. i.e. you need a statistic - metric filter does not have this.

So I would propose adding a method to metric say, "from_metric_fitler(metric_filter, ...)" and then include the extra info needed to create a metric from a metric filter.

I'm fairly confident this is possible at the type script level...

I would say it should rather be on metric than on metric filter...

[rix0rrr]

I would recommend a getter instead of a method.