Packages
timber
2.8.1
3.1.2
3.1.1
3.1.0
3.0.0
3.0.0-alpha.3
3.0.0-alpha.2
3.0.0-alpha.1
2.8.4
2.8.3
2.8.2
2.8.1
2.8.0
2.7.0
2.6.1
2.6.0
2.5.6
2.5.5
2.5.4
2.5.3
2.5.2
2.5.1
2.5.0
2.4.5
2.4.4
2.4.3
2.4.2
2.4.1
2.4.0
2.3.4
2.3.3
2.3.1
2.3.0
2.2.1
2.2.0
2.1.8
2.1.7
2.1.6
2.1.5
2.1.4
2.1.3
2.1.2
2.1.1
2.1.0
2.0.2
2.0.1
2.0.0
2.0.0-rc7
2.0.0-rc6
2.0.0-rc5
2.0.0-rc4
2.0.0-rc3
2.0.0-rc2
2.0.0-rc1
1.1.18
1.1.17
1.1.16
1.1.15
1.1.14
1.1.13
1.1.12
1.1.11
1.1.10
1.1.9
1.1.8
1.1.7
1.1.6
1.1.5
1.1.4
1.1.3
1.1.2
1.1.1
1.1.0
1.0.16
1.0.15
1.0.14
1.0.13
1.0.12
1.0.11
1.0.10
1.0.9
1.0.8
1.0.7
1.0.6
1.0.5
1.0.4
1.0.3
1.0.2
1.0.1
1.0.0
0.4.7
0.4.6
0.4.5
0.4.4
0.4.3
0.4.2
0.4.1
0.4.0
0.3.2
0.3.1
0.3.0
0.2.3
0.2.2
0.2.1
0.2.0
0.1.5
0.1.4
0.1.3
0.1.2
0.1.1
0.1.0
🌲 Great Elixir Logging Made Easy. Official Timber.io Integration.
Current section
Files
Jump to
Current section
Files
lib/timber/integrations/http_context_plug.ex
defmodule Timber.Integrations.HTTPContextPlug do
@moduledoc """
Automatically captures the HTTP method, path, and request_id in Plug-based frameworks
like Phoenix and adds it to the context.
By adding this data to the context, you'll be able to associate
all the log statements that occur while processing that HTTP request.
## Adding the Plug
`Timber.Integrations.HTTPContextPlug` 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 Timber.Integrations.HTTPContextPlug` should be grouped with
any other plugs you call prior to performing business logic.
Timber expects query parameters 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.Integrations.HTTPContextPlug` can be inserted. The recommended place is in
`endpoint.ex`. Make sure that you insert this plug immediately before your `Router` plug.
## Request ID
Timber does its best to track the request ID for every HTTP request in order to help you
filter your logs easily. If you are calling the `Plug.RequestId` plug in your pipeline,
you should make sure that `Timber.Integrations.HTTPContextPlug` 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"
```
"""
alias Timber.Contexts.HTTPContext
alias Timber.Utils.Plug, as: PlugUtils
@doc """
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`.
"""
@spec init(Plug.opts()) :: Plug.opts()
def init(opts) do
opts
end
@doc """
Adds the Request ID to the Timber context data
"""
@spec call(Plug.Conn.t(), Plug.opts()) :: Plug.Conn.t()
def call(%{method: method, request_path: request_path} = conn, opts) do
request_id_header = Keyword.get(opts, :request_id_header, "x-request-id")
remote_addr = PlugUtils.get_client_ip(conn)
request_id =
case PlugUtils.get_request_id(conn, request_id_header) do
[{_, request_id}] -> request_id
[] -> nil
end
%HTTPContext{
method: method,
path: request_path,
request_id: request_id,
remote_addr: remote_addr
}
|> Timber.add_context()
conn
end
end