Replacing Phoenix.Instrumenter with Telemetry events in AppSignal's Phoenix integration

Phoenix Forum Questions / Help
, ,
1

Hey all!

I’m Jeff, from AppSignal. I’ve been working on getting our integration ready for the deprecation of Phoenix.Instrumenter in the upcoming version of Phoenix, and I could use some guidance.

Currently, we Phoenix.Instrumenter to hook into the phoenix_controller_call events to track events as they happened. Now, with the newly emitted Telemetry events, we’re moving that logic over to a new event handler that hooks into the [:phoenix, :endpoint, :start] and [:phoenix, :endpoint, :stop] events, which has been working great for our purposes.

However, we’re having some trouble getting the controller and action names out of the conn in the new events. Since the old phoenix_controller_call events were called later in the request, the pipeline was already called, meaning the :phoenix_controller and :phoenix_action` were already set in the conn. Since the Telemetry events are called right before the pipeline is started, we can’t set the controller and action names before the controller action is called. We’ve moved the logic to set the controller and action names to a before_send callback.

Again, this works. However, when an error happens that prevents the before_send callback from being called (like an unhandled exit or a timeout), we can’t determine in which controller action that error happened. We’re trying to figure out if there’s a way around that, or if this is intended behaviour.

We were excited to see this proposal to add controller events last year, which would allow us to revert to setting the action names before the action is called, but it seems like this was replaced with the endpoint events that are in master now. Are there any plans to bring something like this back?

In short; we’re able to instrument endpoint calls on Phoenix 1.5 currently, but we can’t match exits to their controller and action names, causing them to be reported as “outside of an action” in AppSignal. Would that be expected behaviour (since they’re process exits), or would there be a way around that? Any input would be greatly appreciated!

Thanks,
— Jeff

1 Like
2

TL;DR - if plug+plug_opts metadata are both atoms, you have controller+action, otherwise log only the plug.

Hi Jeff!

We moved it to the router so we instrument more cases. Previously, plugs were rarely instrumented. So in this case, the controller+action were replaced by plug+plug_opts metadata. What we do is that, if plug and plug_opts are both atoms, then we can assume they are a controller+action.

You can see what we do here:

I hope this helps!

1 Like
3

Hey @josevalim! That certainly helps. Knowing I can trust the plug and plug_opts from the metadata will allow us to revert back to setting the controller and action names before the pipeline is called, thus catching those errors again.

Thanks a lot! :slight_smile:

1 Like