-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Apex log integration(Initial commit) #220
Conversation
apexlog/apexlog.go
Outdated
// | ||
// Valid names are "debug" "info", "warning", "error", and "fatal". If the name is not | ||
// recognized, "error" severity is used. | ||
func setGobrakeSeverity(severity string) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This name is misleading because it doesn't actually set Gobrake's severity (the library, or the notifier). It just sets state in our handler.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
changed the name.
apexlog/apexlog.go
Outdated
|
||
msg := fmt.Sprint(args...) | ||
|
||
var theErr error |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have never seen this name being used in Go. Can we use the standard name err
instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
apexlog/apexlog.go
Outdated
} else { | ||
notice = Gobrake.Notice(msg, req, depth) | ||
} | ||
notice.Context["severity"] = severityName[s] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If s
implemented String()
, we could call:
notice.Context["severity"] = severityName[s] | |
notice.Context["severity"] = s.String() |
apexlog/apexlog.go
Outdated
} | ||
|
||
var notice *gobrake.Notice | ||
if theErr != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since you use if else
... you can flip the branches so that we don't negate without a good reason. It's just easier to read if this... then that
vs if not this... then that
.
examples/apexlog/main.go
Outdated
} | ||
}() | ||
|
||
select {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This example looks rather complex IMO. What we could do is to:
- Set severity to
warning
- Send a debug log and explain it won't be delivered
- Send a fatal log and explain that it will be delivered
- Set severity to
debug
- Send a debug log and explain that it will be delivered
No need for goroutines.
apexlog/apexlog.go
Outdated
func New(notifier *gobrake.Notifier, severity string) *Handler { | ||
setGobrakeSeverity(severity) | ||
var v Handler | ||
Gobrake = notifier |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What will happen if two projects use this apexlog
integration? Probably only one integration will win and the other one will stop sending logs. Can we make sure we support this scenario?
I am actually not sure why we store notifier
on package-level. We store it on the handler itself on the next line, so why not to use it from there?
examples/apexlog/main.go
Outdated
) | ||
|
||
func main() { | ||
// Initialize the airbrake notifier |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is still present.
examples/apexlog/main.go
Outdated
// Insert the airbrake notifier instance and set the severity level. | ||
// The acceptable severity levels are "debug" "info", "warning", "error", and "fatal". | ||
// If the severity level is not recognized, "error" severity is used. | ||
airbrakeHandler := apexlog.New(airbrake, "error") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We still pass a string instead of severity
.
apexlog/apexlog.go
Outdated
|
||
// HandleLog method is used for sending notices to airbrake. | ||
func (h *Handler) HandleLog(e *log.Entry) error { | ||
h.notifyAirbrake(0, severity(e.Level), e.Message) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't need to have 0
(depth) as a function parameter because it never changes. Let's just remove it and hardcode it to 0 on line 93.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's just a variable, so that we can build on it in future if we want to or if we want to add some another variable and need some reference.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you provide an example of a possible scenario in the future where we want to pass anything other than 0 here?
examples/apexlog/main.go
Outdated
"user": "tobi", | ||
}) | ||
|
||
for range time.Tick(time.Millisecond * 500) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need a timer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This example is use used for the apex/log package(the one they used in their package), so we can show that the middleware will work without making any modifications to apex/log and it will be easier for developers to understand who are using apex/log already.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I gave this a run locally and I sent 160 errors to Airbrake within ~15 seconds. I don't think it's a good idea to run this on a loop because our users can leave this running for some time and then they will run out of their error quota or will have to pay more than needed.
I think we need to print these messages without a loop and make the program exit by itself so that we won't waste error quota.
Is this ready for another review? |
Yes |
Ok, thanks. Please write "PTAL" once you are done with the code. This will help me understand the state of the PR 🙂 |
examples/apexlog/main.go
Outdated
"user": "tobi", | ||
}) | ||
|
||
for range time.Tick(time.Millisecond * 500) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I gave this a run locally and I sent 160 errors to Airbrake within ~15 seconds. I don't think it's a good idea to run this on a loop because our users can leave this running for some time and then they will run out of their error quota or will have to pay more than needed.
I think we need to print these messages without a loop and make the program exit by itself so that we won't waste error quota.
examples/apexlog/main.go
Outdated
"user": "tobi", | ||
}) | ||
|
||
fmt.Println("Check your Airbrake dashboard at https://airbrake.io/projects/:ProjectId to see these log messages") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- We should print the real project id being used so that users can actually click on the link
- It would be nice to explain that some of the log messages won't be delivered to Airbrake due to severity settings. As of now this message implies all of the messages will be delivered, which isn't actually the case
apexlog/apexlog.go
Outdated
InfoLog: "info", | ||
WarnLog: "warn", | ||
ErrorLog: "error", | ||
FatalLog: "fatal", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When I send ctx.Fatal("oops")
, it exits the program but never reports anything to Airbrake.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The apex/log package exits the application internally denying us to log it in airbrake
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we cannot support this, we shouldn't be exposing this severity in our integration because it doesn't do anything useful. In doing so, we should probably document this behavior. If I set up FataLog
severity, nothing at all would be sent to Airbrake, which is misleading (I would think that only fatal logs would be sent).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I will remove that.
PTAL |
Did you see these comments?
They don't appear to be resolved. |
PTAL |
a531b64
to
a75332d
Compare
No description provided.