Using "abusing OTP internals" makes me think that we should avoid that bit; but I'm admittedly unfamiliar with how the backends work. When I say "application" above, I'm mainly using it to mean modules that belong to the application - not processes. This would mean that GenServers started using application modules would also be included in the definitions.
I think this would be more expected; what do you think? Isaac Whitfield On Thursday, December 7, 2017 at 11:18:36 AM UTC-8, Michał Muskała wrote: > > There's always a question of what this setting would actually mean - > should it affect logging from modules that belong to that application or > should it affect logging from processes belonging to that application. If > the later, it's already possible with a custom logger backend by leveraging > the group leader mechanism and abusing OTP internals a little bit. > > Each log has the pid of the originating process - using > :application.get_application(pid) one can obtain the application where this > process runs. The backend can dispatch the log based on the configuration > and only log messages from some of the applications. > > Michał. > > On 7 Dec 2017, 20:01 +0100, Isaac Whitfield <[email protected] <javascript:>>, > wrote: > > This is based on previous conversation in > https://groups.google.com/d/msg/elixir-lang-core/C5-ixZVau3U/Gkb4PyOOAQAJ, > but this thread proposes an actual solution which I believe will benefit > everyone. > > The Logger in Elixir is widely used due to being in the standard library, > but misses out on a few key use cases that are familiar for developers > coming from other languages. For one, I believe it's time to add > functionality to suppress logs on a per-application basis. As the > application is known to the logging macros it can easily filter out at > compile time. This can also be a backwards-compatible option inside the > Logger configuration to override the default log level on a per application > basis: > > > config :logger, :my_logger, > level: :info, > applications: [ > library1: :debug > ] > > > This allows developers to allow logs to be noisier for specific > applications (such as their own), without being swamped with noise from > other applications. The :applications key will just override the default > level provided in the :level key. If the :applications key is not ideal, we > can name it something else (:apps, :override, etc). We could even just > combine the two in :levels and use a :default for the default level. > > In addition to these changes, I propose that a new logging level be added > which is lower than the default log level of :debug, with the intent that > all developers log to this unless there is explicit reason to have their > logs seen by default. The combination of this and the above :applications > key allows developers to easily turn on logs from applications they're > interested in at the time. It allows the application developer to decide > what is important enough for another developer to see, rather than the > developer having to (typically) guess. I propose that this new logging > level should be named any of :trace, :verbose or :quiet (with :trace being > preferred for brevity/familiarity). > > There are many other languages which encourage this style of logging. Here > are a few I know of: > > - Node.js has the "debug" package, which is widely popular as it allows > users to opt-in to seeing logs from specific namespaces (which roughly > translates to OTP applications in our use case). > - Java has SLF4J which hides debug logs by default, allowing you to opt in > on package or class level (also hugely popular). > - Rust's official logging framework defaults to actually hiding all > logging, making you explicitly ask to see logs (of any kind). > > The interesting thing with the packages from Node.s/Java is that they're > libraries and not in the standard library; they evolved because of the > standard logging missing this stuff (although to be fair, Node.js only has > console). As the Logger is so widely used in Elixir, it feels that we're > already at the point where this should be supported. Making this an > external library in Elixir would be wasted effort as we would then have > logging from different sources with different behaviour, thus lowering the > utility. I think that including this support in Logger will make logging > feel more familiar to developers coming from the languages above, without > making it unfamiliar to (e.g.) Ruby developers where the behaviour matches > what Elixir currently has. > > I appreciate any support and/or suggestions with this. I feel strongly > about not having a "quiet" log level, as it causes a very painful balance > for a library developer when determining how verbose to be with logging. > > Thanks in advance for all replies, feel free to ask questions! > IW > > -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/606029ea-9855-44c6-ba94-69113ffed45c%40googlegroups.com > > <https://groups.google.com/d/msgid/elixir-lang-core/606029ea-9855-44c6-ba94-69113ffed45c%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/61adb36f-e448-46c2-abf9-b1a5757a14d3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
