README
¶
c4hgol
import "git.fractalqb.de/fractalqb/c4hgol"
Configuration for Heterogeneous Go Loggers
Though Go has a logging package in its standard library this package is rather basic. IMHO this is the reason why there are several additional and different logging libraries in the Go community which lead to some irritation when one wants to write an application that ends up with having several different logging frameworks included due to package dependencies.
This package does not address the desire to have one unified logger or at least a unified logging interface. – Let the packages choose their loggers… for good or for bad. However, what I want to be able to do is configure all those loggers in my application in a unified way! At least configure some common things that one often wants to configure:
- Switching loggers for some “topics” on and off
- Setting the log level of loggers
- Set a writer as the target for the logging messages
- (to come: log format?)
Note that the first bullet in the list gives the hint that loggers shall be grouped into topics so that configuration becomes simpler.
Log Packages Architecture Proposition
Make a virtue of necessity…
Theoretical Approach
First of all one has to question why it could come to the situation that a single executable includes different loggin libraries! If each component (library), an executable is made of, returns detailed information about the coutome of each of its offered services (functions/methods) the executable can decide if and how to log those outcomes.—No need for a component to do logging at all, i.e. only the executable uses logging and therefere can arrange to use one logging library.
In theory this could be done for exceptional situations, aka errors. Here one could start to collect context information at the point of failure. This information then propagates back to the executable while beeing enriched with relevant context information. Again, it would be up to the executable to decide what to do with this.
For “small” components and when executables have a rather shallow dependecy graph this approach does not only work well, it is also a desirable approach. – It keeps thigs simple!
Facing the Real World…
…at least when things become more and more complex. In reality we often see requiremenst that break the Theoretical Approach:
-
In practice error/exception handling is rarely perfect and most often only comes with a text message. This makes reasonable decisions difficult for executables.
-
As soon as one also wants information about the happy case details from a deeply “buiried” component it gets difficult, if not impossible, for top-level executable's code to get that.
For short: One has to expect that sufficiently sofisticated components come with their own logging included.
Would that be a problem? IMHO not, as long as you have some means to configure the loggers to your need. I.e. make c4hgol a concept! This would address the need of application developers and gives reasonable choices to component developers:
-
Component developers can chose their logging API
-
Logging calls can be static calls, i.e. no dynamic dispatching through interfaces
Used by
- qbsllm – combines leveled logging, Slim structured logging and c4hgol into one logging library.
- c4apex – Implements a c4hgol Configurer for apex/log
Documentation
¶
Overview ¶
Though Go has a logging package in its standard library this package is rather basic. IMHO this is the reason why there are several additional and different logging libraries in the Go community which lead to some irritation when one wants to write an application that ends up with having several different logging frameworks included due to package dependencies.
This package does not address the desire to have one unified logger or at least a unified logging interface. – Let the packages choose their loggers… for good or for bad. However, what I want to be able to do is configure all those loggers in my application in a unified way! At least configure some common things that one often wants to configure:
- Switching loggers for some “topics” on and off
- Setting the log level of loggers
- (may be other things to come in the future)
Note that the first bullet in the list gives the hint that loggers shall be grouped into topics so that configuration becomes simpler.
Index ¶
- func ForTopics(cfg Configurer, do func(current Configurer, path []string))
- func LevelCfgDoc(lvlMap map[string]Level) string
- func ListTopics(cfg Configurer, wr io.Writer, prefix string)
- func SetLevel(cfg Configurer, cfgStr string, lvlMap map[string]Level)
- type Configurer
- type Level
- type LevelMap
- type Topic
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func ForTopics ¶
func ForTopics(cfg Configurer, do func(current Configurer, path []string))
func ListTopics ¶
func ListTopics(cfg Configurer, wr io.Writer, prefix string)
func SetLevel ¶
func SetLevel(cfg Configurer, cfgStr string, lvlMap map[string]Level)
Types ¶
type Configurer ¶
type Configurer interface {
Name() string
Enabled() bool
Enable(setEnabled bool)
Level() Level
SetLevel(l Level)
Output() io.Writer
SetOutput(wr io.Writer)
}
func NewTopic ¶
func NewTopic(represents Configurer, subtopics ...Configurer) Configurer
type Level ¶
type Level = int32
Type Level denotes the importance of a log message. It sets 0 to be the normal log message most commonly identified as Info. More important messages have higher values and less important levels get lower values. These values have to be mapped to specific logging packages by the respective Configurer implementation.
Note that there are no predefined constants for Panic and Fatal as these also imply specific behaviour that gose beyond logging a message. For c4hgol we consider Panic and Fatal to be "a separate story".
Source Files
Directories