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

additional labels for http metrics #231

Open
NimrodAvni78 opened this issue Jul 24, 2023 · 3 comments
Open

additional labels for http metrics #231

NimrodAvni78 opened this issue Jul 24, 2023 · 3 comments
Assignees
Labels
enhancement New feature or request

Comments

@NimrodAvni78
Copy link

Is your feature request related to a problem? Please describe.

i would like to have some additional labels for the http metrics http_server_duration_average_us_total and http_server_client_average_us_total
these include: http_verb, status code http_route
for route, i think we can try to infer the route template to not pollute with to many labels
i.e if we see /api/v1/customers/1 + /api/v1/customers/2 + /api/v1/customers/3 we can infer the route to be /api/v1/customers/$id or something like that, we can think of a logic to try to infer that

Describe the solution you'd like

change the ebpf probes to extract method, status code and route from the http request, and add it as labels to the existing metrics

Describe alternatives you've considered

No response

Additional context

No response

@NimrodAvni78 NimrodAvni78 added the enhancement New feature or request label Jul 24, 2023
@NimrodAvni78
Copy link
Author

btw i would like to work on this. so you can assign me to it
if you have any feedback on how it should be implemented ill like to hear :)

@atoulme
Copy link
Contributor

atoulme commented Jul 24, 2023

It's yours @NimrodAvni78 !

@yonch
Copy link
Contributor

yonch commented Jul 25, 2023

Awesome @NimrodAvni78 ! It will be a good capability to add!

I’d really love to see a design that would preserve the current system’s O(1) cost of handling each incoming event, because this property has been extremely useful in providing predictable performance for users.

My intuition is this is achievable, e.g., decide to handle at most N path components (say N=5) and use a hash table to keep collected metrics and which templates have been inferred. If inference logic can work “on-line” (i.e., logic can find templates as samples are coming in one at a time, without batch-processing) and is O(1) for that inference, that means inference and collection are both O(1).

The framework offers hash tables and infra to output metrics for items stored in those hash tables (which all current metrics use).

For transparency I’m unavailable to have a discussion about this in the next few weeks (I’m on leave). Happy to discuss in September if you haven’t finished this already :)

Excited to see where you take this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants