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 😋 🍪