Legacy net/http integration guide

Add Bugsnag to your legacy net/http applications.

This integration supports Go 1.6 and earlier. For newer applications, see the updated integration guide.

Installation

Use versions 1.3.2 or earlier of the notifier with versions of Go older than 1.7.

Below you’ll find methods of getting this older version of the Go Bugsnag notifier.

Use Bugsnag with Go 1.6 and below with dep

You can learn about using dep for dependency management here.

In your Gopkg.toml file add a dependency on the 1.3.2 branch of bugsnag-go:

[[constraint]]
  name = "github.com/bugsnag/bugsnag-go"
  version = "1.3.2"

then run dep ensure to lock your version of bugsnag-go to a version that supports Go versions older than 1.7.

Use Bugsnag with Go 1.6 and below with go get

If you wish to use the built in go get command for fetching dependencies, you’ll have to manually check out an older version of the notifier and downgrade the downloaded version:

go get github.com/bugsnag/bugsnag-go
cd $GOPATH/src/github.com/bugsnag/bugsnag-go
git checkout v1.3.2
go build

Note: If you do not have the $GOPATH environment variable configured, you should replace $GOPATH with $GOROOT.

Basic configuration

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() {
        bugsnag.Configure(bugsnag.Configuration{
            APIKey:          "YOUR API KEY HERE",
            ReleaseStage:    "production",
            // The import paths for the Go packages containing your source files
            ProjectPackages: []string{"main", "github.com/org/myapp"},
            // more configuration options
        })
    
        // rest of your program.
    }
    

    NOTE: Initializing Bugsnag in a location other than the start of your application may have unintended side effects, due to the monitoring behavior of Configuration.PanicHandler, which wraps and monitors the application process. See the configuration documentation for more details.

  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))
    

Reporting unhandled panics

After completing installation and basic configuration, unhandled panics will be automatically reported. Error data will begin to appear in your project’s dashboard. To ensure panics from goroutines are handled effectively, see reporting panics from goroutines.

This feature is enabled via the Configuration.PanicHandler, which forks and monitors the application as a sub-process, reporting any unhandled panics.

Reporting handled errors

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

if err != nil {
    bugsnag.Notify(err)
}

When reporting handled errors, it’s often helpful to send us custom diagnostic data or to adjust the severity of particular errors. For more information, see the reporting handled errors reference.

Reporting panics from goroutines

Since goroutines are generally non-blocking, panics captured on a goroutine may crash the application before having the opportunity to be delivered to Bugsnag unless intentionally handled.

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.

go func() {
    defer bugsnag.AutoNotify()

    // ...
}()

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()

    // ...
}()

Sending diagnostic 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.

Custom metaData appears as tabs on error reports on your Bugsnag dashboard. You can set it by passing a bugsnag.MetaData object as rawData.

bugsnag.Notify(err,
    bugsnag.MetaData{
        "Account": {
            "Name": Account.Name,
            "Paying": Account.Plan.Premium,
        },
    })

For more information, see the reporting handled errors reference.

Identifying users

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.Notify(err,
    bugsnag.User{Id: "1234", Name: "Conrad", Email: "me@example.com"})

For more information, see the reporting handled errors reference.

Session tracking

Bugsnag can track the number of “sessions” that happen in your application. This enables Bugsnag to provide and compare stability scores between releases to help you understand the quality of your releases.

Session tracking requires version 1.4 of bugsnag-go, and is not available for legacy Go applications.

Tracking releases

Configure your app version to see the release that each error was introduced in.

bugsnag.Configure(bugsnag.Configuration{
    AppVersion: "1.2.3",
})

Then set up a build tool integration to enable linking to code in your source control provider from the releases dashboard, timeline annotations, and stack traces.

Next steps