Feature request: Support setting functionName for cold-starts via middy

[steven10172]

Use case

I would like to use the logMetrics middleware and specify an alternative function name. This would allow for names to be more static since CDK may sometimes replaces functions and the trailing characters are random.

Solution/User Experience

I would recommend updating the middy ExtraOptions interface to accept another property called functionName that if defined is used instead of request.context.functionName.

Example usage:

export const handler = middy()
  .use(injectLambdaContext(logger, { resetKeys: true }))
  .use(
    logMetrics(metrics, {
      captureColdStartMetric: true,
      defaultDimensions: { functionName: LambdaNames.GET_ASSET },
    }),
  )
  .handler(getAssetHandler);

Alternative solutions

Another solution would be to expose an object to the ExtraOptions interface that would allow attaching any dimensions to the cold start metric. This can then be used to override the function_name dimension, though caution would need to be exercised to ensure the value is not overwritten within the cold start check (ref)

Example usage:

export const handler = middy()
  .use(injectLambdaContext(logger, { resetKeys: true }))
  .use(
    logMetrics(metrics, {
      captureColdStartMetric: true,
      coldStartDimensions: { function_name: LambdaNames.GET_ASSET },
      defaultDimensions: { functionName: LambdaNames.GET_ASSET },
    }),
  )
  .handler(getAssetHandler);

Acknowledgment

• This feature request meets Powertools for AWS Lambda (TypeScript) Tenets
• Should this be considered in other Powertools for AWS Lambda languages? i.e. Python, Java, and .NET

Future readers

Please react with 👍 and your use case to help us understand customer demand.

[boring-cyborg]

Thanks for opening your first issue here! We'll come back to you as soon as we can.
In the meantime, check out the #typescript channel on our Powertools for AWS Lambda Discord: Invite link

[am29d]

Hey @steven10172

thanks for opening the issue. After a bit of testing I realise that having this option would reduce the number of metrics for a cold start. It is possible with the right query, but the number of metric will still increase with each Lambda resource replacement.

We have seen a similar request recently to decouple resource names from configuration, i.e. Idempotency records and function names. I see a risk for users to unintentionally override the name which makes it hard to track back the actual resource of the function, but that is the price of the customisation.

Maybe I am missing something, but I'd put the functionName into constructor to override the default name.

I am curious to hear @hjgraca, @phipag and @leandrodamascena views, how they'd see it in Python, .NET and Java

[leandrodamascena]

Hi @am29d! Thanks for tagging me here.

thanks for opening the issue. After a bit of testing I realise that having this option would reduce the number of metrics for a cold start. It is possible with the right query, but the number of metric will still increase with each Lambda resource replacement.

Are you talking about adding this as a default dimension? If so, I completely agree that we shouldn't do this using default dimensions because the experience isn't the best and you'll probably end up with multiple dimensions, making it harder to search, potentially losing data, and the customers will probably paying twice for the metrics.

Maybe I am missing something, but I'd put the functionName into constructor to override the default name.

Yes, that's a good option! I'm just wondering if the name should be functionName or something else, I don't have strong opinions here and if you decide to go with functionName I will do the same in Python.

[phipag]

Hey @am29d! The behavior in Java is the same. It is not possible to customize the function name. It is extracted from the Lambda context.

I agree with the option to add a functionName argument and I can do the same in Java. Due to the static nature of the MetricsLogger in Java, I suggest adding it to the decorator @Metrics(captureColdStart = true, functionName = "MyFunctionName").

I want to make sure I understand this correctly: Adding the functionName will not create an additional dimension for all metrics but only overwrite the function name when emitting the cold start metric, correct?

[dreamorosi]

I want to make sure I understand this correctly: Adding the functionName will not create an additional dimension for all metrics but only overwrite the function name when emitting the cold start metric, correct?

That's correct - this is also why we are not adding it to the defaultDimensions hash map.

[dreamorosi]

I think we all agree that we should allow customers to modify the function name.

The two additional points to resolve is where to add it. In Java the Metrics class is static, so the only option is to pass it to the decorator - I suspect the same is true for .NET (is it @hjgraca?).

For Python & TS, we can go either way:

Option 1

const metrics = new Metrics({
  functionName: 'foo'
});

export const handler = middy()
  .use(logMetrics(metrics, {
    captureColdStart: true,
  })
  .handler( ... ) 

Option 2

const metrics = new Metrics();

export const handler = middy()
  .use(logMetrics(metrics, {
    captureColdStart: true,
    functionName: 'foo'
  })
  .handler( ... ) 

---

Java/.NET are going for something similar to option 2.

Personally I'd prefer option 1, but for consistency's sake and also because captureColdStart is already there I kind of think option 2 is probably a bit better.

[steven10172]

My preference is option 2 as it works better for projects with 100s of handlers and run across 100s of lambdas. For simplicity my team has a generic metric object we consume, though I could make option 1 work via ENV injection of the value.

Note: 🤔 maybe an ENV variable that sets the value could be of use here. It would allow more stable/connected values via CDK.

Another reason for option 2, is that outside of middy you can already set the function name via

metrics.setFunctionName('my-function-name').

It's just that middy always sets the value to context, so maybe an alternative to option 2 is to only set the name if not currently defined.

In theory you could offer the following:

• .setFunctionName() remains as-is
• functionName is a Metric constructor parameter
• The middy handler only sets functionName if it's not defined
• Support POWERTOOLS_FUNCTION_NAME for better CDK static definition of the value as it's likely a more stable infra value compared to function code

And optionally you could support overriding of functionName in the middy middleware as a parameter, but I'm not certain this is required if other options mentioned above are supported. Though support for a middy override would mimic how the other values like defaultDimensions work.

edit: spelling and grammar adjustments

[am29d]

In theory you could offer the following:

• .setFunctionName() remains as-is
• functionName is a Metric constructor parameter
• The middy handler only sets functionName if it's not defined
• Support POWERTOOLS_FUNCTION_NAME for better CDK static definition of the value as it's likely a more stable infra value compared to function code

I agree, this will to use this feature for all options we provide, with or without middy.

[am29d]

@steven10172 will be working on the PRs for these change.

[github-actions]

⚠️ COMMENT VISIBILITY WARNING ⚠️

This issue is now closed. Please be mindful that future comments are hard for our team to see.

If you need more assistance, please either tag a team member or open a new issue that references this one.

If you wish to keep having a conversation with other community members under this issue feel free to do so.

[github-actions]

This is now released under v2.17.0 version!