rollbar/rollbar-go

Go client for Rollbar

rollbar-go

Rollbar is a real-time exception reporting service for Go and other languages. The Rollbar service will alert you of problems with your code and help you understand them in a ways never possible before. We love it and we hope you will too.

rollbar-go is a Golang Rollbar client that makes it easy to report errors to Rollbar with full stacktraces. Errors are sent to Rollbar asynchronously in a background goroutine.

Because Go's error type doesn't include stack information from when it was set or allocated, we use the stack information from where the error was reported.

Setup Instructions and Usage

1. Sign up for a Rollbar account
2. Follow the Usage example in our Go SDK docs to get started for your platform.

Documentation

API docs on godoc.org

Running Tests

Running tests docs on docs.rollar.com

Release History & Changelog

See our Releases page for a list of all releases, including changes.

Help / Support

If you run into any issues, please email us at [email protected]

For bug reports, please open an issue on GitHub.

Contributing

1. Fork it
2. Create your feature branch (git checkout -b my-new-feature).
3. Commit your changes (git commit -am 'Added some feature')
4. Push to the branch (git push origin my-new-feature)
5. Create new Pull Request

History

This library originated with this project github.com/stvp/rollbar. This was subsequently forked by Heroku, github.com/heroku/rollbar, and extended. Those two libraries diverged as features were added independently to both. This official library is actually a fork of the Heroku fork with some git magic to make it appear as a standalone repository along with all of that history. We then also went back to the original stvp library and brought over most of the divergent changes. Since then we have moved forward to add more functionality to this library and it is the recommended notifier for Go going forward.

rollbar-go's Issues

Support deploy tracking

Can I grab crashes in goroutines?

I use rollbar.WrapAndWait()，but cannot grab crash in goroutines?

Only collect person.id by default for person tracking

Allow the ability to send person.email and person.username, but by default we should only collect person.id going forward.

@rokob This is a top priority.

Confusion around Wait() function

I am confused about the expected properties of Wait() both for the Client type and the AsyncTransport type.

AFAICT Wait() isn't deterministic in the face of concurrency & could panic when called while errors are still being reported.

Example:
I'm running a web server. Go net/http package runs each request in its own goroutine, so any number of which can be running at any given time.
If I want to report an error in a handler and then wait the docs lead me to believe that I would use Error() and then Wait(). But there are at least two problems with that:

1. Any number of errors, upto len(Buffer) may be enqueued, and waiting to be reported, not just the error I sent.
2. calling sync.WaitGroup.Add(), while sync.WaitGroup.Wait() is being held causes a panic: https://golang.org/src/sync/waitgroup.go#L77

I have a branch that does away with these problems, but I was initially under the impression that Wait() would only be used after Close() was called, but that doesn't seem to be the case.

So, what are the expected semantics of Wait() that rollbar-go would like to provide?

Add items per minute config option

Similar to rollbar.js, the max number of items to report per minute. The limit should count uncaught errors and any direct calls.

Async transpot can panic

Due to a recursion issue we've been hitting rollbar limits. To address these issues we temporarily disabling bursting on Rollbar. Unfortunately this seems to result in a panic in the rollbar-go async client.

The fact may be that we are sending rollbar messages even though the connection has been closed. Obviously that's an issue on our end, and we're looking into that.

But the fact that a library meant for logging errors can itself cause these kinds of panics is worrying. Worst yet; because the panic happens in a subroutine we cannot do anything in our application to gracefully handle such issues in the future.

It would be nice if the rollbar-go library had a panic recovery in its subroutine. Maybe have it still default to a panic but give developers a way to override that default behavior.

Allow IP collection to be easily turned on and off in config

Keep the default IP collection what it is now, but allow the ability to turn IP collection off in the config.

@rokob This is a top priority.

Are two async transports go routines running if you create your own client?

Hey guys,

Looking at the code in this library and I notice that in rollbar.go you create a global variable std which calls NewAsync(). This method eventually creates a AsyncTransport which launches a Go routine blocking on the transport's channel.

If I was to create my own client struct, I would also import the root rollbar package and the standard logger would continue to run in the backend.

Is this by design to always provide a default logger ?

Default std async transport with dangling goroutine

Let's say I want to integrate this rollbar client to a custom logger only if the user opts for it.
The problem is that this line

std = NewAsync("", "development", "", hostname, "")

always gets executed just importing the library in another package, even though I may not use any other functionality (eg. if a user of my custom logger doesn't need rollbar at all).

This results in a dangling goroutine like the following

1 @ 0x45780b 0x4578b3 0x42e88b 0x42e66b 0x9a3404 0x4865c1
#    0x9a3403    github.com/rollbar/rollbar-go.NewAsyncTransport.func1+0x83    /home/gian/Documents/Projects/go/pkg/mod/github.com/rollbar/[email protected]/async_transport.go:51

generated by this portion of code.

It whould be nice to have a constructor of the rollbar client instead of having one that is created by default, with no way of interrupting that goroutine.

Recommended go client

It seems this isn't maintained and readme references stvp/rollbar in usage example. However, no mention of status of this repo and relation of above repo.

Could you briefly explain status/expectations and if needed, please direct people to above client with a small note in readme ? Thanks!

Ability to transform payload

Implement a transform function, similar to rollbar.js

Support a checkIgnore function

Other libraries allow for a function to be called before posting to Rollbar to check if the given error should be ignored and not sent to Rollbar. This is a convenient hook for doing a variety of customization that would be nice to have.

Make the repo commitizen-friendly

Add https://github.com/commitizen/cz-cli to repo's dependencies.

Add config for commitizen to use https://www.npmjs.com/package/cz-conventional-changelog

This will provide the git cz command which makes creating conventional-changelog commits easy

This also needs we will need to adjust our contributing instructions for the community

Bug: `LambdaWrapper` panics at runtime when panic occurs inside a lambda handler with multiple return values

When a lambda handler with several return values is wrapped using LambdaWrapper, and a panic is called from inside the handler, runtime error "reflect: wrong return count from function created by MakeFunc" occurs

Example of lambda handler:

client.LambdaWrapper(func() (string, error) {
	panic(err)
})

Here's a unit test to prove the bug

#client_test.go

func TestLambdaWrapperWithErrorAndMultipleReturnValues(t *testing.T) {
	client := testClient()
	err := errors.New("bork")

	defer func() {
		recoveredError := recover()

		if recoveredError != err {
			if recoveredError == nil {
				t.Error("Expected wrapper to bubble up the custom panic error")
			} else {
				t.Errorf("Unexpected panic %s", recoveredError)
			}
		}

		if transport, ok := client.Transport.(*TestTransport); ok {
			if transport.Body == nil {
				t.Error("Expected Body to be present")
			}
			if !transport.WaitCalled {
				t.Error("Expected wait to be called")
			}
		} else {
			t.Fail()
		}
	}()

	handler := client.LambdaWrapper(func() (string, error) {
		panic(err)
		return "", nil
	})
	fn := reflect.ValueOf(handler)
	var args []reflect.Value
	fn.Call(args)
}

Option to use deepest stack trace possible

At the moment, if the cause error does not have a stack trace, rollbar-go builds a stack trace itself. In an application where rollbar-go is used at a very high level, e.g. at the root of the application execution, this self-built stack trace becomes almost useless. Instead, I think it would be very useful if there was an option (or simply the default behavior) that enables rollbar-go to save the deepest stack trace it can find instead of just checking the cause error. This shouldn't be very complicated to implement based on the current code base, and I think the sample use case I've outlined below is a very common one.

Sample use case:
In your application, you do all the rollbar reporting at the root, as in, you report all errors that surface up to main(). Furthermore, you also capture a stack trace every time you create/wrap an error (e.g. if pkg/errors is used, this happens). Whenever a 3rd-party error (for example, one that lacks a stack trace) surfaces into your application, it will get a stack trace attached to it, showing where this error "entered" your code. With the above addition, it will now be much clearer to see in Rollbar where in your code this error surfaced, and combined with the error message, help you resolve it as quickly as possible. It will also make the automatic Rollbar fingerprinting much more accurate since it will be able to distinguish errors in different parts of the code with the same error message/class etc.

Add transform option

Similarly to the rest of the SDKs, it would be helpful to add the transform function.

One use case is so that users can attach a fingerprint key to the payload, so that the occurrence will be grouped by this fingerprint key as opposed to the default fingerprinting scheme.

See: https://docs.rollbar.com/docs/grouping-algorithm#section-customizing-fingerprints-in-code

Capture local variables

Similar to pyrollbar. See 'locals' here: https://docs.rollbar.com/docs/python#section-configuration-reference

Remove global mutable state

Hi,

I understand this is currently just in beta. Are you open to rethinking the API? I forked a similar library to remove package global state. You can read more about package global state at https://dave.cheney.net/2017/06/11/go-without-package-scoped-variables or https://peter.bourgon.org/blog/2017/06/09/theory-of-modern-go.html

I worry the library, currently designed, forces a large amount of global mutable state which could limit usage.

The library also assumes concurrency with Wait. Ideally this could be handed off or be a concern separate from the library. For example, someone else could have other concurrency ideas or fallback ideas.

I think ideally the client library should be simple and blocking, with the ability to augment that behavior. Here is the API for my fork.

		c := Client{
			Endpoint:    s.URL,
			AccessToken: "abc",
		}

Then, the library mirrors rollbar's real API allowing people to send values and even inspect results.

			resp, err := c.Message(ctx, Debug, "TestCodeVersion")
			So(err, ShouldBeNil)
			So(resp.Result.UUID, ShouldNotEqual, "")

Truncate large payloads to ensure we don't drop them

go reporting the compile error on the example.

Hi,

I have followed the document instruction to use Rollbar Go notifier. I have observed following issue.

1. With the example that you have mentioned in the documentation. It's generating compile time error.

func main() {
  rollbar.SetToken("MY_TOKEN")
  rollbar.SetEnvironment("production")  // defaults to "development"
  rollbar.SetCodeVersion("v2")   // optional Git hash/branch/tag (required for GitHub integration)
  rollbar.SetServerHost("web.1")   // optional override; defaults to hostname
  rollbar.SetServerRoot("github.com/heroku/myproject") // path of project (required for GitHub integration   and non-project stacktrace collapsing)

 result, err := DoSomething()
 if err != nil {
    rollbar.Critical(err)
 }
  rollbar.Info("Message body goes here")
  rollbar.Wait()
}

It's generating compile time error. I have made my own example which is working perfectly fine and able to send the log to the rollbar console. The example is.

package main
import (
  "github.com/rollbar/rollbar-go"
  "errors"
  "fmt"
  "time"
)
func recoverError() {  
   if r := recover(); r!= nil {
       fmt.Println(r)
       rollbar.Critical(r)
       rollbar.Wait()    
   }
}

func main() {
    defer catchError()
    rollbar.SetToken("MY-TOKEN")
    rollbar.SetEnvironment("production")
    var timer *time.Timer = nil
    timer.Reset(10) // crash
}

2. With the Notifier integration. We need to run following command to import rollbar package inside the code.

go get github.com/rollbar/rollbar-go

I think you have forgotten to add in the documentation. I have tried without go get command it was throwing package error.

Thanks and regards.

Wahid Ali

Prevent rollbar-go to start a Client by default

The library is initializing an AsyncClient , by assigning a default value to the std variable in rollbar.go

Even if one would create his own client, a default client is created and assigned to std.

This is quite problematic, i.e. when building tests, as a go routine is started by default, preventing to to verify your application is leaking goroutines.

The only workaround at the moment is to call Close() to stop the default Client.

A way to disable this feature would be nice, i.e. when one disable the default client using SetEnabled(false).

set a new transport

The way to set a new transport would be something like:
rollbar.std.Transport = NewTransport

However, this fails because std is not exported and therefore not accessible to the user. (This could also be done with an exported setter function, but that doesn't exist either, so either way a necessary interface appears missing.)

This looks like an oversight, and probably no one has ever set a new transport, and this is just now being discovered.

Until there is a fix, they should try to use WrapAndWait or a similar idea. If they run into issues with this, they can send an example and maybe we can hep work through it.

https://app.intercom.io/a/apps/rlisg82q/inbox/inbox/849049/conversations/23277315799

Add enabled/disabled config option

Stop hacker's from thefting

Thefting me from have an life and an complete place to go bye there lying issues cause of mine man wonts to break mine heart with abuse that was supposed to been mine friend since I was an kid and he's also homosexual.

Add SetFramework() Config Option

internal: https://app.intercom.io/a/apps/rlisg82q/inbox/inbox/813342/conversations/18079663554

Segfault when using client

This code in main() yields a segfault:

  var rc = rollbar.Client{}
  rc.Wait()

yields this panic error:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xf78dc2]

goroutine 1 [running]:
github.com/rollbar/rollbar-go.(*Client).Wait(...)
        /home/alex/go/pkg/mod/github.com/rollbar/[email protected]/client.go:582
main.main()

Item POST timeouts

I've been seeing a lot of these connection timeouts lately (both in staging and production), and it's accompanied by missing items in Rollbar.

2018/07/04 04:48:01 Rollbar error: POST failed: Post https://api.rollbar.com/api/1/item/: net/http: TLS handshake timeout
2018/07/04 16:50:43 Rollbar error: POST failed: Post https://api.rollbar.com/api/1/item/: dial tcp 35.201.81.77:443: i/o timeout
2018/07/05 02:04:33 Rollbar error: POST failed: Post https://api.rollbar.com/api/1/item/: dial tcp 35.201.81.77:443: context deadline exceeded
2018/07/05 09:50:04 Rollbar error: POST failed: Post https://api.rollbar.com/api/1/item/: dial tcp 35.201.81.77:443: i/o timeout
2018/07/05 17:12:59 Rollbar error: POST failed: Post https://api.rollbar.com/api/1/item/: dial tcp 35.201.81.77:443: i/o timeout
2018/07/06 05:39:28 Rollbar error: POST failed: Post https://api.rollbar.com/api/1/item/: EOF
2018/07/06 07:01:41 Rollbar error: POST failed: Post https://api.rollbar.com/api/1/item/: net/http: TLS handshake timeout
2018/07/06 14:08:05 Rollbar error: POST failed: Post https://api.rollbar.com/api/1/item/: net/http: TLS handshake timeout
2018/07/06 14:43:16 Rollbar error: POST failed: Post https://api.rollbar.com/api/1/item/: dial tcp 35.201.81.77:443: i/o timeout
2018/07/06 20:21:44 Rollbar error: POST failed: Post https://api.rollbar.com/api/1/item/: net/http: TLS handshake timeout
2018/07/06 20:38:45 Rollbar error: POST failed: Post https://api.rollbar.com/api/1/item/: dial tcp: i/o timeout
2018/07/06 21:58:07 Rollbar error: POST failed: Post https://api.rollbar.com/api/1/item/: net/http: TLS handshake timeout
2018/07/07 05:22:47 Rollbar error: POST failed: Post https://api.rollbar.com/api/1/item/: net/http: TLS handshake timeout
2018/07/07 15:12:40 Rollbar error: POST failed: Post https://api.rollbar.com/api/1/item/: net/http: TLS handshake timeout
2018/07/07 21:22:13 Rollbar error: POST failed: Post https://api.rollbar.com/api/1/item/: net/http: TLS handshake timeout
2018/07/08 18:25:06 Rollbar error: POST failed: Post https://api.rollbar.com/api/1/item/: dial tcp: i/o timeout
2018/07/09 00:05:10 Rollbar error: POST failed: Post https://api.rollbar.com/api/1/item/: net/http: TLS handshake timeout
2018/07/09 00:45:44 Rollbar error: POST failed: Post https://api.rollbar.com/api/1/item/: net/http: TLS handshake timeout
2018/07/09 04:07:45 Rollbar error: POST failed: Post https://api.rollbar.com/api/1/item/: net/http: TLS handshake timeout
2018/07/09 08:07:26 Rollbar error: POST failed: Post https://api.rollbar.com/api/1/item/: net/http: TLS handshake timeout
2018/07/09 15:44:34 Rollbar error: POST failed: Post https://api.rollbar.com/api/1/item/: net/http: TLS handshake timeout
2018/07/09 23:10:37 Rollbar error: POST failed: Post https://api.rollbar.com/api/1/item/: dial tcp: i/o timeout
2018/07/09 23:14:42 Rollbar error: POST failed: Post https://api.rollbar.com/api/1/item/: dial tcp 35.201.81.77:443: i/o timeout
2018/07/10 01:59:07 Rollbar error: POST failed: Post https://api.rollbar.com/api/1/item/: EOF
2018/07/10 01:59:21 Rollbar error: POST failed: Post https://api.rollbar.com/api/1/item/: net/http: TLS handshake timeout
2018/07/10 03:33:42 Rollbar error: POST failed: Post https://api.rollbar.com/api/1/item/: net/http: TLS handshake timeout
2018/07/10 07:38:57 Rollbar error: POST failed: Post https://api.rollbar.com/api/1/item/: dial tcp: i/o timeout
2018/07/10 12:06:06 Rollbar error: POST failed: Post https://api.rollbar.com/api/1/item/: net/http: TLS handshake timeout
2018/07/10 13:29:17 Rollbar error: POST failed: Post https://api.rollbar.com/api/1/item/: net/http: TLS handshake timeout
2018/07/10 17:44:34 Rollbar error: POST failed: Post https://api.rollbar.com/api/1/item/: dial tcp 35.201.81.77:443: i/o timeout

A couple things here:

1. It sure seems like these would be due to problems with the api.rollbar.com server, as some items get through successfully. Can somebody check whether there were high response times during/around those errors?
2. Right now those error items are getting lost. They should probably be re-queued for transport.
3. From a pragmatic standpoint, it would also be nice if when an item failed to send it could be dumped to stderr. I was relying on rollbar instead of having verbose server logs, but since they don't make it to the rollbar service I just don't see any information on those errors.

(I was referred here by support)

Add capture uncaught config option

Similar to rollbar.js, the ability to turn on/off uncaught error reporting.

Add support for FluentD

We use Rollbar & FluentD a lot in our PHP services, but that is not supported in Golang. It'd be a very nice good-to-have

Add support for using a proxy

Unable to get IP addresses in gin middleware.

I have written following middleware based on github.com/gin-contrib/rollbar, I would like to have IP address from the context be sent to rollbar. But I am only able to do it as a custom variable.

func Recovery(onlyCrashes bool) gin.HandlerFunc {

	return func(c *gin.Context) {
		defer func() {

			if rval := recover(); rval != nil {
				debug.PrintStack()

				// rollbar.SetEndpoint(c.Request.RequestURI)
				rollbar.SetItemsPerMinute(20)
				rollbar.SetPerson(strconv.FormatInt(c.Keys["remote_id"].(int64), 10), "", "")
				rollbar.Critical(errors.New(fmt.Sprint(rval)), map[string]interface{}{
					"endpoint":  c.Request.RequestURI,
					"person.Id": c.Keys["remote_id"].(int64),
                                        "IPAddress": c.ClientIP(),
				})

				c.AbortWithStatus(http.StatusInternalServerError)
			}

			if !onlyCrashes {
				for _, item := range c.Errors {
					rollbar.Error(item.Err, map[string]string{
						"meta":     fmt.Sprint(item.Meta),
						"endpoint": c.Request.RequestURI,
					})
				}
			}
		}()

		c.Next()
	}
}

How can I properly log IP address in gin.context on rollbar. This doesn't show up in IPAddresses Tab on rollbar console.

Will you release this pkg anymore?

I want to take this commit #69 into my project. This package has stopped with the release of v1.2.0, but its commit is not included in v1.2.0.

Will you release this package anymore? Or please let me know if there is another method to use it.

Best regards.

client/transport.Close() does not support context

The close operation for client (and transport as well) should take context argument to make it possible to interrupt the method if it takes to long to send/close everything.

Add max items config option

Similar to rollbar.js maxItems

Telemetry support

Similar to telemetry in rollbar.js.

This needs to include the config options for enabling/disabling telemetry and scrubbing telemetry data.

Breaking API change with release of v1.4.3

Not exporting the type returned by the rollbar New* factory functions is a pretty significant breaking change, and prevents developers from embedding the client in a struct or casting it out of a context.

I think this change should be reconsidered.

Setup CI via travis or circle

Take advantage of new Go 1.13 Unwrap method

Go 1.13 is out, and now has some new stuff in the standard library related to error unwrapping. While Unwrap is not part of the error interface, it will probably be implemented in many custom errors going forward.

Because this is a thing in the standard library, I'm wondering if you may want to pull the Stacker part of CauseStacker into its own interface. If Causer and Stacker were their own interfaces, you could still generate a trace_chain, but you could then also modify getCause to do something like this:

func getCause(err error) error {
	if cs, ok := err.(Causer); ok {
		return cs.Cause()
	}
	if unwrapped := errors.Unwrap(err); unwrapped != nil {
		return unwrapped
	}
	return nil
}

At some point you could potentially even deprecate Causer in favor of using the standard Unwrap.

Also, while directly using the standard library's errors.Unwrap would break compatibility with versions older than 1.13, the x/errors package includes an equivalent function for compatibility, which would allow you to move forward with this while supporting older versions.

Looking forward to your thoughts!

Add scrub whitelist config option

Similar to Rollbar-PHP's scrub_whitelist: an array of fields that you do NOT to be scrubbed even if they match entries in scrub_fields.

Use runtime.Frames instead of rollbar.Stack in CauseStacker interface

When using the rollbar-go library, it might be useful for applications to generate their own stacktraces elsewhere in the applications (before the error gets to Rollbar). This is especially useful if using Logrus to handle all logs (including errors).

Right now the CauseStacker Stack() method returns rollbar.Stack. This creates a dependency on the rollbar sdk in a library that would otherwise not need it.

Consider changing this to use the runtime.Frames and instead translate that internally to a JSON serializable struct for the payload.

Thoughts?

Anonymize IP address config option

We need to allow users the option of collecting IP addresses and anonymizing them. Let's anonymize the IPs as described here: https://support.google.com/analytics/answer/2763052

@rokob This is a top priority.

Point docs from README to Rollbar's site

Keep the basic getting started info, then link to Rollbar's docs.

Add log level config option

Similar to rollbar.js logLevel

Support setting Person information

Unclear how to send messages with custom client instance

So this works fine:

  rollbar.SetToken("MY_TOKEN")
  rollbar.Info("Message body goes here")
  rollbar.Critical("Critical body goes here")
  rollbar.Wait()

But in general I would prefer to create a specific instance:

  var rc = rollbar.Client{}
  rc.SetToken("MY_TOKEN")
  rc.Info() // nope :(
  rc.Critical() // nope :(
  rc.Wait()

it's unclear how to send events now! :(

Also capture stack on non-error panics

When Wrap() catches a panic that is not an instance of err, it doesn't include the stack trace in the report. runtime.Stack() can be used to capture the stack trace for the current panic, see https://groups.google.com/forum/#!topic/golang-nuts/MB8GyW5j2UY

Add support for `x-forwarded-for` header

Currently there is no way to manually specify an IP address, only to specify a request. The problem this creates is that rollbar does not seem to make any attempt to infer the IP address beyond looking at the remote address. In many large scale deployments the IP address is set via an x-forwarded-for header because the remote address is that of a load balancer.

So, please add support for the x-forwarded-for header. Or give us the ability to manually set the IP address.

Thanks!

422 Unprocessable Entity after Upgrading to v1.4.2

Hey folks, just an FYI that following the upgrade from v1.4.1 to v1.4.2 our Rollbar client's starting logging a 422 error resulting in error reporting failures.

Any example for adding rollbar to serverless ?

I am using below serverless framework with golang.

https://serverless.com

https://github.com/yunspace/serverless-golang

Does any know how to add global error handling with rollbar & this framework?

Document all the things