Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide Default Values for .add_metric(unit=) and .add_metric(value=) #1180

Closed
ghost opened this issue Sep 21, 2021 · 6 comments
Closed

Provide Default Values for .add_metric(unit=) and .add_metric(value=) #1180

ghost opened this issue Sep 21, 2021 · 6 comments
Labels
breaking-change Breaking change feature-request feature request help wanted Could use a second pair of eyes/hands metrics

Comments

@ghost
Copy link

ghost commented Sep 21, 2021

Is your feature request related to a problem? Please describe.
Approximately 2/3rd of my metrics are just posting singletons to a given metric, where unit=MetricUnit.Count and value=1. This results in repeating myself frequently.

Describe the solution you'd like
Provide default values for unit and value, such that I can .add_metric() by providing just a name= value.

Describe alternatives you've considered
A wrapper function that provides the same functionality might also be useful, but this seems like overkill compared to providing default values.

Additional context
This is the first time I've opened a Feature Request on a public repo... did I provide enough detail? :-)

@boring-cyborg
Copy link

boring-cyborg bot commented Sep 21, 2021

Thanks for opening your first issue here! We'll come back to you as soon as we can.

@heitorlessa
Copy link
Contributor

Hey @nsandar That's a great idea for unit, not for value as this can trip people both when reading the code later and on testing. As for the details, they are super crispy, so thank you for a high quality request ;)

This could be similar to how we've done default dimensions.

I'm currently out of bandwidth to implement it until other higher priorities enhancements are done - I can however provide guidance to contribute it if you could help.

We'd need a couple of things to implement this:

  • A new public method set_default_metric_unit(self, value: str): ...
  • A new public method clear_default_metric_unit
  • Update clear_metrics method to include set_default_metric_unit with previously used value. This is used by customers in unit testing so their defaults are always re-added and metrics cleared for each test

@florian42
Copy link

Hey, @heitorlessa, I would like to contribute a pr for this.
But I have trouble with persisting the default metric unit between instances.
My idea is to make the changes in metrics.py, mainly by adding the following instance variable _default_metric_unit: Optional[Union[MetricUnit, str]] = None and then overriding the add_metric method from the parent class, for example:

# metrics.py

def add_metric(self, name: str, value: float, unit: Optional[Union[MetricUnit, str]] = None) -> None:
    if unit is None and self.default_metric_unit is None:
        raise MetricUnitError("specify a unit")
    super().add_metric(name=name, value=value, unit=unit)

Note that this also means that unit and value have switched positions - maybe that is even a breaking change (in case I rely on positional arguments)?

@heitorlessa
Copy link
Contributor

Hey @florian42 thanks a lot for the help. We're going through a big feature now (Event Handler route splitting) and I can have a look at this with you later this week.

On the positioning, yep, a mistake I've made early was not enforcing kwarg only *, name: str.... Need to think more carefully about this.

@heitorlessa heitorlessa transferred this issue from aws-powertools/powertools-lambda-python Nov 13, 2021
@heitorlessa heitorlessa transferred this issue from aws-powertools/powertools-lambda Apr 28, 2022
@heitorlessa heitorlessa added help wanted Could use a second pair of eyes/hands area/metrics and removed Proposed labels May 20, 2022
@heitorlessa heitorlessa added the feature-request feature request label Jun 13, 2022
@heitorlessa heitorlessa added the breaking-change Breaking change label Aug 18, 2022
@heitorlessa
Copy link
Contributor

We're closing feature requests older than a year that haven't received enough customers +1 or that we were unable to prioritize. For newer customers interested in, please feel free to comment and we can reopen it.

@heitorlessa heitorlessa closed this as not planned Won't fix, can't repro, duplicate, stale Jul 19, 2023
@github-actions
Copy link
Contributor

⚠️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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking-change Breaking change feature-request feature request help wanted Could use a second pair of eyes/hands metrics
Projects
Status: Shipped
Development

No branches or pull requests

2 participants