appsignal
AppSignal for Phoenix Version 2.2.0 Supports Phoenix 1.7
Connor James and Jeff Kreeftmeijer on
Changes in the upcoming Phoenix 1.7 release have led us to re-think how AppSignal for Phoenix works. AppSignal for Phoenix version 2.2.0 introduces our changes to make upgrading to Phoenix 1.7 easier. In this blog post, we'll outline what's changed and why.
How AppSignal Used Views to Gather Insights
In previous versions of our integration, we used a module named Appsignal.Phoenix.View
for Phoenix application views:
defmodule AppsignalPhoenixExampleWeb do # ... def view do quote do use Phoenix.View, root: "lib/appsignal_phoenix_example_web/templates", namespace: AppsignalPhoenixExampleWeb use Appsignal.Phoenix.View # Import convenience functions from controllers import Phoenix.Controller, only: [get_flash: 1, get_flash: 2, view_module: 1] # Include shared imports and aliases for views unquote(view_helpers()) end end # ... end
Our Appsignal.Phoenix.View
module hooked itself into each view by wrapping the render/2
function. Whenever that function was called in any of an application's views, an AppSignal span was created before it was called, and closed before it returned.
Since 2020, this allowed AppSignal to gain insights about templates being rendered, including layouts and partials. Before that, AppSignal used template engines to do the same thing.
:telemetry
When we released the first versions of our Elixir integration in 2017, there wasn’t a unified way to add telemetry to Elixir applications. Phoenix had its own "instrumenters" logic the AppSignal integration hooked into.
The :telemetry
project started in 2018 with telemetry events introduced in Phoenix 1.5, removing the instrumenters. AppSignal for Phoenix 2.0 also adopted :telemetry
for Phoenix events, but the old way of instrumenting templates remained, with users still having to add AppSignal.Phoenix.View
to their application's views.
Phoenix 1.7
Phoenix 1.7 removed the view
function in application web modules in favor of an HTML one using Phoenix.Component
instead of Phoenix.View. This change meant our Appsignal.Phoenix.View
module could no longer hook into the render/2
function, so we needed to find a new way to collect telemetry data.
As AppSignal is committed to OpenTelemetry, we decided rather than create our own workaround, it would be more beneficial if we added a :telemetry
instrumentation to Phoenix ourselves. This
allows AppSignal as well as other APMs and OpenTelemetry to hook into those events too.
In Phoenix 1.7, a [:phoenix, :controller, :render, :start]
and [:phoenix, :controller, :render, :stop]
event will now be emitted whenever a template is rendered.
Note: At the time of publication (06/12/22), Phoenix 1.7 is currently unreleased.
AppSignal for Phoenix 2.2.0
To use :telemetry
in your AppSignal for Phoenix integration, upgrade to AppSignal for Phoenix 2.2.0:
# mix.exs defmodule AppsignalPhoenixExample.MixProject do # ... defp deps do [ {:phoenix, "~> 1.5.3"}, {:appsignal_phoenix, "~> 2.2.0"} # ... ] end end
Then install Phoenix edge:
$ mix archive.uninstall phx_new $ mix archive.install hex phx_new https://github.com/phoenixframework/phoenix
Once completed, your AppSignal integration will now support these newly added events, making your application's eventual update to Phoenix 1.7 one step faster.
Need Help, or Hungry for Stroopwafels?
If you've got any questions about how AppSignal works for Phoenix or any of our other integrations, or you'd like to see something not already available on AppSignal, please do get in touch with us, we'd love to hear what you have to say! We provide developer-to-developer support and ship stroopwafels to trial users on request 😋 🍪