-
Notifications
You must be signed in to change notification settings - Fork 13
Using multiple loggers
What actually a Sealog logger is? It is:
- A set of funcs which hold the common algorithms
- A configuration which specifies all parameters
The former is always the same, so if the loggers are 'different', it is obvious that actually the 'configurations' are different.
Therefore, this section is about logging with different configs in the same application.
Actually, you don't need it in most cases. If you need to change some parameters on the fly, read this section: Changing config on the fly. So, multiple configs should be used in case you really need different logger configurations to exist simultaneously.
Usually, the most common use-case for this functionality is logging in programs with multiple modules, e.g. you import 2-3 libraries that also use Sealog, so you want to pass them special configs. See Writing libraries with Sealog.
Another practical case is logging in extremely performance critical situations: it is sometimes not acceptable to write many exception cases and filters in dispatching scheme for performance critical sections, because it could make things too complicated. In these cases it could be better to write a simple config, which just holds 1 constraint and 1 output and just use this config in all such critical files.
NOTE: In most situations, even in high-load apps, you don't need that, because you just should log so much. Info messages and warns for diagnostics (not frequent), errors and critical for errors (also not frequent). Debug and Trace should be disabled in production configs. So probably, this 'multi-config' feature should be used rarely in case it is absolutely needed.
Actually, all Sealog package-level funcs are operating on package-level config variables. They are:
(sealog/log.go)
var currentConfig *config.LogConfig
var defaultConfig *config.LogConfig
When you call sealog.SetConfig func, you overwrite 'currentConfig' variable. All funcs, like 'Trace', 'Debug', 'Info', etc. - use 'currentConfig' under the hood. If 'currentConfig' was not set yet, 'defaultConfig' is used.
In a normal case you call 'SetConfig' to overwrite the package level variable 'currentConfig'. If you need more configs in addition to the package-level 'currentConfig', you create those additional configs and use special methods which end with 'WithConfig': TraceWithConfig, DebugWithConfig, and others, passing them these additional configurations.