Timber v3.0.0-alpha.2 Timber.LoggerBackends.HTTP View Source

Provides a logger backend that dispatches logs via HTTP

The HTTP backend buffers and delivers log messages over HTTP to the Timber API. It uses batching and msgpack to deliver logs with high-throughput and little overhead.

Note: We use this transport strategy internally at Timber for our log ingestion pipeline; generating ~250 logs per second with virtually no change in performance. For the curious, we log metrics, and this is how we are able to optimize our pipeline.

Messages are always written to the buffer first. The buffer is only drained when it reaches its maximum allowed size or a specified amount of time has elapsed. This balances output with batching so that logs are sent even when the application doesn’t produce enough logs to fill the buffer.

The maximum allowed size of the buffer can be controlled with the :max_buffer_size configuration value.

All outgoing requests are made asynchronously. If a second request is made while the previous (first) request is still being processed, then the transport will enter synchronous mode, waiting for a response before proceeding with the request. Synchronous mode will cause any logging calls to block until the request completes.

Link to this section Summary

Types

The level of a log event is described as an atom

The message for a log event is given as IO.chardata. It is important not to assume the message will be a String.t/0

The precision of the microsecond represents the precision with which the fractional seconds are kept

t()

A representation of stateful data for this module

Time is represented both to the millisecond and to the microsecond with precision

Functions

Callback implementation for c::gen_event.code_change/3

Callback implementation for c::gen_event.terminate/2

Link to this section Types

Link to this type buffer() View Source
buffer() :: [] | [Timber.LogEntry.t()]
Link to this type hour() View Source
hour() :: 0..23
Link to this type http_client() View Source
http_client() :: module() | nil

The level of a log event is described as an atom

The message for a log event is given as IO.chardata. It is important not to assume the message will be a String.t/0

Link to this type microsecond() View Source
microsecond() :: 0..999_999
Link to this type millisecond() View Source
millisecond() :: 0..999
Link to this type minute() View Source
minute() :: 0..59
Link to this type month() View Source
month() :: 1..12
Link to this type precision() View Source
precision() :: 0..6

The precision of the microsecond represents the precision with which the fractional seconds are kept.

See Calendar.microsecond/0 for more information.

Link to this type second() View Source
second() :: 0..59
Link to this type t() View Source
t() :: %Timber.LoggerBackends.HTTP{
  api_key: String.t() | nil,
  buffer: buffer(),
  buffer_size: non_neg_integer(),
  flush_interval: non_neg_integer(),
  http_client: http_client(),
  max_buffer_size: pos_integer(),
  min_level: level() | nil,
  ref: reference() | nil
}

A representation of stateful data for this module

min_level

The minimum level to be logged. The Elixir Logger module typically handle filtering the log level, however this is a stop-gap for direct testing as well as any custom levels.

Time is represented both to the millisecond and to the microsecond with precision.

Link to this type timestamp() View Source
timestamp() :: {date(), time()}

Link to this section Functions

Link to this function code_change(old, state, extra) View Source

Callback implementation for c::gen_event.code_change/3.

Link to this function terminate(reason, state) View Source

Callback implementation for c::gen_event.terminate/2.