Add sentry #981
Add sentry #981
Conversation
iAdramelk
force-pushed
the
sentry-integration
branch
from
021489b to
fc05835
Compare
iAdramelk
force-pushed
the
sentry-integration
branch
from
fc05835 to
0d2d1df
Compare
|
Interesting. So Sentry is a SRE/APM dashboard? I quickly read https://blog.sentry.io/2018/03/06/the-sentry-workflow but would be great to know what this is all about 🙂 |
|
@jorgeorpinel , yep. Pretty much it. We can collect info about user's javascirpt errors with it, see information about environment, stack traces, etc. |
| @@ -0,0 +1,14 @@ | |||
| /* eslint-env node */ | |||
|
|
|||
| const withSourceMaps = require('@zeit/next-source-maps') | |||
There was a problem hiding this comment.
I see @zeit/next-source-maps was also added here. Is this specifically just a nice addition for Sentry logs/traces?
There was a problem hiding this comment.
Source maps is a mechanism to map bundled and minified code with the original source files. If we just run sentry as it is, it will show errors like: You nave an error on line 1, symbol 3454560 in the gX method. Source maps will ideally show us original file, line and method name. (But right now it's looks like it didn't work correctly)
It's not strictly related to Sentry and is used for example by browser Dev Tools, but it make using Sentry more convenient.
There was a problem hiding this comment.
Right, I did read about source maps and it seems like a great feature. I was just wondering if this was added specifically for Sentry traces or whether it can also be used on the Browser now.
There was a problem hiding this comment.
Well, we should be, because I leave them enabled (there is also an option to send them directly to sentry through API and not publish on site). But in practice from that I see, I misconfigured them somehow and didn't see them anywhere.
There was a problem hiding this comment.
OK cool please let us know when you figure it out 🙂
| process.on('unhandledRejection', err => { | ||
| Sentry.captureException(err) | ||
| }) | ||
|
|
||
| process.on('uncaughtException', err => { | ||
| Sentry.captureException(err) | ||
| }) |
There was a problem hiding this comment.
Why are these needed if Sentry supposedly has automated handling of uncaught exceptions and unhandled rejections? See https://docs.sentry.io/platforms/javascript/#automatically-capturing-errors
There was a problem hiding this comment.
It's for server side errors in node.js, Sentry will automatically log errors in browser, but not unhandled errors in SSR.
There was a problem hiding this comment.
Got it, thanks.
Would these also be needed separately for server.js or other build-time code? e.g. sidebar.js
There was a problem hiding this comment.
This catches all code in the actual pages including sidebar.js, but I think we are now missing errors from server.js because they happens before we call _document.js.
There was a problem hiding this comment.
Yes some server code runs before the Next app and partially includes sidebar.js code I think. That's what I was wondering about. But it's probably not a big deal? Only runs when the server is being initialized, probably only when new versions are deployed to Heroku (or when they restart it automatically for whatever reason).
There was a problem hiding this comment.
That's pretty much my thoughts as well. And also the fact that we are planning to migrate to Gatsby and it didn't have a server. So I decided to leave it as is for now.
Test integration with Sentry. To make it work we need to add env variable
SENTRY_DSNto Heroku.