getsentry/sentry-elixir

Bad software is everywhere, and we're tired of it. Sentry is on a mission to help developers write better software faster, so we can get back to enjoying technology. If you want to join us Check out our open positions

This is the official Sentry SDK for Sentry.

💁: This README documents unreleased features (from the master branch). For documentation on the current release, see the official documentation.

To use Sentry in your project, add it as a dependency in your mix.exs file. Sentry does not install a JSON library nor HTTP client by itself. Sentry will default to trying to use Jason for JSON serialization and Hackney for HTTP requests, but can be configured to use other ones. To use the default ones, do:

defp deps do
  [
    # ...

    {:sentry, "~> 10.0"},
    {:jason, "~> 1.4"},
    {:hackney, "~> 1.19"}
  ]
end

Sentry has a range of configuration options, but most applications will have a configuration that looks like the following:

# config/config.exs
config :sentry,
  dsn: "https://[email protected]/1",
  environment_name: Mix.env(),
  enable_source_code_context: true,
  root_source_code_paths: [File.cwd!()]

This library comes with a :logger handler to capture error messages coming from process crashes. To enable this, add the handler when your application starts:

  def start(_type, _args) do
+   :logger.add_handler(:sentry_handler, Sentry.LoggerHandler, %{})

    # ...
  end

The handler can also be configured to capture Logger metadata. See the documentation here.

Sometimes you want to capture specific exceptions manually. To do so, use Sentry.capture_exception/2.

try do
  ThisWillError.really()
rescue
  my_exception ->
    Sentry.capture_exception(my_exception, stacktrace: __STACKTRACE__)
end

Sometimes you want to capture messages that are not exceptions. To do that, use Sentry.capture_message/2:

Sentry.capture_message("custom_event_name", extra: %{extra: information})

To learn more about how to use this SDK, refer to the documentation.

To ensure you've set up your configuration correctly we recommend running the included Mix task. It can be tested on different Mix environments and will tell you if it is not currently configured to send events in that environment:

MIX_ENV=dev mix sentry.send_test_event

In some cases, you may want to test that certain actions in your application cause a report to be sent to Sentry. Sentry itself does this by using Bypass. It is important to note that when modifying the environment configuration the test case should not be run asynchronously, since you are modifying global configuration. Not returning the environment configuration to its original state could also affect other tests depending on how the Sentry configuration interacts with them. A good way to make sure to revert the environment is to use the on_exit/2 callback that ships with ExUnit.

For example:

test "add/2 does not raise but sends an event to Sentry when given bad input" do
  bypass = Bypass.open()

  Bypass.expect(bypass, fn conn ->
    assert {:ok, _body, conn} = Plug.Conn.read_body(conn)
    Plug.Conn.resp(conn, 200, ~s<{"id": "340"}>)
  end)

  Sentry.put_config(:dsn, "http://public:secret@localhost:#{bypass.port}/1")
  Sentry.put_config(:send_result, :sync)

  on_exit(fn ->
    Sentry.put_config(:dsn, nil)
    Sentry.put_config(:send_result, :none)
  end)

  MyModule.add(1, "a")
end

When testing, you will also want to set the :send_result type to :sync, so that sending Sentry events blocks until the event is sent.

• Phoenix and Plug

Please refer to CONTRIBUTING.md.

If you need help setting up or configuring the Python SDK (or anything else in the Sentry universe) please head over to the Sentry Community on Discord. There is a ton of great people in our Discord community ready to help you!

Licensed under the MIT license, see LICENSE.