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
andTower.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:
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
withtower_honeybadger
in your dependencies. - Replace
config :tower, reporters: [TowerSentry]
withconfig :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]
toconfig :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!