[RFC] Remove LogGroupName as default dimension

[jaredcnance]

This issue is to receive feedback on whether or not users want LogGroup as a default dimensions on your metrics. This was originally intended to enable deep-linking from metrics to the EMF events, but we no longer believe this is the correct approach to creating this linkage. This is a breaking change, so we want to hear your feedback.

aws-embedded-metrics-node/src/logger/MetricsLogger.ts

Lines 142 to 147 in 2ec8a84

	const defaultDimensions = {
	// LogGroup name will entirely depend on the environment since there
	// are some cases where the LogGroup cannot be configured (e.g. Lambda)
	LogGroup: environment.getLogGroupName(),
	ServiceName: Configuration.serviceName || environment.getName(),
	ServiceType: Configuration.serviceType || environment.getType(),

[cmckni3]

I agree with removing LogGroup as a default dimension. In my opinion, the log group adds noise to the CloudWatch metric.

[thantos]

Its creating more problem than value for me. CDK exposes the log groups name from lambda as /aws/lambda/[log group name], but this library creates the dimension as /[log group name] meaning my dashboard widgets won't work without some extra work (that I have not figured out yet).

[cmckni3]

Its creating more problem than value for me. CDK exposes the log groups name from lambda as /aws/lambda/[log group name], but this library creates the dimension as /[log group name] meaning my dashboard widgets won't work without some extra work (that I have not figured out yet).

It's tricky with CDK especially with CloudWatch dashboards. Would be interested in seeing your CDK stack/construct.

[thantos]

  metricCustomMetric(metricName: string, options?: MetricOptions): IMetric {
    return new Metric({
      namespace: MetricConstants.namespace,
      metricName,
      dimensions: {
        ServiceName: MetricConstants.serviceName(this.props.serviceQualifier),
        ServiceType: MetricConstants.serviceType,
        /*
         logGroupName will output /aws/lambda/[name]
         EMF will put just [name] in the log group name dimension. We need just [name].
        */
        LogGroup: Fn.select(3, Fn.split('/', this.computeMetricsFunction.logGroup.logGroupName))
      },
      ...options
    });
  }

[cmckni3]

@thantos Does the stack error out?

The code makes sense and seems like it would work.

A caveat with log groups and Lambda: log groups are created after the first invocation of the function. In my stack, I create the log group up front so I can attach metric filters.

[thantos]

No, I've recreated it a few times and the stack has been fine. I don't think metrics care about the existence of the metric its pointing to. And log name here is just a dimension and not an identifier.

[cmckni3]

No, I've recreated it a few times and the stack has been fine. I don't think metrics care about the existence of the metric its pointing to. And log name here is just a dimension and not an identifier.

Yeah. It depends. Metric filters and retention for log groups need the log group to be attached.

I started using CDK before the CFN retention property existed on log groups. Has been a journey.

[Glen-Moonpig]

Get rid 👍

[mduesterhoeft]

Actually the LogGroup dimension is getting in our way as well. We have metrics that are emitted from different lambdas. When adding alarms for such metrics we need to add alarms for each log group. This is a bit annoying and error prone. It would be desirable to at least be able to switch off the creation of the log group dimension.