Tapper v0.6.0 Tapper.Application View Source

Tapper main application; configures and starts application supervisor.

Automatically started when Tapper is included as dependency.

Configuration

Looks for configuration under :tapper key:

key	type	purpose
`system_id`	`String.t`	This application's id; used for `service_name` in default `Endpoint` used in annotations; default `unknown`
`ip`	`tuple`	This application's principle IPV4 or IPV6 address, as 4- or 8-tuple of ints; defaults to IP of first non-loopback interface, or `{127.0.0.1}` if none.
`port`	`integer`	The application's principle port, e.g. HTTP port 80; defaults to 0

| reporter | atom | {atom, any} | function/1 | Module implementing Tapper.Reporter.Api ^[1], or function of arity 1 to use for reporting spans; defaults to Tapper.Reporter.Console. | | server_trace | atom | Logger level to log server traces at, or false (default false) |

All keys support the Phoenix-style {:system, var} format^[2], to allow lookup from shell environment variables, e.g. {:system, "PORT"} to read PORT environment variable.

Config values will be converted to the expected type, principally so that string values can be handled from environment variables:

ip is expected in dotted IPV4 or colon IPV6 notation, see Erlang's inet:parse_address/1
reporter can be specified as a string which will be converted to an atom, following Elixir's module name rules.

Example

In config.exs etc.:

config :tapper,
  system_id: "my-cool-svc",
  reporter: Tapper.Reporter.Zipkin,
  port: {:system, "PORT"}

^[1] If the reporter is given as {module, arg} it is expected to specify an OTP server to be started under Tapper's main supervisor.
^[2] Tapper uses the DeferredConfig library to resolve all configuration under the :tapper key, so see its documention for more options.

Link to this section Summary

Functions

start(type, args)

Called when an application is started

Link to this section Functions

start(type, args) View Source

Called when an application is started.

This function is called when an application is started using Application.start/2 (and functions on top of that, such as Application.ensure_started/2). This function should start the top-level process of the application (which should be the top supervisor of the application's supervision tree if the application follows the OTP design principles around supervision).

start_type defines how the application is started:

:normal - used if the startup is a normal startup or if the application is distributed and is started on the current node because of a failover from another node and the application specification key :start_phases is :undefined.
{:takeover, node} - used if the application is distributed and is started on the current node because of a failover on the node node.
{:failover, node} - used if the application is distributed and is started on the current node because of a failover on node node, and the application specification key :start_phases is not :undefined.

start_args are the arguments passed to the application in the :mod specification key (e.g., mod: {MyApp, [:my_args]}).

This function should either return {:ok, pid} or {:ok, pid, state} if startup is successful. pid should be the PID of the top supervisor. state can be an arbitrary term, and if omitted will default to []; if the application is later stopped, state is passed to the stop/1 callback (see the documentation for the c:stop/1 callback for more information).

use Application provides no default implementation for the start/2 callback.

Callback implementation for Application.start/2.