crbelaus
commented
2 months ago Hey @mrdotb, thanks for your thoughtful message.
In my experience both AppSignal and Sentry logger handlers do not capture enough helpful information in many cases. I've frequently seen vague messages about a particular process dying but no useful information that allows me to find where the problem originates or what is causing it.
That is aligned with their business model. Since they charge money for the number of registered errors, it is in their best interest to track as many events as possible (with or without useful information).
All this is to say that the logger handler is definitely on the roadmap but we are still working on it. We need to balance providing useful information, being good citizens on the database and handling idempotency considerations.
Regarding the Discord integration: someone is already working on a similar package but targeted to Telegram (error_tracker_telegram). The idea is that the package will attach to the ErrorTracker telemetry events and send the relevant information to the Telegram API.
Just mentioning it in case it is useful, as having a Discord integration package would be amazing.
Hello,
I’ve been working on a project called DiscoLog, which is using error-tracker as a starting but uses Discord Api for storing errors. I’ve borrowed heavily from error-tracker and added some additional functionality.
While working with the error-tracker codebase, I identified a missing feature—a logger handler. I created one based on the sentry-elixir logger handler. By using a logger, it’s possible to catch and convert all exceptions into error occurrences (e.g., GenServer exits or crashes). Essentially, any exception passed to
Logger.errorcan now be recorded as an occurrence.However, this introduced a new challenge: if an error is already reported by a specific integration (like Oban, Phoenix, etc.), there needs to be a mechanism to prevent duplicate reports. To address this, I used the same way they solve the issue in elixir-sentry with an error hash and a temporary storage mechanism.
I would love to contribute this logger handler back to the error-tracker project, but since it’s a big feature, I wanted to check with you first to see if there’s interest in adding it.