sentry v2.0.0 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
Parses and submits an exception to Sentry if current environment is in included_environments
Sends a Sentry.Event
Called when an application is started
Functions
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(%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
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 nodenode
.{:failover, node}
- used if the application is distributed and is started on the current node because of a failover on nodenode
, 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
.