rollbar / rollbar-go Goto Github PK
View Code? Open in Web Editor NEWGo client for Rollbar
Home Page: https://docs.rollbar.com/docs/go
License: MIT License
Go client for Rollbar
Home Page: https://docs.rollbar.com/docs/go
License: MIT License
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, "")
Similar to telemetry in rollbar.js.
This needs to include the config options for enabling/disabling telemetry and scrubbing telemetry data.
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
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.
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.
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()
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.
Similar to rollbar.js, the ability to turn on/off uncaught error reporting.
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:
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?
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.
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.
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)
}
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?
I use rollbar.WrapAndWait(),but cannot grab crash in goroutines?
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!
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.
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
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.
I am using below serverless framework with golang.
https://github.com/yunspace/serverless-golang
Does any know how to add global error handling with rollbar & this framework?
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!
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.
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! :(
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!
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.
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
Similar to rollbar.js, the max number of items to report per minute. The limit should count uncaught errors and any direct calls.
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
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.
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
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.
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.
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.
Similar to rollbar.js maxItems
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 ?
Keep the basic getting started info, then link to Rollbar's docs.
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.
Implement a transform function, similar to rollbar.js
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).
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:
(I was referred here by support)
Similar to pyrollbar. See 'locals' here: https://docs.rollbar.com/docs/python#section-configuration-reference
Similar to rollbar.js logLevel
Hi,
I have followed the document instruction to use Rollbar Go notifier. I have observed following issue.
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
}
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.