levinalex / bugsnag-go

Automatic panic monitoring for golang, net/http and revel

Home Page:https://bugsnag.com/docs/notifiers/go

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Bugsnag Notifier for Golang

The Bugsnag Notifier for Golang gives you instant notification of panics, or unexpected errors, in your golang app. Any unhandled panics will trigger a notification to be sent to your Bugsnag project.

Bugsnag captures errors in real-time from your web, mobile and desktop applications, helping you to understand and resolve them as fast as possible. Create a free account to start capturing exceptions from your applications.

How to Install

  1. Download the code

    go get github.com/bugsnag/bugsnag-go

Using with net/http apps

For a golang app based on net/http, integrating Bugsnag takes two steps. You should also use these instructions if you're using the gorilla toolkit, or the pat muxer.

  1. Configure bugsnag at the start of your main() function:

    import "github.com/bugsnag/bugsnag-go"
    func main() {
            APIKey: "YOUR_API_KEY_HERE",
            ReleaseStage: "production",
            // more configuration options
        // rest of your program.
  2. Wrap your server in a bugsnag.Handler

    // a. If you're using the builtin http mux, you can just pass
    //    bugsnag.Handler(nil) to http.ListenAndServer
    http.ListenAndServe(":8080", bugsnag.Handler(nil))
    // b. If you're creating a server manually yourself, you can set
    //    its handlers the same way
    srv := http.Server{
        Handler: bugsnag.Handler(nil)
    // c. If you're not using the builtin http mux, wrap your own handler
    // (though make sure that it doesn't already catch panics)
    http.ListenAndServe(":8080", bugsnag.Handler(handler))

Using with Revel apps

There are two steps to get panic handling in revel apps.

  1. Add the bugsnagrevel.Filter immediately after the revel.PanicFilter in app/init.go:

    import "github.com/bugsnag/bugsnag-go/revel"
    revel.Filters = []revel.Filter{
        // ...
  2. Set bugsnag.apikey in the top section of conf/app.conf.


Using with martini apps

  1. Add bugsnagmartini.AutoNotify immediately after the martini.Recovery middleware in main.go. This causes unhandled panics to notify bugsnag.

    import "github.com/bugsnag/bugsnag-go/martini"
    func main() {
            APIKey: "YOUR_API_KEY_HERE",
  2. Use bugsnag from the context injection if you need to notify about non-fatal errors.

    func MyHandler(r *http.Request, bugsnag *bugsnag.Notifier) string {

Using with Google App Engine

  1. Configure bugsnag at the start of your init() function:

    import "github.com/bugsnag/bugsnag-go"
    func init() {
            APIKey: "YOUR_API_KEY_HERE",
        // ...
  2. Wrap every http.Handler or http.HandlerFunc with Bugsnag:

    // a. If you're using HandlerFuncs
    http.HandleFunc("/", bugsnag.HandlerFunc(
        func (w http.ResponseWriter, r *http.Request) {
            // ...
    // b. If you're using Handlers
    http.Handle("/", bugsnag.Handler(myHttpHandler))
  3. In order to use Bugsnag, you must provide the current appengine.Context, or current *http.Request as rawData (This is done automatically for bugsnag.Handler and bugsnag.HandlerFunc). The easiest way to do this is to create a new instance of the notifier.

    c := appengine.NewContext(r)
    notifier := bugsnag.New(c)
    if err != nil {
    go func () {
        defer notifier.Recover()
        // ...

Notifying Bugsnag manually

Bugsnag will automatically handle any panics that crash your program and notify you of them. If you've integrated with revel or net/http, then you'll also be notified of any panics() that happen while processing a request.

Sometimes however it's useful to manually notify Bugsnag of a problem. To do this, call bugsnag.Notify()

if err != nil {

Manual panic handling

To avoid a panic in a goroutine from crashing your entire app, you can use bugsnag.Recover() to stop a panic from unwinding the stack any further. When Recover() is hit, it will send any current panic to Bugsnag and then stop panicking. This is most useful at the start of a goroutine:

go func() {
    defer bugsnag.Recover()

    // ...

Alternatively you can use bugsnag.AutoNotify() to notify bugsnag of a panic while letting the program continue to panic. This is useful if you're using a Framework that already has some handling of panics and you are retrofitting bugsnag support.

defer bugsnag.AutoNotify()

Sending Custom Data

Most functions in the Bugsnag API, including bugsnag.Notify(), bugsnag.Recover(), bugsnag.AutoNotify(), and bugsnag.Handler() let you attach data to the notifications that they send. To do this you pass in rawData, which can be any of the supported types listed here. To add support for more types of rawData see OnBeforeNotify.

Custom MetaData

Custom metaData appears as tabs on Bugsnag.com. You can set it by passing a bugsnag.MetaData object as rawData.

        "Account": {
            "Name": Account.Name,
            "Paying": Account.Plan.Premium,

Request data

Bugsnag can extract interesting data from *http.Request objects, and *revel.Controller objects. These are automatically passed in when handling panics, and you can pass them yourself.

func (w http.ResponseWriter, r *http.Request) {
    bugsnag.Notify(err, r)

User data

User data is searchable, and the Id powers the count of users affected. You can set which user an error affects by passing a bugsnag.User object as rawData.

    bugsnag.User{Id: "1234", Name: "Conrad", Email: "me@cirw.in"})

Error Class

Errors in your Bugsnag dashboard are grouped by their "error class" and by line number. You can override the error class by passing a bugsnag.ErrorClass object as rawData.

bugsnag.Notify(err, bugsnag.ErrorClass{"I/O Timeout"})


The context shows up prominently in the list view so that you can get an idea of where a problem occurred. You can set it by passing a bugsnag.Context object as rawData.

bugsnag.Notify(err, bugsnag.Context{"backgroundJob"})


Bugsnag supports three severities, SeverityError, SeverityWarning, and SeverityInfo. You can set the severity of an error by passing one of these objects as rawData.

bugsnag.Notify(err, bugsnag.SeverityInfo)


You must call bugsnag.Configure() at the start of your program to use Bugsnag, you pass it a bugsnag.Configuration object containing any of the following values.


The Bugsnag API key can be found on your Bugsnag dashboard under "Settings".



The Bugsnag endpoint defaults to https://notify.bugsnag.com/. If you're using Bugsnag enterprise, you should set this to the endpoint of your local instance.

    Endpoint: "http://bugsnag.internal:49000/",


The ReleaseStage tracks where your app is deployed. You should set this to production, staging, development or similar as appropriate.

    ReleaseStage: "development",


The list of ReleaseStages to notify in. By default Bugsnag will notify you in all release stages, but you can use this to silence development errors.

    NotifyReleaseStages: []string{"production", "staging"},


If you use a versioning scheme for deploys of your app, Bugsnag can use the AppVersion to only re-open errors if they occur in later version of the app.

    AppVersion: "1.2.3",


The hostname is used to track where exceptions are coming from in the Bugsnag dashboard. The default value is obtained from os.Hostname() so you won't often need to change this.

    Hostname: "go1",


In order to determine where a crash happens Bugsnag needs to know which packages you consider to be part of your app (as opposed to a library). By default this is set to []string{"main*"}. Strings are matched to package names using filepath.Match.

    ProjectPackages: []string{"main", "github.com/domain/myapp/*"},


Sometimes sensitive data is accidentally included in Bugsnag MetaData. You can remove it by setting ParamsFilters. Any key in the MetaData that includes any string in the filters will be redacted. The default is []string{"password", "secret"}, which prevents fields like password, password_confirmation and secret_answer from being sent.

    ParamsFilters: []string{"password", "secret"},


The Logger to write to in case of an error inside Bugsnag. This defaults to the global logger.

    Logger: app.Logger,


The first time Bugsnag is configured, it wraps the running program in a panic handler using panicwrap. This forks a sub-process which monitors unhandled panics. To prevent this, set PanicHandler to func() {} the first time you call bugsnag.Configure. This will prevent bugsnag from being able to notify you about unhandled panics.

    PanicHandler: func() {},


Bugsnag usually starts a new goroutine before sending notifications. This means that notifications can be lost if you do a bugsnag.Notify and then immediately os.Exit. To avoid this problem, set Bugsnag to Synchronous (or just panic() instead ;).

    Synchronous: true

Or just for one error:

bugsnag.Notify(err, bugsnag.Configuration{Synchronous: true})


The transport configures how Bugsnag makes http requests. By default we use http.DefaultTransport which handles HTTP proxies automatically using the $HTTP_PROXY environment variable.

    Transport: http.DefaultTransport,

Custom data with OnBeforeNotify

While it's nice that you can pass MetaData directly into bugsnag.Notify, bugsnag.AutoNotify, and bugsnag.Recover, this can be a bit cumbersome and inefficient — you're constructing the meta-data whether or not it will actually be used. A better idea is to pass raw data in to these functions, and add an OnBeforeNotify filter that converts them into MetaData.

For example, lets say our system processes jobs:

type Job struct{
    Retry     bool
    UserId    string
    UserEmail string
    Name      string
    Params    map[string]string

You can pass a job directly into Bugsnag.notify:

bugsnag.Notify(err, job)

And then add a filter to extract information from that job and attach it to the Bugsnag event:

    func(event *bugsnag.Event, config *bugsnag.Configuration) error {

        // Search all the RawData for any *Job pointers that we're passed in
        // to bugsnag.Notify() and friends.
        for _, datum := range event.RawData {
            if job, ok := datum.(*Job); ok {
                // don't notify bugsnag about errors in retries
                if job.Retry {
                    return fmt.Errorf("not notifying about retried jobs")

                // add the job as a tab on Bugsnag.com
                event.MetaData.AddStruct("Job", job)

                // set the user correctly
                event.User = &User{Id: job.UserId, Email: job.UserEmail}

        // continue notifying as normal
        return nil

Advanced Usage

If you want to have multiple different configurations around in one program, you can use bugsnag.New() to create multiple independent instances of Bugsnag. You can use these without calling bugsnag.Configure(), but bear in mind that until you call bugsnag.Configure() unhandled panics will not be sent to bugsnag.

notifier := bugsnag.New(bugsnag.Configuration{

In fact any place that lets you pass in rawData also allows you to pass in configuration. For example to send http errors to one bugsnag project, you could do:

bugsnag.Handler(nil, bugsnag.Configuration{APIKey: "YOUR_OTHER_API_KEY"})


If you need to override Bugsnag's grouping algorithm, you can set the GroupingHash in an OnBeforeNotify:

    func (event *bugsnag.Event, config *bugsnag.Configuration) error {
        event.GroupingHash = calculateGroupingHash(event)
        return nil

Skipping lines in stacktrace

If you have your own logging wrapper all of your errors will appear to originate from inside it. You can avoid this problem by constructing an error with a stacktrace manually, and then passing that to Bugsnag.notify:

import (

func LogError(e error) {
    // 1 removes one line of stacktrace, so the caller of LogError
    // will be at the top.
    e = errors.New(e, 1)
ezoic increase your site revenue


Automatic panic monitoring for golang, net/http and revel


License:MIT License


Language:Go 100.0%Language:Makefile 0.0%