Timber v2.5.4 Timber.Integrations.PhoenixInstrumenter View Source
Handles instrumentation of Phoenix.Endpoint
.
This module is designed to log events when Phoenix calls a controller or renders a template. It hooks into the instrumentation tools built into Phoenix. Because of this, you will have to trigger a Phoenix recompile in order for the instrumentation to take effect.
Adding Instrumentation
Phoenix instrumenetation is controlled through the configuration for your
Phoenix endpoint module, typically named along the lines of MyApp.Endpoint
.
This module will be configured in config/config.exs
similar to the following:
config :my_app, MyApp.Endpoint,
http: [port: 4001],
root: Path.dirname(__DIR__),
pubsub: [name: MyApp.PubSub,
adapter: Phoenix.PubSub.PG2]
You will need to add an :instrumenters
key to this configuration with
a value of [Timber.Integrations.PhoenixInstrumenter]
. This would update the configuration
to something like the following:
config :my_app, MyApp.Endpoint,
http: [port: 4001],
root: Path.dirname(__DIR__),
instrumenters: [Timber.Integrations.PhoenixInstrumenter],
pubsub: [name: MyApp.PubSub,
adapter: Phoenix.PubSub.PG2]
In order for this to take affect locally, you will need to recompile Phoenix using
the command mix deps.compile phoenix
. By default, Timber will log calls to controllers
and template renders at the :info
level. You can change this by adding an additional
configuration line:
config :timber, :instrumentation_level, :debug
If you’re currently displaying logs at the :debug
level, you will also see that
Phoenix has built-in logging already at this level. The Phoenix logger will not emit
Timber events, so you can turn it off to stop the duplicate output. The Phoenix logger
is controlled through the MyApp.Web
module. Look for a definition block like the
following:
def controller do
quote do
use Phoenix.Controller
end
end
You will want to modify this to the following
def controller do
quote do
use Phoenix.Controller, log: false
end
end
Ignoring Controller Actions for Instrumentation
If you have specific controller actions that you don’t want to be instrumented, you can add them to the instrumentation blacklist. For example, if your application provides a health controller for external applications, you may want to stop instrumentation on that controller’s actions to reduce noise.
The :controller_actions_blacklist
configuration key can be used to control which
controller actions to suppress instrumentation for. It takes a list of two-element
tuples. The first element is the controller name, and the second element is the
action.
As an example, here’s how we would prevent instrumentation of the check
action in
TimberClientAPI.HealthController
:
config :timber, Timber.Integrations.PhoenixInstrumenter,
controller_actions_blacklist: [
{TimberClientAPI.HealthController, :check}
]
Now, when Phoenix calls check/2
on the TimberClientAPI.HealthController
module,
no log lines will be produced!
Link to this section Summary
Link to this section Functions
add_controller_action_to_blacklist(controller, action) :: :ok
Adds a controller action to the blacklist
This function will update the blacklist of controller actions, following the same conventions as the blacklist described in the application configuration.
The controller
should be the qualified name of the Phoenix controller’s
Elixir module (e.g., TimberClientAPI.OrganizationController
).
The action
should be the name of the action (e.g., index
).
remove_controller_action_from_blacklist(controller, action) :: :ok
Removes controller action from the blacklist
This function will update the blacklist of controller actions, following the same conventions as the blacklist described in the application configuration.
The controller
should be the qualified name of the Phoenix controller’s
Elixir module (e.g., TimberClientAPI.OrganizationController
).
The action
should be the name of the action (e.g., index
).