Tower is an Elixir library that provides a common interface for Error Tracking and Reporting, agnostic to which services or destinations you prefer to report to.

• Automatically listens for and reports un-handled exceptions occurring in any process.
• Provides small set of public functions for you to manually report any handled exception (Tower.report_exception and Tower.report_message, among a few more)
• Reports to one or many of your preferred services or destinations (separate package reporters/adapters) you configured with config :tower, reporters: [...].

Reporters/adapters currently supported:

• BugSnag
• Email
• ErrorTracker
• Honeybadger
• Rollbar
• Sentry
• Slack

Why?

• De-coupling of error capturing from error reporting.
• Be able to easily report to more than one place, either temporarily in case of transitioning from services, or for back-up reasons.
• Easier to switch or try out new services or destinations
• Having capturing logic implemented once may make it easier to respond to future changes in BEAM and Elixir, that benefit multiple reporter packages.

More at mimiquate/tower#Motivation.

Example Scenarios

Scenario #1

You want to report to Sentry.

• You include tower_sentry .
• Set a few Sentry-specific config setting.
• Set config :tower, reporters: [TowerSentry]

Automatic reporting of exceptions will “just work”.

Manually report by calling Tower.report_exception anywhere you like in your application code, like so:

  try do
    # possibly raising code
  rescue
    exception ->
      Tower.report_exception(exception, __STACKTRACE__)
  end

Scenario #2

You need/want to switch service from Sentry to Honeybadger.

• Replace tower_sentry with tower_honeybadger in your dependencies.
• Replace config :tower, reporters: [TowerSentry] with config :tower, reporters: [TowerHoneybadger]
• Remove Sentry-specific configs.
• Add Honeybadger-specific config, like setting API Key.
• Automatic reporting of exceptions continue to “just work” without any changes.
• Manual report calls to Tower.report_exception throughout your application code unchanged.

Scenario #3

You are reporting to Sentry and you want to test ErrorTracker while continuing to report to Sentry.

• Add tower_error_tracker.
• Follow a few ErrorTracker specific configs.
• Update config :tower, reporters: [TowerSentry] to config :tower, reporters: [TowerSentry, TowerErrorTracker] .
• Automatic reporting of exceptions continue to “just work” without any changes.
• Manual report calls to Tower.report_exception throughout your application code unchanged.
• Now you will have exceptions reported to both Sentry and ErrorTracker.

The Ephemeral Reporter

You can include the built-in Tower.EphemeralReporter in the reporters: config list. It will keep the last 50 heard exceptions stored in naive Agent state. Useful for testing, development, and occasional production debugging.

iex(1)> Tower.EphemeralReporter.events()
[]
iex(2)> Task.start(fn -> raise "exception within an async task" end)
{:ok, #PID<0.344.0>}

11:52:12.684 [error] Task #PID<0.344.0> started from #PID<0.343.0> terminating
** (RuntimeError) exception within an async task
    (elixir 1.17.3) src/elixir.erl:386: :elixir.eval_external_handler/3
Function: #Function<43.39164016/0 in :erl_eval.expr/6>
    Args: []
iex(3)> Tower.EphemeralReporter.events()
[
  %Tower.Event{
    id: "019290aa-4c2a-7853-85f9-e9171e16ef04",
    similarity_id: 9949489,
    datetime: ~U[2024-10-15 14:52:12.684704Z],
    level: :error,
    kind: :error,
    reason: %RuntimeError{message: "exception within an async task"},
    ...
  }
]

Support for more services?

We may write reporters for new services.

But we strongly encourage others to help and write and publish new reporters/adapters as you see fit and value.

Links

• GitHub: mimiquate/tower
• Hex.pm: tower
• Feature requests
• Bug reports

What’s next?

We plan to continue polishing, maturing and improving it. But we also need the community

Any feedback is in any form very much appreciated!
Please comment, use it, find and report bugs.
Ideas or feature requests are encouraged in the GitHub repo Discussions.

Thank you for taking the time to read!