journald alternatives and similar packages
Based on the "Logging" category.
Alternatively, view journald alternatives based on common mentions on social networks and blogs.
-
spew
Implements a deep pretty printer for Go data structures to aid in debugging -
seelog
Seelog is a native Go logging library that provides flexible asynchronous dispatching, filtering, and formatting. -
go-logger
Simple logger for Go programs. Allows custom formats for messages. -
rollingwriter
Rolling writer is an IO util for auto rolling write in go. -
sqldb-logger
A logger for Go SQL database driver without modifying existing *sql.DB stdlib usage. -
httpretty
Package httpretty prints the HTTP requests you make with Go pretty on your terminal. -
loggo
A logging library for Go. Doesn't use the built in go log standard library, but instead offers a replacement. -
ozzo-log
A Go (golang) package providing high-performance asynchronous logging, message filtering by severity and category, and multiple message targets. -
logex
An golang log lib, supports tracking and level, wrap by standard log lib -
gologger
Simple easy to use log lib for go, logs in Colored Cosole, Simple Console, File or Elasticsearch. -
noodlog
๐ Parametrized JSON logging library in Golang which lets you obfuscate sensitive data and marshal any kind of content. -
mlog
A simple logging module for go, with a rotating file feature and console logging. -
slf
The Structured Logging Facade (SLF) for Go (like SLF4J but structured and for Go) -
Kiwi Logs&Context
Fast, structured, with filters and dynamic sinks. No levels. Logger & context keeper for Go language ๐ฅ It smell like a mushroom. -
logmatic
Colorized logger for Golang with dynamic log level configuration -
slog
The reference implementation of the Structured Logging Facade (SLF) for Go -
gomol
Gomol is a library for structured, multiple-output logging for Go with extensible logging outputs -
kemba
A tiny debug logging tool. Ideal for CLI tools and command applications. Inspired by https://github.com/visionmedia/debug -
go-rethinklogger
Automatically persists all the logs of your Go application inside RethinkDB.
Learn any GitHub repo in 59 seconds
Do you think we are missing an alternative of journald or a related project?
Popular Comparisons
README
journald
Package journald
offers Go implementation of systemd Journal's native API for logging. Key features are:
- based on a connection-less socket
- work with messages of any size and type
- client can use any number of separate sockets
Installation
Install the package with:
go get github.com/ssgreg/journald
Usage: The Best Way
The Best Way to use structured logs (systemd Journal, etc.) is logf - the fast, asynchronous, structured logger in Go with zero allocation count and it's journald driver logfjournald. This driver uses journald
package.
The following example creates the new logf
logger with logfjournald
appender.
package main
import (
"runtime"
"github.com/ssgreg/logf"
"github.com/ssgreg/logfjournald"
)
func main() {
// Create journald Appender with default journald Encoder.
appender, appenderClose := logfjournald.NewAppender(logfjournald.NewEncoder.Default())
defer appenderClose()
// Create ChannelWriter with journald Encoder.
writer, writerClose := logf.NewChannelWriter(logf.ChannelWriterConfig{
Appender: appender,
})
defer writerClose()
// Create Logger with ChannelWriter.
logger := logf.NewLogger(logf.LevelInfo, writer)
logger.Info("got cpu info", logf.Int("count", runtime.NumCPU()))
}
The JSON representation of the journal entry this generates:
{
"TS": "2018-11-01T07:25:18Z",
"PRIORITY": "6",
"LEVEL": "info",
"MESSAGE": "got cpu info",
"COUNT": "4",
}
Usage: AS-IS
Let's look at what the journald
provides as Go APIs for logging:
package main
import (
"github.com/ssgreg/journald"
)
func main() {
journald.Print(journald.PriorityInfo, "Hello World!")
}
The JSON representation of the journal entry this generates:
{
"PRIORITY": "6",
"MESSAGE": "Hello World!",
"_PID": "3965",
"_COMM": "simple",
"...": "..."
}
The primary reason for using the Journal's native logging APIs is not just plain logs: it is to allow passing additional structured log messages from the program into the journal. This additional log data may the be used to search the journal for, is available for consumption for other programs, and might help the administrator to track down issues beyond what is expressed in the human readable message text. Here's an example how to do that with journals.Send
:
package main
import (
"os"
"runtime"
"github.com/ssgreg/journald"
)
func main() {
journald.Send("Hello World!", journald.PriorityInfo, map[string]interface{}{
"HOME": os.Getenv("HOME"),
"TERM": os.Getenv("TERM"),
"N_GOROUTINE": runtime.NumGoroutine(),
"N_CPUS": runtime.NumCPU(),
"TRACE": runtime.ReadTrace(),
})
}
This will write a log message to the journal much like the earlier examples. However, this times a few additional, structured fields are attached:
{
"PRIORITY": "6",
"MESSAGE": "Hello World!",
"HOME": "/root",
"TERM": "xterm",
"N_GOROUTINE": "2",
"N_CPUS": "4",
"TRACE": [103,111,32,49,46,56,32,116,114,97,99,101,0,0,0,0],
"_PID": "4037",
"_COMM": "send",
"...": "..."
}
Our structured message includes seven fields. The first two we passed are well-known fields:
MESSAGE=
is the actual human readable message part of the structured message.PRIORITY=
is the numeric message priority value as known from BSD syslog formatted as an integer string.
Applications may relatively freely define additional fields as they see fit (we defined four pretty arbitrary ones in our example). A complete list of the currently well-known fields is available here.
Thanks to http://0pointer.de/blog/ for the inspiration.