sentry

v2.0.1

sentry v2.0.1 Sentry

Provides the basic functionality to submit a Sentry.Event to the Sentry Service.

Configuration

Add the following to your production config

config :sentry, dsn: "https://public:secret@app.getsentry.com/1"
  included_environments: [:prod],
  environment_name: :prod,
  tags: %{
    env: "production"
  }

The environment_name and included_environments work together to determine if and when Sentry should record exceptions. The environment_name is the name of the current environment. In the example above, we have explicitly set the environment to :prod which works well if you are inside an environment specific configuration config/prod.exs.

An alternative is to use Mix.env in your general configuration file:

config :sentry, dsn: "https://public:secret@app.getsentry.com/1"
  included_environments: [:prod],
  environment_name: Mix.env

This will set the environment name to whatever the current Mix environment atom is, but it will only send events if the current environment is :prod, since that is the only entry in the included_environments key.

You can even rely on more custom determinations of the environment name. It’s not uncommmon for most applications to have a “staging” environment. In order to handle this without adding an additional Mix environment, you can set an environment variable that determines the release level.

config :sentry, dsn: "https://public:secret@app.getsentry.com/1"
  included_environments: ~w(production staging),
  environment_name: System.get_env("RELEASE_LEVEL") || "development"

In this example, we are getting the environment name from the RELEASE_LEVEL environment variable. If that variable does not exist, we default to "development". Now, on our servers, we can set the environment variable appropriately. On our local development machines, exceptions will never be sent, because the default value is not in the list of included_environments.

Capturing Exceptions

Simply calling capture_exception2 will send the event.

Sentry.capture_exception(my_exception)

Configuring The Logger Backend

See Sentry.Logger

Summary

Functions

capture_exception(exception, opts \\ [])

Parses and submits an exception to Sentry if current environment is in included_environments

send_event(event)

Sends a Sentry.Event

start(type, opts)

Called when an application is started

Functions

capture_exception(exception, opts \\ []) 
capture_exception(Exception.t, Keyword.t) ::
  {:ok, String.t} |
  :error

Parses and submits an exception to Sentry if current environment is in included_environments.

send_event(event) 
send_event(%Sentry.Event{breadcrumbs: term, culprit: term, environment: term, event_id: term, exception: term, extra: term, level: term, message: term, platform: term, release: term, request: term, server_name: term, stacktrace: term, tags: term, timestamp: term, user: term}) ::
  {:ok, String.t} |
  :error

Sends a Sentry.Event

start(type, opts)

Called when an application is started.

This function is called when an the 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 mode 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 stop/2 callback for more information).

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

Callback implementation for Application.start/2.