Feature request: Remove 'service' dimension from single_metric()

[nikevp]

Use case

My team has a specific metric format used across lambda runtimes with the following dimensions: [Operation, Function]. I would like to use single_metric without 'service' added as a third dimension.

I would remove POWERTOOLS_SERVICE_NAME, but we also leverage the powertools Logger.

Solution/User Experience

The ability to exclude 'service' as a dimension from single_metric calls.

Alternative solutions

Support ignoring POWERTOOLS_SERVICE_NAME globally in Metric() since it is required by Logger.

Acknowledgment

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

[leandrodamascena]

Hello @nikevp! Thanks for opening this issue! I'd like to hear from other maintainers what they think about this, as disabling POWERTOOLS_SERVICE_NAME globally can be a problem and lead to unexpected behavior. Adding a flag to single_metric makes this very specialized and perhaps not the best developer experience.
I'm not saying that we won't analyze how to implement this or that I'm against it, but I don't have a strong opinion on this matter and I would like to ask my peers for help.

For now, if this is a mandatory requirement and is harming your production environment I might suggest you set the public service variable to None before single_metric's ContextManager flushes it. It's not the best experience, but it works as a workaround while we try to figure out a solution to this.

Something like this:

import os

from aws_lambda_powertools import single_metric
from aws_lambda_powertools.metrics import MetricUnit
from aws_lambda_powertools.utilities.typing import LambdaContext

STAGE = os.getenv("STAGE", "dev")


def lambda_handler(event: dict, context: LambdaContext):
    with single_metric(name="MySingleMetric", unit=MetricUnit.Count, value=1, namespace="TEST") as metric:
        metric.add_dimension(name="environment", value=STAGE)
        metric.add_dimension(name="xyz", value="123")
        metric.service = None

cc @sthulb @rubenfonseca

Thanks

[rubenfonseca]

Agree with @leandrodamascena comments. At most, we could add a service kwarg to the single_metric call to make it easier to remove it, but this is not recommended behaviour anyway. The workaround may be sufficient.

[sthulb]

I agree with @rubenfonseca – I think using @leandrodamascena's code snippet, you could wrap it in a function to ensure that you get what you want without having context managers everywhere in your code

[nikevp]

Thanks for the quick reply @leandrodamascena. Your example works perfectly for my use case and I'm already using a singleton function for the logic.

I was running into issues Friday trying to pass service=None which is ignored due to

powertools-lambda-python/aws_lambda_powertools/metrics/base.py

Line 189 in fa235c0

if self.service and not self.dimension_set.get("service"):

Since you can easily remove the dimension before emitting, I no longer see any need for a code change. However, it might be worth noting in the logger documentation that adding $POWERTOOLS_SERVICE_NAME will automatically add a dimension to all metrics. This might be a rare edge case, but could negatively impact existing alarm coverage.

[leandrodamascena]

Hi @nikevp! Thank you for the feedback! I'm pleased to hear that you were able to resolve the issue.
We have a section in our documentation explaining that a new dimension will be created. While I believe it's well-explained, I'd appreciate your opinion on whether we should enhance this message.

https://docs.powertools.aws.dev/lambda/python/latest/core/metrics/#getting-started

Thank you.

[nikevp]

Hey @leandrodamascena, I agree the metric ENV documentation is clear. On my side, I overlooked the implications of adding POWERTOOLS_SERVICE_NAME to the logger without considering the impact on metrics.

Here it does not indicate adding POWERTOOLS_SERVICE_NAME will impact metrics: https://docs.powertools.aws.dev/lambda/python/latest/core/logger/#getting-started

It's easy to catch in development by reviewing the logs, but only if you are setting up Metrics after Logger. If you setup the Metrics feature and later on add the Logger, a user might add POWERTOOLS_SERVICE_NAME without knowing it changes dimensions. This might not be a common migration pattern so I'm okay with the current documentation.

If you think it's worth revising to clarify the dependency, you might do something like:

There are some other environment variables which can be set to modify Logger's settings at a global scope. The POWERTOOLS_SERVICE_NAME environment variable is shared with other features and adds a default service dimension to Metrics.

[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.