github.com/wheelcomplex/cue
Package cue implements contextual logging with "batteries included". It has thorough test coverage and supports logging to stdout/stderr, file, syslog, and network sockets, as well as hosted third-party logging and error/reporting services such as Honeybadger, Loggly, Opbeat, Rollbar, and Sentry. Cue uses atomic operations to compare logging calls to registered collector thresholds. This ensures no-op calls are performed quickly and without lock contention. On a 2015 MacBook Pro, no-op calls take about 16ns/call, meaning tens of millions of calls may be dispatched per second. Uncollected log calls are very cheap. Furthermore, collector thresholds may be altered dynamically at run-time, on a per-collector basis. If debugging logs are needed to troubleshoot a live issue, collector thresholds may be set to the DEBUG level for a short period of time and then restored to their original levels shortly thereafter. See the SetLevel function for details. Logging instances are created via the NewLogger function. A simple convention is to initialize an unexported package logger: Additional context information may be added to the package logger via the log.WithValue and log.WithFields methods: Depending on the collector and log format, output would look something like: Cue simplifies error reporting by logging the given error and message, and then returning the same error value. Hence you can return the log.Error/log.Errorf values in-line: Cue provides Collector implementations for popular error reporting services such as Honeybadger, Rollbar, Sentry, and Opbeat. If one of these collector implementations were registered, the above code would automatically open a new error report, complete with stack trace and context information from the logger instance. See the cue/hosted package for details. Finally, cue provides convenience methods for panic and recovery. Calling Panic or Panicf will log the provided message at the FATAL level and then panic. Calling Recover recovers from panics and logs the recovered value and message at the FATAL level. If a panic is triggered via a cue logger instance's Panic or Panicf methods, Recover recovers from the panic but only emits the single event from the Panic/Panicf method. Cue decouples event generation from event collection. Library and framework authors may generate log events without concern for the details of collection. Event collection is opt-in -- no collectors are registered by default. Event collection, if enabled, should be configured close to a program's main package/function, not by libraries. This gives the event subscriber complete control over the behavior of event collection. Collectors are registered via the Collect and CollectAsync functions. Each collector is registered for a given level threshold. The threshold for a collector may be updated at any time using the SetLevel function. Collect registers fully synchronous event collectors. Logging calls that match a synchronous collector's threshold block until the collector's Collect method returns successfully. This is dangerous if the Collector performs any operations that block or return errors. However, it's simple to use and understand: CollectAsync registers asynchronous collectors. It creates a buffered channel for the collector and starts a worker goroutine to service events. Logging calls return after queuing events to the collector channel. If the channel's buffer is full, the event is dropped and a drop counter is incremented atomically. This ensures asynchronous logging calls never block. The worker goroutine detects changes in the atomic drop counter and surfaces drop events as collector errors. See the cue/collector docs for details on collector error handling. When asynchronous logging is enabled, Close must be called to flush queued events on program termination. Close is safe to call even if asynchronous logging isn't enabled -- it returns immediately if no events are queued. Note that ctrl+c and kill <pid> terminate Go programs without triggering cleanup code. When using asynchronous logging, it's a good idea to register signal handlers to capture SIGINT (ctrl+c) and SIGTERM (kill <pid>). See the os/signals package docs for details. By default, cue collects a single stack frame for any event that matches a registered collector. This ensures collectors may log the file name, package, and line number for any collected event. SetFrames may be used to alter this frame count, or disable frame collection entirely. See the SetFrames function for details. When using error reporting services, SetFrames should be used to increase the errorFrames parameter from the default value of 1 to a value that provides enough stack context to successfully diagnose reported errors. This example logs to both the terminal (stdout) and to file. If the program receives SIGHUP, the file will be reopened (for log rotation). Additional context is added via the .WithValue and .WithFields Logger methods. The formatting may be changed by passing a different formatter to either collector. See the cue/format godocs for details. The context data may also be formatted as JSON for machine parsing if desired. See cue/format.JSONMessage and cue/format.JSONContext. This example shows how to use error reporting services. This example shows quite a few of the cue features: logging to a file that reopens on SIGHUP (for log rotation), logging colored output to stdout, logging to syslog, and reporting errors to Honeybadger.
Readme
Cue implements contextual logging with "batteries included". It has thorough test coverage and supports logging to stdout/stderr, file, syslog, and network sockets, as well as hosted third-party logging and error/reporting services such as Honeybadger, Loggly, Opbeat, Rollbar, and Sentry.
Cue uses atomic operations to compare logging calls to registered collector thresholds. This ensures no-op calls are performed quickly and without lock contention. On a 2015 MacBook Pro, no-op calls take about 16ns/call, meaning tens of millions of calls may be dispatched per second. Uncollected log calls are very cheap.
Minor breaking changes may occur prior to the 1.0 release. After the 1.0 release, the API is guaranteed to remain backwards compatible.
Cue makes use of sync/atomic.Value and thus requires Go 1.4.x or later.
Please see the godocs for additional information.
This example logs to both the terminal (stdout) and to file. If the program receives SIGHUP, the file will be reopened. This is useful for log rotation. Additional context is added via the .WithValue and .WithFields Logger methods.
The formatting may be changed by passing a different formatter to either collector. See the cue/format godocs for details. The context data may also be formatted as JSON for machine parsing if desired. See cue/format.JSONMessage and cue/format.JSONContext.
package main
import (
"github.com/bobziuchkovski/cue"
"github.com/bobziuchkovski/cue/collector"
"os"
"syscall"
)
var log = cue.NewLogger("main")
func main() {
cue.Collect(cue.INFO, collector.Terminal{}.New())
cue.Collect(cue.INFO, collector.File{
Path: "app.log",
ReopenSignal: syscall.SIGHUP,
}.New())
log := cue.NewLogger("example")
log.Debug("Debug message -- a quick no-op since our collector is registered at INFO level")
log.Info("Info message")
log.Warn("Warn message")
// Add additional context
log.WithValue("items", 2).Infof("This is an %s", "example")
log.WithFields(cue.Fields{
"user": "bob",
"authenticated": true,
}).Warn("Doing something important")
host, err := os.Hostname()
if err != nil {
log.Error(err, "Failed to retrieve hostname")
} else {
log.Infof("My hostname is %s", host)
}
// The output looks something like:
// Mar 13 12:40:10 INFO example_basic_test.go:25 Info message
// Mar 13 12:40:10 WARN example_basic_test.go:26 Warn message
// Mar 13 12:40:10 INFO example_basic_test.go:29 This is an example items=2
// Mar 13 12:40:10 WARN example_basic_test.go:33 Doing something important user=bob authenticated=true
// Mar 13 12:40:10 INFO example_basic_test.go:39 My hostname is pegasus.bobbyz.org
}
Please see the godocs for additional information.
This example uses cue/hosted.Honeybadger to report error events to Honeybadger.
package main
import (
"github.com/bobziuchkovski/cue"
"github.com/bobziuchkovski/cue/hosted"
"os"
"time"
)
var log = cue.NewLogger("main")
func main() {
// Here we're assuming the Honeybadger API key is stored via environment
// variable, as well as an APP_ENV variable specifying "test", "production", etc.
cue.CollectAsync(cue.ERROR, 10000, hosted.Honeybadger{
Key: os.Getenv("HONEYBADGER_KEY"),
Environment: os.Getenv("APP_ENV"),
}.New())
// We want to collect more stack frames for error and panic events so that
// our Honeybadger incidents show us enough stack trace to troubleshoot.
cue.SetFrames(1, 32)
// We use Close to flush the asynchronous buffer. This way we won't
// lose error reports if one is in the process of sending when the program
// is terminating.
defer cue.Close(5 * time.Second)
// If something panics, it will automatically open a Honeybadger event
// when recovered by this line
defer log.Recover("Recovered panic")
// Force a panic
PanickingFunc()
}
func PanickingFunc() {
panic("This will be reported to Honeybadger")
}
Please see the godocs for additional information.
This example shows quite a few of the cue features: logging to a file that reopens on SIGHUP (for log rotation), logging colored output to stdout, logging to syslog with JSON context formatting, and reporting errors to Honeybadger.
package main
import (
"github.com/bobziuchkovski/cue"
"github.com/bobziuchkovski/cue/collector"
"github.com/bobziuchkovski/cue/format"
"github.com/bobziuchkovski/cue/hosted"
"os"
"syscall"
"time"
)
var log = cue.NewLogger("main")
func main() {
// defer cue.Close before log.Recover so that Close flushes any events
// triggers by panic recovery
defer cue.Close(5 * time.Second)
defer log.Recover("Recovered panic in main")
ConfigureLogging()
RunTheProgram()
}
func ConfigureLogging() {
// Collect logs to stdout in color! :)
cue.Collect(cue.DEBUG, collector.Terminal{
Formatter: format.HumanReadableColors,
}.New())
// Collect to app.log and reopen the handle if we receive SIGHUP
cue.Collect(cue.INFO, collector.File{
Path: "app.log",
ReopenSignal: syscall.SIGHUP,
}.New())
// Collect to syslog, formatting the context data as JSON for indexing.
cue.Collect(cue.WARN, collector.Syslog{
App: "app",
Facility: collector.LOCAL7,
Formatter: format.JSONMessage,
}.New())
// Report errors asynchronously to Honeybadger. If HONEYBADGER_KEY is
// unset, Honeybadger.New will return nil and cue.CollectAsync will
// ignore it. This works great for development.
cue.CollectAsync(cue.ERROR, 10000, hosted.Honeybadger{
Key: os.Getenv("HONEYBADGER_KEY"),
Environment: os.Getenv("APP_ENV"),
}.New())
cue.SetFrames(1, 32)
}
func RunTheProgram() {
log.Info("Running the program!")
log.WithFields(cue.Fields{
"sad": true,
"length": 0,
}).Panic("No program", "Whoops, there's no program to run!")
}
Please see the godocs for additional details.
Bob Ziuchkovski (@bobziuchkovski)
Copyright (c) 2016 Bob Ziuchkovski
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
FAQs
Package cue implements contextual logging with "batteries included". It has thorough test coverage and supports logging to stdout/stderr, file, syslog, and network sockets, as well as hosted third-party logging and error/reporting services such as Honeybadger, Loggly, Opbeat, Rollbar, and Sentry. Cue uses atomic operations to compare logging calls to registered collector thresholds. This ensures no-op calls are performed quickly and without lock contention. On a 2015 MacBook Pro, no-op calls take about 16ns/call, meaning tens of millions of calls may be dispatched per second. Uncollected log calls are very cheap. Furthermore, collector thresholds may be altered dynamically at run-time, on a per-collector basis. If debugging logs are needed to troubleshoot a live issue, collector thresholds may be set to the DEBUG level for a short period of time and then restored to their original levels shortly thereafter. See the SetLevel function for details. Logging instances are created via the NewLogger function. A simple convention is to initialize an unexported package logger: Additional context information may be added to the package logger via the log.WithValue and log.WithFields methods: Depending on the collector and log format, output would look something like: Cue simplifies error reporting by logging the given error and message, and then returning the same error value. Hence you can return the log.Error/log.Errorf values in-line: Cue provides Collector implementations for popular error reporting services such as Honeybadger, Rollbar, Sentry, and Opbeat. If one of these collector implementations were registered, the above code would automatically open a new error report, complete with stack trace and context information from the logger instance. See the cue/hosted package for details. Finally, cue provides convenience methods for panic and recovery. Calling Panic or Panicf will log the provided message at the FATAL level and then panic. Calling Recover recovers from panics and logs the recovered value and message at the FATAL level. If a panic is triggered via a cue logger instance's Panic or Panicf methods, Recover recovers from the panic but only emits the single event from the Panic/Panicf method. Cue decouples event generation from event collection. Library and framework authors may generate log events without concern for the details of collection. Event collection is opt-in -- no collectors are registered by default. Event collection, if enabled, should be configured close to a program's main package/function, not by libraries. This gives the event subscriber complete control over the behavior of event collection. Collectors are registered via the Collect and CollectAsync functions. Each collector is registered for a given level threshold. The threshold for a collector may be updated at any time using the SetLevel function. Collect registers fully synchronous event collectors. Logging calls that match a synchronous collector's threshold block until the collector's Collect method returns successfully. This is dangerous if the Collector performs any operations that block or return errors. However, it's simple to use and understand: CollectAsync registers asynchronous collectors. It creates a buffered channel for the collector and starts a worker goroutine to service events. Logging calls return after queuing events to the collector channel. If the channel's buffer is full, the event is dropped and a drop counter is incremented atomically. This ensures asynchronous logging calls never block. The worker goroutine detects changes in the atomic drop counter and surfaces drop events as collector errors. See the cue/collector docs for details on collector error handling. When asynchronous logging is enabled, Close must be called to flush queued events on program termination. Close is safe to call even if asynchronous logging isn't enabled -- it returns immediately if no events are queued. Note that ctrl+c and kill <pid> terminate Go programs without triggering cleanup code. When using asynchronous logging, it's a good idea to register signal handlers to capture SIGINT (ctrl+c) and SIGTERM (kill <pid>). See the os/signals package docs for details. By default, cue collects a single stack frame for any event that matches a registered collector. This ensures collectors may log the file name, package, and line number for any collected event. SetFrames may be used to alter this frame count, or disable frame collection entirely. See the SetFrames function for details. When using error reporting services, SetFrames should be used to increase the errorFrames parameter from the default value of 1 to a value that provides enough stack context to successfully diagnose reported errors. This example logs to both the terminal (stdout) and to file. If the program receives SIGHUP, the file will be reopened (for log rotation). Additional context is added via the .WithValue and .WithFields Logger methods. The formatting may be changed by passing a different formatter to either collector. See the cue/format godocs for details. The context data may also be formatted as JSON for machine parsing if desired. See cue/format.JSONMessage and cue/format.JSONContext. This example shows how to use error reporting services. This example shows quite a few of the cue features: logging to a file that reopens on SIGHUP (for log rotation), logging colored output to stdout, logging to syslog, and reporting errors to Honeybadger.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Git dependencies in open source packages can introduce significant risks, including lack of version control, stability issues, dependency drift, and difficulty in auditing, making them potential targets for supply chain attacks.
Security News
Node.js has added experimental support for TypeScript, a move that highlights the growing importance of TypeScript in modern development.
Product
Check out what's new at Socket with our Product Changelog. It tracks all public-facing updates, improvements, and fixes so you can take full advantage of our features.