Timber v0.1.5 Timber.Plug
Automatically captures context information about HTTP requests and responses in Plug-based frameworks like Phoenix.
Whether you use Plug by itself or as part of a framework like Phoenix, adding this plug to your pipeline will automatically add context information about HTTP requests and responses to your log statements.
Adding the Plug
Timber.Plug
can be added to your plug pipeline using the standard
Plug.Builder.plug/2
macro. The point at which you place it determines
what state Timber will receive the connection in, therefore it’s
recommended you place it as close to the origin of the request as
possible.
Plug (Standalone or Plug.Router)
If you are using Plug without a framework, your setup will vary depending
on your architecture. The call to plug Plug.Timber
should be grouped
with any other plugs you call prior to performing business logic.
Timber expects query paramters to have already been fetched on the
connection using Plug.Conn.fetch_query_params/2
.
Phoenix
Phoenix’s flexibility means there are multiple points in the plug pipeline
where the Timber.Plug
can be inserted. The recommended place is in
a :logging
pipeline in your router, but if you have more complex needs
you can also place the plug in an endpoint or a controller.
defmodule MyApp.Router do
use MyApp.Web, :router
pipeline :logging do
plug Timber.Plug
end
scope "/api", MyApp do
pipe_through :logging
end
end
If you place the plug call in your endpoint, you will need to make sure
that it appears after Plug.RequestId
(if you are using it) but before
the call to your router.
Request ID
Timber does its best to track the request ID for every HTTP request
in order to help you filter your logs responsibly. If you are calling
the Plug.RequestId
plug in your pipeline, you should make sure
that Timber.Plug
appears after that plug so that it can pick
up the correct ID.
By default, Timber expects your request ID to be stored using the header name “X-Request-ID” (casing irrelevant), but that may not fit all needs. If you use a custom header name for your request ID, you can pass that name as an option to the plug:
plug Timber.Plug, request_id_header: "req-id"
Issues with Plug.ErrorHandler
If you are using Plug.ErrorHandler
, you will lose any context regarding
the response if an exception is raised. This is because of how the error
handler works in practice. In order to capture information about the
response, Timber registers a callback to be used before Plug actually
sends the response. Plug stores this context information on the
connection struct. When an exception is raised, the methodology used
by the error handler will reset the conn to the state it was first
accepted. This means the conn loses any changes made to it by your
plug pipeline, including the callback Timber registered.
Summary
Functions
Adds contextual data about the request and response for this conn
to
Timber’s context stack
Prepares the given options for use in a plug pipeline
Functions
Adds contextual data about the request and response for this conn
to
Timber’s context stack
When this plug is called, information about the request is immediately added to the stack.
Prepares the given options for use in a plug pipeline
When the Plug.Builder.plug/2
macro is called, it will use this
function to prepare options. Any resulting options will be
passed on to the plug on every call. The options accepted
by this function are the same as defined by call/2
.