Timber v1.1.10 API Reference
Modules
The functions in this module work by modifying the Logger metadata store which is unique to every BEAM process. This is convenient in many ways. First and foremost, it does not require you to manually manage the metadata. Second, because we conform to the standard Logger principles, you can utilize Timber alongside other Logger backends without issue. Timber prefixes its contextual metadata keys so as not to interfere with other systems
The ContextEntry module formalizes the structure of context stack entries
The CustomContext
allows you to track contextual information relevant to your
system that is not one of the commonly supported contexts for Timber (Timber.Contexts.*
)
The HTTP context tracks information about an HTTP request currently being handled
The organization context tracks the organization of the currently authenticated user
The Runtime context tracks information about the current runtime, such as the module, file, function, and line number that called the log line
Tracks system information such as the current Process ID (pid)
The User context tracks the currently authenticated user
A common interface for working with structures in the Timber.Events
namespace
The ControllerCallEvent
represents a controller being called during the HTTP request
cycle
The CustomEvent
represents events that aren’t covered elsewhere
The ExceptionEvent
is used to track exceptions
The HTTPClientRequestEvent
tracks outgoing HTTP requests giving you structured insight
into communication with external services
The HTTPClientResponseEvent
tracks responses for outgoing HTTP requests. This gives you
structured insight into communication with external services
The HTTPServerRequestEvent
tracks incoming HTTP requests. This gives you structured
insight into the HTTP requests coming into your app
The HTTPServerResponseEvent
tracks responses for incoming HTTP requests. In other words,
the resposnes you are sending back to your clients. This gives you structured insight into
the response you are sending back to your clients
The SQLQueryEvent
tracks outgoing SQL queries. This gives you structured insight into
SQL query performance within your application
The TemplateRenderEvent
trackes template rendering within your app. Giving you structured
insight into template rendering performance
Automatically captures the HTTP request ID in Plug-based frameworks like Phoenix and adds it to the context
Timber integration for Ecto
Automatically logs metadata information about HTTP requests and responses in Plug-based frameworks like Phoenix
Handles instrumentation of Phoenix.Endpoint
The LogEntry module formalizes the structure of every log entry
The LoggerBackend module is at the heart of Timber’s integration. It specifies
a backend that can be used with the standard Logger
application distributed
with Elixir
A Transport specifies the way in which Timber.LoggerBackend
should actually output
log events
An efficient HTTP transport that buffers and delivers log messages over HTTP to the Timber API. It uses batching, keep-alive connections, and msgpack to deliver logs with high-throughput and little overhead
Behavior for custom HTTP clients. If you opt not to use the default Timber HTTP client
(Timber.Transports.HTTP.HackneyClient
) you can define your own here
An efficient HTTP client that leverages hackney, keep alive connections, and connection pools to communicate with the Timber API
The IODevice transport mechanism allows you to log directly to
stdout
(default; see below) or any other IODevice of your choice
Exceptions
Error raised when the device being sought is non-existent or otherwise cannot be found or used
Protocols
Converts a data structure into a Timber.Context.t
. This is called on any data structure passed
in the Timber.add_context/1
function
Converts a data structure into a Timber.Event.t
. This is called on any data structure passed
in the :event
metadata key passed to Logger