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/e4d70614-cddb-49ae-8f68-d87f8b33de14%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
