-
-
Notifications
You must be signed in to change notification settings - Fork 108
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
Include event and handler name as tags with handle_in metrics #187
Conversation
} | ||
end, | ||
tags: [:endpoint], | ||
tags: [:endpoint, :handler, :event], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I noticed the phoenix tests only check for event counts and not the tag values, so this is a bit hard to test without editing a decent chunk of code. I could add additional test coverage there for this whole module in a follow-up PR if that would be preferred!
lib/prom_ex/plugins/phoenix.ex
Outdated
%{ | ||
endpoint: normalize_module_name(endpoint) | ||
endpoint: normalize_module_name(endpoint), | ||
event: event, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall this looks good to me. The only part that gives me pause is the event
since it is a binary and has the potential to be an unbounded value. I think it would be best if this module accepts an option to normalize event values. The default implementation would be a passthrough:
fn event ->
event
end
But then the user could override this to do something like so:
fn
"join" -> "join"
"leave" -> "leave"
_ -> "unknown"
end
Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @akoutmos good idea and I can implement it like you've described. Just might be a little slow due to the holiday season!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No worries at all my friend! Happy holidays!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've updated the PR with support for a normalizer function. I also added some new tests- one to test for handled_in
metrics generally which I noticed were missing and another to test that configuring the normalize_event_names
option works as expected.
To verify this works in a Phoenix app, I've pushed up this branch to one of Felt's preview instances. Here's some of the metrics emitted-
Looks like things are working as expected! |
Hey @akoutmos, now that the holidays are over just wanted to poke for another review on this PR. |
It looks like there are some test failures. Could you address those? |
@akoutmos the tests should be fixed now. They were failing in different test files because I've added 2 additional test events for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Thanks for the contribution!! |
Change description
Adds the event name that is present from the
channel_handled_in
telemetry payload as a tag for the duration metric.I also noticed that
:handler
was included in thetags
field, but wasn't actually set undertag_values
. Maybe this was a bug? I added it as a tag value as well.There's a lot of value including this tag with duration metrics. Right now, if a specific event handler function is slow, there's no way to identify that with without the
event
dimension. With it added, it's now possible to group by events and monitor for slow handlers.Example usage
Nothing really required from the user's side to set this up, they'll just need to update their PromEx version.
channel_handled_in_duration_milliseconds
metrics will now include theevent
andhandler
tags. Example output:Checklist