Feature request: Avoid flushing metrics when no metrics to flush

[bml1g12]

Use case

We are using

    "@middy/core": "^4.0.2",
    "@aws-lambda-powertools/metrics": "^1.0.1",

Metrics with this setup:

const log = new Logger({
  // POWERTOOLS_LOG_LEVEL environment variable sets log level
  serviceName: config.serviceName,
  persistentLogAttributes: {
    release: config.releaseVersion,
    environment: config.stage,
  },
})

const metrics = new Metrics({
  serviceName: config.serviceName,
  namespace: "xxx",
  defaultDimensions: {
    aws_account_id: config.awsAccountId,
    aws_region: config.region,
  },
})

const tracer = new Tracer({ serviceName: config.serviceName })
// You can use tracer.provider attribute to access all methods provided by the AWS X-Ray SDK.
// This is useful when you need a feature available in X-Ray that is not available in the
// Tracer utility, for example, SQL queries tracing, or a custom logger.
tracer.provider.setLogger(log)

const withMiddy = (handler: Handler) =>
  middy(handler)
    .use(captureLambdaHandler(tracer))
    .use(logMetrics(metrics, { captureColdStartMetric: false }))

And if we do not log any metrics cloudwatch logs report what I think is a redundant log that makes logs a little harder to read through and of course expends a tiny amount of money to emit:

2024-09-04T12:33:44.468Z
{
    "_aws": {
        "Timestamp": 1725453224468,
        "CloudWatchMetrics": [
            {
                "Namespace": "xxx",
                "Dimensions": [
                    [
                        "service",
                        "aws_account_id",
                        "aws_region"
                    ]
                ],
                "Metrics": []
            }
        ]
    },
    "service": "xxx",
    "aws_account_id": "xxx",
    "aws_region": "ap-northeast-1"
}

Solution/User Experience

I believe the AWS Powertools Library for Python does not produce such empty logs, I think the ideal behaviour would be to omit these logs entirely if there's no metrics to log?

Alternative solutions

We could of course omit including the library entirely for each lambda, but given the middleware is often used to apply generic boilerplate to all lambdas in a repo, I don't think that would be appropriate if we wanted to only report metrics for some lambdas.

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

[dreamorosi]

Hi @bml1g12, thank you for opening this feature request.

From a first look, it seems that this could be related or at least have a good amount of overlap with #2036, would you mind taking a look and see if this is the case?

If yes, I think we could close this and use the other. That issue hasn't been updated in a few months but I now see that in addition to this issue, there's a decent amount of interest by looking at the 👍, so it could be a good time to repriotize it.

As a side note, v1 of Powertools for AWS Lambda (TypeScript) has reached end of life this week, so I would advise to consider upgrading to a more recent version in the v2.x line.

[bml1g12]

Hi @bml1g12, thank you for opening this feature request.

From a first look, it seems that this could be related or at least have a good amount of overlap with #2036, would you mind taking a look and see if this is the case?

If yes, I think we could close this and use the other. That issue hasn't been updated in a few months but I now see that in addition to this issue, there's a decent amount of interest by looking at the 👍, so it could be a good time to repriotize it.

As a side note, v1 of Powertools for AWS Lambda (TypeScript) has reached end of life this week, so I would advise to consider upgrading to a more recent version in the v2.x line.

Thanks @dreamorosi , I think that issue basically covers this request so will close it, although I notice in your response there you focus on the topic of removing the warning which is a good point and something I'd like to be able to hide; however I should note my main concern is the fact that we log an empty metric on top of that; so even if we disable the warning, we'd want to also disable the empty metric log.

Taking Powertools Python as an example, they log this warning using the warning standard module. This gives customers a way to suppress warnings without having to change their code.

In Powertools Python they do not log an empty metric at all, just the warning