godeps: bump coreos/pkg/capnslog

Update to catch coreos/pkg#43 which should fix SYSLOG_IDENTIFIER getting
set when etcd is logging to the journal.
This commit is contained in:
Jonathan Boulle 2015-11-06 18:37:06 +01:00 committed by Yicheng Qin
parent 53bc644168
commit 5d6457e658
4 changed files with 15 additions and 12 deletions

2
Godeps/Godeps.json generated
View File

@ -53,7 +53,7 @@
}, },
{ {
"ImportPath": "github.com/coreos/pkg/capnslog", "ImportPath": "github.com/coreos/pkg/capnslog",
"Rev": "42a8c3b1a6f917bb8346ef738f32712a7ca0ede7" "Rev": "2c77715c4df99b5420ffcae14ead08f52104065d"
}, },
{ {
"ImportPath": "github.com/gogo/protobuf/proto", "ImportPath": "github.com/gogo/protobuf/proto",

View File

@ -1,32 +1,33 @@
# CoreOS Log # capnslog, the CoreOS logging package
There are far too many logging packages out there, with varying degrees of licenses, far too many features (colorization, all sorts of log frameworks) or are just a pain to use (lack of `Fatalln()`?) There are far too many logging packages out there, with varying degrees of licenses, far too many features (colorization, all sorts of log frameworks) or are just a pain to use (lack of `Fatalln()`?).
capnslog provides a simple but consistent logging interface suitable for all kinds of projects.
## Design Principles ### Design Principles
* `package main` is the place where logging gets turned on and routed ##### `package main` is the place where logging gets turned on and routed
A library should not touch log options, only generate log entries. Libraries are silent until main lets them speak. A library should not touch log options, only generate log entries. Libraries are silent until main lets them speak.
* All log options are runtime-configurable. ##### All log options are runtime-configurable.
Still the job of `main` to expose these configurations. `main` may delegate this to, say, a configuration webhook, but does so explicitly. Still the job of `main` to expose these configurations. `main` may delegate this to, say, a configuration webhook, but does so explicitly.
* There is one log object per package. It is registered under its repository and package name. ##### There is one log object per package. It is registered under its repository and package name.
`main` activates logging for its repository and any dependency repositories it would also like to have output in its logstream. `main` also dictates at which level each subpackage logs. `main` activates logging for its repository and any dependency repositories it would also like to have output in its logstream. `main` also dictates at which level each subpackage logs.
* There is *one* output stream, and it is an `io.Writer` composed with a formatter. ##### There is *one* output stream, and it is an `io.Writer` composed with a formatter.
Splitting streams is probably not the job of your program, but rather, your log aggregation framework. If you must split output streams, again, `main` configures this and you can write a very simple two-output struct that satisfies io.Writer. Splitting streams is probably not the job of your program, but rather, your log aggregation framework. If you must split output streams, again, `main` configures this and you can write a very simple two-output struct that satisfies io.Writer.
Fancy colorful formatting and JSON output are beyond the scope of a basic logging framework -- they're application/log-collector dependant. These are, at best, provided as options, but more likely, provided by your application. Fancy colorful formatting and JSON output are beyond the scope of a basic logging framework -- they're application/log-collector dependant. These are, at best, provided as options, but more likely, provided by your application.
* Log objects are an interface ##### Log objects are an interface
An object knows best how to print itself. Log objects can collect more interesting metadata if they wish, however, because text isn't going away anytime soon, they must all be marshalable to text. The simplest log object is a string, which returns itself. If you wish to do more fancy tricks for printing your log objects, see also JSON output -- introspect and write a formatter which can handle your advanced log interface. Making strings is the only thing guaranteed. An object knows best how to print itself. Log objects can collect more interesting metadata if they wish, however, because text isn't going away anytime soon, they must all be marshalable to text. The simplest log object is a string, which returns itself. If you wish to do more fancy tricks for printing your log objects, see also JSON output -- introspect and write a formatter which can handle your advanced log interface. Making strings is the only thing guaranteed.
* Log levels have specific meanings: ##### Log levels have specific meanings:
* Critical: Unrecoverable. Must fail. * Critical: Unrecoverable. Must fail.
* Error: Data has been lost, a request has failed for a bad reason, or a required resource has been lost * Error: Data has been lost, a request has failed for a bad reason, or a required resource has been lost

View File

@ -19,7 +19,7 @@ import "os"
func init() { func init() {
initHijack() initHijack()
// Go `log` pacakge uses os.Stderr. // Go `log` package uses os.Stderr.
SetFormatter(NewPrettyFormatter(os.Stderr, false)) SetFormatter(NewPrettyFormatter(os.Stderr, false))
SetGlobalLogLevel(INFO) SetGlobalLogLevel(INFO)
} }

View File

@ -20,6 +20,7 @@ import (
"errors" "errors"
"fmt" "fmt"
"os" "os"
"path/filepath"
"github.com/coreos/etcd/Godeps/_workspace/src/github.com/coreos/go-systemd/journal" "github.com/coreos/etcd/Godeps/_workspace/src/github.com/coreos/go-systemd/journal"
) )
@ -56,6 +57,7 @@ func (j *journaldFormatter) Format(pkg string, l LogLevel, _ int, entries ...int
msg := fmt.Sprint(entries...) msg := fmt.Sprint(entries...)
tags := map[string]string{ tags := map[string]string{
"PACKAGE": pkg, "PACKAGE": pkg,
"SYSLOG_IDENTIFIER": filepath.Base(os.Args[0]),
} }
err := journal.Send(msg, pri, tags) err := journal.Send(msg, pri, tags)
if err != nil { if err != nil {