HN Explorer

Show HN: dazl – the Go logging framework of frameworks (github.com)

9 points by kuujo ↗ HN
A few years ago, my team moved from Java to Go. Working on Go projects, we came across a variety of logging frameworks with different APIs outputting messages in different formats. Go seemed to be lacking a logging abstraction like slf4j, which has been so invaluable to the Java ecosystem. Without that abstraction layer, the APIs for configuring logging vary wildly across projects, and libraries must either add a dependency on one of those frameworks or simply avoid structured logging altogether.

Dazl is a logging abstraction layer that decouples the logging API from specific Go logging libraries, providing a pluggable logging backend with support for popular frameworks like zap and zerolog. Add logging to your Go library without forcing a particular logging dependency on your users. Use dazl to make logging configurable (via YAML) in your Go application. Dazl is designed to make logging easier for Go developers and their users by providing a unified interface to establish consistency across Go libraries and logging frameworks.

Dazl was originally developed in open source at the Open Networking Foundation but remained somewhat hidden away within the subdirectories of an obscure repo. My team has since moved to Intel where this project is still in use in today. I’m sharing it now in the hopes Go developers will get the same value from it we have.

3 comments

[ 3.1 ms ] story [ 20.1 ms ] thread
bboreham
Thanks for highlighting. How does it relate to slog?

https://pkg.go.dev/golang.org/x/exp/slog

kuujo
We’re not attempting to replace any of the existing Go logging frameworks. Dazl is an abstraction layer above structured loggers like slog. We could add a slog plugin (we have zap and zerolog plugins already). Essentially, what you would get from that is the ability to configure slog loggers (log levels, fields, outputs/writers, sampling, etc) via dazl configuration files.

But the fundamental role of dazl is really to eliminate dependencies on frameworks like slog as much as possible, particularly in Go libraries. If libraries use dazl rather than a framework like slog, users of the library can then import whatever logging backend they want to use (slog, zap, zerolog, etc). This becomes really useful when dazl is used by multiple libraries depended on by a Go application. Often different libraries will use different logging frameworks (if they even have logging at all), and this can produce inconsistent log messages with no unified interface for configuring loggers across your dependencies. In a perfect world, those libraries you depend on would use dazl for logging instead, enabling the top-level project that depends on those libraries to configure a single logging backend that’s shared across all the dependencies.

bboreham
I believe slog is also intended to sit above existing loggers. It is quite new.