[lambda] expose log group and support metric filter

[alexarb]

🚀 Feature Request

General Information

• 👋 I may be able to implement this feature request

• ⚠️ This feature might incur a breaking change

Description

Currently it's impossible to add MetricFilter for Lambda logs, because Lambda does not return log group and log group will be created only after any invocations of function. Manually created log groups (in CDK) might not work because of possible race conditions.

Addition of MetricFilter to logs is similar to LogGroup retention setting as discussed here #667 (comment) and implemented in PR #2067

Proposed Solution

Environment

• CDK CLI Version:
  all
• Module Version:
  all
• OS:
  all
• Language:
  all

Other information

[SomayaB]

Hi @alexarb, thanks for submitting a feature request! We will look into this and someone will update this issue when there is movement.

[nija-at]

Related #667

[AdonousTech]

Hello. Any update on this feature request? This is a major issue when attempting to create metric filters on lambda logs. Currently we must use ILogGroup for the logGroup property of the MetricFilter construct. This limits possible workarounds (e.g. referencing the name of existing log group). The only workaround seems to be manually creating the metric filter in the console. That is far from ideal.

[ivoanjo]

+1 my team is also facing the issue @AdonousTech mentioned above.

[nija-at]

Based on lambda's documentation, it seems that the log group name for the function will always be /aws/lambda/<function name>.

@alexarb, @AdonousTech & @ivoanjo - would using the LogGroup.fromLogGroupARN() API or the upcoming LogGroup.fromLogGroupName() API and manually specifying the LogGroup ARN or name unblock your use cases?

[Marty-Me]

We're facing the same issue. @nija-at It won't, as the Log Group is only created after the initial invocation of the Lambda. What worked for me was creating the Log Group ourselves /aws/lambda/<function name> and after this creating the metrics filter.

[AdonousTech]

@nija-at I was able to get it working last night by using the logs.LogGroup.fromLogGroupArn. However, I only tested it on a stack update. I need to test it on the full stack creation to ensure there are no race conditions (e.g. LogGroup.fromLogGroupArn does not work because log group is not yet created). I will update and let you know whether it worked.

Here's the syntax for my metric filter (I declared the actual metric and lambda function earlier in the stack):

      this.metricFilter = new logs.MetricFilter(this, 'MetricFilter', {
        filterPattern: {logPatternString: '{ $.eventType = "CriticalError" }'},
        logGroup: logs.LogGroup.fromLogGroupArn(this, 'LogGroup', 'arn:aws:logs:' + props?.env?.region + ':' + props?.env?.account + ':log-group:/aws/lambda/' + this.lambdaFunction.functionName),
        metricNamespace: this.metric.namespace,
        metricName: this.metric.metricName,
        defaultValue: 0,
        metricValue: '1'
      });

[AdonousTech]

I had a chance to test my workaround above, but as I suspected, it fails when creating a new stack.

The specified log group does not exist. (Service: AWSLogs; Status Code: 400; Error Code: ResourceNotFoundException; Request ID: 9f1672ef-e9a5-4d51-aa63-9786f5280fff)

Also, we cannot create the log group ahead of time because log groups starting with aws are restricted. Consequently, the solution above is better than nothing. Until the feature is added, I will need to comment out certain parts of the code, and uncomment after the lambda function and log group is created.

I will continue to watch this thread for updates.

[nija-at]

Thanks for your responses.

What worked for me was creating the Log Group ourselves

@Marty-Me - did you do this through the CDK app or outside (CLI or console)?

we cannot create the log group ahead of time because log groups starting with aws are restricted

@AdonousTech - how do you mean? I was able to do the following -

⇒  aws logs create-log-group --log-group-name /aws/lambda/test-group
⇒  aws logs describe-log-groups --log-group-name-prefix /aws/lambda/test --query 'logGroups[].logGroupName'
[
    "/aws/lambda/test-group"
]

[Marty-Me]

@nija-at using the cdk, as I used the lambda's name, an implicit dependency was created between the log group and the lambda, which prevented 'order of creation'-conflicts.

[AdonousTech]

@nija-at I take that back, I can actually create the log group. I'm not sure what I did wrong last time when I received the naming error.

After working through this, it seems that I now have an acceptable flow. In my TS code I simply 1) declare the LogGroup after the lambda.Function and follow the standard naming convention /aws/lambda/' + this.functionName. 2) I reference the log group on the MetricFilter by simply using this.logGroup. This order seems to work (e.g. lambda function first, log group second).

Problem solved. Thanks! For anyone else struggling with this:

      // first declare lambda function
      this.lambdaFunction = new lambda.Function(this, Vars.lambda.functionName, {
        runtime: lambda.Runtime.NODEJS_12_X,
        handler: 'index.handler',
        tracing: lambda.Tracing.ACTIVE,
        role: this.executionRole,
        code: lambda.Code.fromAsset(path.join(__dirname, '../../lambda/code/skill_lambda.zip'))
      });

      // declare log group using standard naming convention
      this.logGroup = new LogGroup(this, 'LogGroup', {
        logGroupName: '/aws/lambda/' + this.lambdaFunction.functionName
      })

      // declare other dependencies on log group such as metric filter, alarms, etc
            this.metricFilter = new logs.MetricFilter(this, 'MetricFilter', {
        filterPattern: {logPatternString: '{ $.eventType = "CriticalError" }'},
        logGroup: this.logGroup,
        metricNamespace: this.metric.namespace,
        metricName: this.metric.metricName,
        defaultValue: 0,
        metricValue: '1'
      });

[mariusGundersen]

There seems to be two ways to do this:

• create a new logGroup()
• get an existing logGroup using LogGroup.fromLogGroupArn()

The first method only works if the log group doesn't already exist, but the second one only works if the log group already exists. In my scenario I had made the lambda (and the log group) in a previous deploy, and then I wanted to add a subscription to the log group in a second deploy, so I had to use the second variant. But then I tried to deploy this construct in a new stack, and now it failed, since the log group didn't exist yet. So Unless you know the state of the stack you are deploying to you can't really use these.