I'm not interested in using a package (I could have written one myself);
this does not provide a good experience for end user applications where
developers have to use dozens of different options to enable logs across
all of their dependencies. The point of adding this to Logger is to provide
a single option set to enable logging across all of their dependencies and
modules, making it easier to switch on/off, and due to Logger living in
stdlib it's easy to discover and many people will default to using it. This
makes a naturally better logging ecosystem for everyone, not just the
people who want/need this feature. What's more, if your categories are
arbitrary, how do you know the categories someone has used in a dependency?
Finding out makes the process a lot more painful.
Isaac
On Monday, December 11, 2017 at 9:33:57 AM UTC-8, Steve Pallen wrote:
>
> I built a solution for a similar scenario and have it running in
> approximately 50 production deployments. The product that uses it is a
> telecommunications gateway supporting up to 3000 business telephones. Some
> of these deployments support 24x7 high volume call centers. To give you an
> idea of its complexity, the solution supports up to 40 TCP and 10 UPD
> connections to external servers as well as a reliable UPD connection for
> each of the 300 phones. This equates to approximately 3100 long running,
> supervised processes.
>
> The solution wraps the standard out of the box Logger with the same
> functions and levels, but adds an extra (optional) argument to the log/2,
> error/1, warn/1, info/1 and debug/1 functions. Here is how it's used:
>
> use MyLogger
>
> MyLogger.info :category1,"log message"
> MyLogger.debug :category2,"some #{inspect expensive}operation"
> MyLogger.warn"always displayed when :warn level set"
>
> The category levels can be set in the config file as well as changed at
> run time. Messages are always converted to anonymous functions so they are
> only expanded when the appropriate category is enabled. I also support
> compile time purging of specific categories similar to how Logger works
> today. I have helpers to query, set, and clear levels. The module can be
> imported in iex to provide a simple interface for log and category control
> in remote consoles for production use.
>
> My production solution has around 25 categories. We use it all the time
> when trouble shooting had to reproduce issues on high traffic customer
> sites. We use it extensively with info and debug levels. When a problem is
> reported, we first review the default logs. If we cannot identify the
> problem, we enable additional categories for the areas that we think the
> problem may be in. Then we wait for the next report of the problem (or
> proactively monitor the logs). We find it very useful for either finding
> the problem, or for getting enough information to reproduce the issue in
> our lab.
>
> We define some categories at the module (process) level and others by
> topic. Topic categories may span multiple processes to help identify cross
> cutting issues. I use an `init` category log in init callback of pretty
> well every gen_server. It logs the process's PID and other identification
> information. I have this category enabled by default.
>
> I have not released this as an open source package, but would be willing
> if there is an interest in the community.
>
> Personally, I prefer the 3rd party dependency approach over building in
> the support to Logger. This is not something that most developers will
> need. However, I believe that is an extremely useful solution for some
> projects.
>
> I look forward to hearing from anyone that may be interested in hex
> package. I may also cross post this on Elixir Forum to get additional
> feedback.
>
> Steve
>
> PS. The ability to control log levels on a module by module bases would
> also be easy to implement as a hex package and added to existing modules by
> simply aliasing `require MyLogger, as: Logger` and implementing the
> wrappers to the existing Logger APIs.
>
> On Thursday, December 7, 2017 at 2:01:40 PM UTC-5, Isaac Whitfield 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.
>>
>>
>>
--
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/c81977b2-064a-4f8d-9f2a-f8d7e5c5d16c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
