Make Tower.Event support a service name

[msutkowski]

This is a small proposal that would ultimately build on the use case mentioned in #118. Currently, Tower always assumes that the error it is processing is from the current application. While this is going to be correct the majority of the time, we could make this slightly more flexible by introducing a service key to the struct that defaults to the current :otp_app (while allowing for an override). The idea here is that this is pretty minimal effort to support, but opens the door for someone to configure Tower as a centralized hub for errors from N services.

The other option is we could find a way to leverage the existing metadata for this purpose and just not consider this at all, but I believe we'd have to deal with this comment:

# Not beautiful that tower needs to know about something specific to tower_error_tracker.
# We may refactor this to be configurable by reporters or it can change once we support
# something like `Tower.set_context`.

Some possible options for making this work to start a discussion:

1. In application config -- config :tower, service: :my_great_service
2. Tower.set_context support
3. Extend logger_metadata env behavior (I don't really see this one working out at all, but it's possible)

Just to be clear, the goal is ultimately to find the best mechanism to say "I am an error being reported by app/service X". It's possible that this might just be a terrible idea, and that's okay! This is all still possible in user land code, but requires a bit of effort to achieve the same thing.

If this idea moves forward, I can open a similar discussion in ErrorTracker for how we make slight changes to support service aggregation.

Thanks for your time!

References:

• https://docs.datadoghq.com/getting_started/tagging/#overview (i don't think we'd need to support tags like this, but you can see how service is used)

[grzuy]

Hi @msutkowski ,

Thanks for starting this discussion, and detailing with clarity the motivation.

Just to be clear, the goal is ultimately to find the best mechanism to say "I am an error being reported by app/service X". It's possible that this might just be a terrible idea, and that's okay! This is all still possible in user land code, but requires a bit of effort to achieve the same thing.

At first glance, I think this sounds like a fair request.

In fact this is something that if supported natively in tower I think could obsolete configuration settings called otp_app in some reporters:

• tower_slack https://github.com/mimiquate/tower_slack?tab=readme-ov-file#usage
• tower_email https://github.com/mimiquate/tower_email?tab=readme-ov-file#usage

It's interesting how the term "current application" is a bit tricky to define in BEAM land, given that in reality BEAM is starting multiple parallel applications when booting, your mix project app, any included_applications/extra_applications and your dependencies applications (at least those not with runtime: false).

So even the term otp_app that we have for the reporters now I realize might be confusing. Maybe service is better suited.

Will give some more thought to this...

[grzuy]

So even the term otp_app that we have for the reporters now I realize might be confusing. Maybe service is better suited.

I guess this is the term mostly used everywhere though, by Phoenix.Endpoint and others...

[msutkowski]

Yea - we tend to use otp_app everywhere as well, but when I think about reporting errors, I'm thinking specifically about service attribution. A relevant example might be that you have an otp_app: :warehouse, but it's going to report to DataDog as wms-service due to helm/kube/whatever configs. I was originally thinking that you'd just default to otp_app, but then allow customization -- either way, I don't think it's a large issue. If tower were to keep the BEAM specific naming, that's fine and solvable with documentation.

[grzuy]

Related: https://elixirforum.com/t/how-to-get-application-name-at-compile-time/59168.