Wow that’s amazing, thanks for putting it together!

Hi @MRdotB ,

This is great, thanks for sharing!

I wonder how easy an integration with tower can be so to have a tower_discord package in order to be able to report errors both to Discord and other places at the same time.

I’m not sure what value integrating with Tower brings. DiscoLog already has a logger handler, so after configuring the Logger backend, doing Logger.error(some_exception) reports the error to the Discord backend. For telemetry, I also hook them and report separately. Adding DiscoLog to your app only requires modifying the config, with no additional code changes. Additionally, we have duplicate logic in event.ex, which I need for error tracking.

You’re right.
There’s too much overlap.

Makes more sense to have an hypothetical tower_discord be a separate package that only depends on tower and maybe a Discord elixir client.

Thanks

This is genius. Putting logs and error tracking into an app people are already using is such a smart idea. Well done!

I released disco_log v0.5.1:

• it fixes an issue that was crashing the logger handler because some elixir type can’t be serialized as is

Meanwhile I have been using it in production on multiples side projects.
I’m very satisfied with the error tracking !

Next features on my list are:

• Go to code the idea is to be able to click the occurrence and to go to the relevant github code on the specfic branch / tag
• Active presence message to make the bot display some info about the node

I’ve only started using it but it’s been great so far. I like how setting up logging for multiple projects/environment is a matter of configuring category_id/channel_id.

I think I may have preferred starting DiscoLog under the application’s supervision tree and explicitly configuring logger handlers, but it might be too early to say

Thanks for your PR! It’s been released on Hex as version 0.6.

I considered allowing DiscoLog to start under an application’s supervision tree and using explicit logger handlers, but decided against it to keep the setup simpler. Everything started by the DiscoLog application is configurable, though, so it still allows flexibility. You can check out the setup in DiscoLog’s application module.

I’ve been looking through the code recently, and I have a feeling that it’s feasible to allow users to start discolog under their supervision tree while maintaining the default option of running it as an independent application. Basically, it should boil down to only reading from global configuration on start up and then passing it to all downstream code (logger handler, Discord.Client, etc.) through composition. So, it’s possible for users to just set enable: false in global config and attach their own logger handlers with custom configuration.

The problem is that it’s a lot of changes and I can’t think of too many use cases that it would unlock. I suppose, if you want to publish to multiple guilds or categories, that will make it possible. I’d still be happy to do this, as I just love the idea behind DiscoLog and want it to be awesome, but I don’t want to create a 1000 LOC refactoring PR out of the blue without your blessing Do you think making DiscoLog highly configurable is worth it, or would you rather shelve the idea until some time in the future?

Sure, it’s possible to achieve this without a big LOC I think.

The clean approach would be to include a Supervisor in the DiscoLog module. After that, you could run it in your application like this:

# lib/my_app/application.ex
def start(_type, _args) do
  children = [
    # other stuff,
    {DiscoLog, Application.fetch_env!(:my_app, :disco_log)}
  ]

  Supervisor.start_link(children, strategy: :one_for_one, name: MyApp.Supervisor)
end

In terms of configuration, there wouldn’t be much to change—just move the existing application logic in the supervisor. The current application would then call the supervisor instead.

For the logger handler, I think the current setup is fine. You can disable it and attach a custom handler yourself.

That said, I can’t think of specific use cases for this right now, but adding this feature would certainly make DiscoLog more flexible.

Oban is a great example of a library that give you a supervisor to start in your application.