Tracking errors and slowdowns in Node + JavaScript using Sentry

All right, let's get started. First of all, thank you, everyone, for taking the time to attend this workshop. I just want to confirm if everyone can hear me. If someone can just give me a yes in the chat, that would be fantastic. Awesome, thank you. Appreciate that, everyone.

All right, so today what we're going to be talking about is how we can track our user experience in our Node and JavaScript apps, specifically when it comes to crashes, errors, exceptions, slow page loads, renders, and all things like that that you would be considered about if you were the developer that wrote this code, put it out into production.

Additionally, we're going to get some visibility and context that we need from the application side so that we can actually know why these issues are happening, where in the code they're happening, who they're happening to, and actually fix it and roll forward.

By way of introduction, my name is Neil Manbar. I come from a front end development background, and now I head up solutions engineering at Sentry, where I help other front end developers and backend developers use Sentry and know about their issues so that they can fix them, which is the exercise that we're going to go through today and I'm really excited about.

So real quick, let's just go through the agenda. First, I want to demonstrate the problem. I want to show where the gaps are when you're developing a browser app that's talking to, let's say, an Express backend, and when issues happen, where the specific gaps in visibility and context are and why you need a true application monitoring tool within your applications.

Then we'll go ahead and integrate Sentry, specifically introduce the SDK into our application for front end. We'll also get the source maps up so that we can get a readable stat trade. And then we will go through all of the various use cases. So we'll use Sentry to solve for errors. We'll tell it what's happening, we'll get all the context that we need, the who, what, when, where, and why so that we can do something about it. And we'll do the same for slowdowns as well. And then, as a developer, you're putting out releases, you're putting out new builds. We're trying to do this at an ever increasing pace. Sentry is also going to tell you how all of this comes together in terms of releases, if your release is adopted, if it's having new errors, if it's having slowdowns, etc. And then any of the data that we send in to the platform, we're going to be able to slice and dice and query and dashboard, and I'll go over that at the end.

If you have any questions, feel free to throw them into the chat. I'll also address questions at the end as well.

So why application monitoring, and why do I actually need it in my applications? Rather than just providing you guys a bunch of text, I'm going to go ahead and showcase the problem. So here I have my application, and it's basically a React front-end that's talking to an Express packet. And what I'm going to do is leave the console open. I'm going to refresh, and it looks like once in a while, it's going to crash, and there you go. And when it does crash, we basically have this unreadable stack trace. We don't really know what's going on. We don't know even if it happened, unless the user reports it to us, or we eventually figure out this is happening and then get to reproducing it, and then we get this information here.

Additionally, let's say when this does work, there's slowdowns as well. So here it's slow. Is it because of the back-end? Is it because of the front-end? Is it because of my rendering code? Is it because of some slowdown at the database layer? I don't know. So let's go ahead and add some items to cart, and then we'll go ahead and check out. And when we do that, there was also some slowness, and it looks like there was an error as well. So what I'm going to do now is kind of recap what happened here. So if we take a look, first thing, we were left with an unreadable stack trace. It was minified. We don't know what was going on, and we didn't even actually know of the error in the first place. Same with the slowdown. We didn't even know about the slowdown unless a user reports it to us, and then we reproduce it, and then we have to look through all the profiling tools and all of that type of stuff. And then additionally, there was an error with the slowdown as well. So on the front end we don't have the visibility we need. And we're stuck to reproducing. And then on the back end, if we're not using an application monitor tool, we end up having to dig through logs, assemble queries, and then piece this together from the outside rather than the inside of the application.

So let's go ahead and showcase what a developer would actually want and need when it comes to this type of stuff. You would need the context. So you need an SDK that lives in the code that's sending stuff up. And then you're alerted when there is an issue. Your team knows about it. And then we can get the application layer context of who, what, when, where, and why that I'm going to show you that Sentry surfaces. And it would be great that we could even identify which commit or code change caused this. So we could get it assigned to the right developer, and then push forward with this and roll forward and get back to a successful state. So this is the workflow that Sentry is going to be able to provide you. We're going to ship up errors, transactions, and sessions. You're going to be alerted when these things go wrong, know about it, get the context you need, and then be able to roll forward. We're going to go through all of this, but we're going to solve for errors. We're going to solve for slowdowns. We're going to see if our latest release was successfully adopted. We'll create some dashboards, some slice and dices data. And as a developer, I use Slack. I use GitHub. I use JIRA. I use my own tools, and I use about a hundred of these things played together as well. For those of you that are looking to follow along, I would suggest you create your own Express app using Express Generator such tool and same with React, you can create React app and go ahead and sign up for Sentry. I've inserted a link here, sentry.io/signup, and we'll go ahead and create two projects. I'm going to be using my own application. It's a little more involved. That's why I suggest that you guys just use Express Generator or create React app and go ahead and just start from a plain brand new application. Signing up is free on Sentry. You can just go ahead and do Sentry.io signup, create an organization, and then go ahead and create projects, one for your React, one for your Express then. Before we get into all this, I'm going to highlight all of the documentation, and then I'll actually go through this exercise with you all. I'll show how this is integrated into that PlantStore app that I was showcasing.

First, let's go ahead and just head over to the documentation. For React, it's going to be quite simple, and you're going to see it's very similar to Express as well. All you have to do is npm install or package or yarn add depending on what package manager that you're using. All you're going to have to do, and this is typically going to be done in index.js or as early as you can inside of your application so we can start tracking those errors and start tracking the transactions. All you have to do is sentry.init, and when you create a project, you're going to be given a DSN, which is a key, and then we want errors to be sent up to Sentry and this is the project ID. For performance, we'll go ahead and enable our tracing integration and we want 100% of the traces spun up. Additionally, in my example, I'm going to be using the React router in Redux, I'll highlight quickly the set up for that. We will also want to upload source maps for frontend as well. First, you have to be able to generate those source maps. It can be done typically with a flag, I think it's Source Map or DevTool, just making sure that your build process is outputting them and then go ahead and upload them to Sentry. There's a few ways we can upload them. You can use our webpack plugin, which is really easy. Just go ahead and install it and then go ahead and specify. In my example, I'm going to be using our CLI tool, which our webpack plugin uses behind the scenes directly, but all we have to do is basically sentry CLI upload source maps. I'm going to highlight all of this in just a moment as well.

Let's go through these instructions for node real quick. If we go ahead to node and then let's go to Express. Once again, very similar, npm install. Then what we'll do is sentry init. We'll attach our request handler for performance here, and then our error handler as well, and we're set to go here. Let me go ahead and showcase this in my application.

Here I mentioned I have a React application that's talking to an Express backend here, and here it is. We'll go through this side by side with Sentry. I already have an organization here. You would go ahead to projects, and then we can go ahead and just create a project. Go ahead and select React. We will be prompted with the instructions to install. Here in this case, just to save time, I've already done some of this, but I will highlight that it's been done and where the integration points are. Here I have installed these two packages. Then if we go to index.js, here we can see sentry.init, the PSN, and that was created as part of creating this project. Here I have this stuff for performance, and I want 100 percent of transactions being sent up. I also want to sentry to know about what releases all this data is coming from. As a developer, it doesn't help if you have errors or slowdowns in the last two days. You want to know that happened in the last few releases. It's still happening, and same with the environment. I want to know that it's happening in production or whether it's happening in one of my earlier environments, so I can then do something about it. I mentioned that we have to upload those source maps, so that's what I've done right here is create React apps. If you run a production build, it will produce those source maps. Here we're just uploading them to sentry, and you're going to go ahead and create an Auth token, and set that as either an environment variable or pass it through so that we can shoot these up to our sentry organization, specifically that relief, and that's going to unite all of this data, so when an error comes in, it has this relief. It has source maps associated with it. We'll apply that transformation and get a clean stack base, which we'll then use for our grouping, and I'm going to go into all of that in a moment. On the Express side, here is my package on JSON. We've included the packages here, and then in my server.js, what I'm doing is sentry.init, dfn, environment, and release, just like we saw earlier, and this is for performance. We want 100% of transactions being sent up, and that's really it here. One thing I forgot to highlight is that here for the front end, if you're using React, or, sorry, Redux, we do attach that context onto our events if you're using our integration, and here, that is right here. I'm also using the router instrumentation as well so that we can attach onto that and auto-instrument accordingly.

So, after all of this, what's going to be done? I'm going to go ahead, once again, back to the documentation and just highlight what's going to be set up. So, if we go into here, and then go into React, you can see that we'll automatically report errors and exceptions within your application. And then, if we set up performance, we'll also create a new transaction for each page load and navigation event and child spans for backend requests. And you're going to see a bunch of stuff, as well, and I'll show you this in a moment. But basically, whatever's happening in the browser will be attached as a span, and we'll be able to understand what was going down. And similarly for Node, this will surface errors and transactions. In addition to each request coming into the backend will be a transaction, and all the activities within there will be spans. And I'll show you this. And we have database integrations and such, as well, to show you what's going on there. But now that we're integrated, and if you all are following along, basically you run all of those NPM installs in Sentry.init, copy-pasting the code from here should actually work, and then you're also presented the code to create an error so that we can then see if everything's wired up properly. But now that we're integrated, we're now going to have errors sent up to Sentry, transactions sent up to Sentry. We'll also have sessions sent up, so that will help us know if someone entered the app and had a healthy exit or crashed and, you know, crash free sessions went down to 95% and we want to debug that and then Sentry knows about our environments and releases and on the front end, we'll also upload the source maps. So what does this all look like after it's wired up? Here, I have an application that I already have sending traffic, but you can see that here are the crash free sessions being sent up, here are transactions being sent up and we can display those and go into the specific views in just a bit and then we have errors being set up. But this helps understand exactly what's happening. Sentry knows about all of these releases and we'll go through alerts a bit later. But long story short, through power of this all in one view, here we see that we drop down to 95%, we can go ahead and highlight that data set and we see exactly the errors that impacted that. So now what we're going to do is go through the various workflows here. Let's solve for errors. I know I showed you a little bit at the high level glance here, but now we're really going to get into it when it comes to errors, slowdowns, and then as a developer, I'm going to show you if I put a release out there, how I know it's properly adopted and what's going on with it. And then we'll assemble some different queries and dashboards, and I'll show you how integrations plays into all of this. So, first, let's go over here. And let me go ahead. And do you all remember this error that I had earlier on the homepage? So, if I wasn't using Sentry, I'd have to reproduce and then eventually get to this. In this case, I am using Sentry. So what I can do is now automatically I'm going to be notified that there is an error. There we go. It just came in. Looks like there was a range error. And now this takes me directly to the Sentry issue. And this was an unhandled error on the front end. And I can see exactly the who, what, when, where, and why. Looks like it was a range error. It happened X amount of times for Y amount of users. Started about 14 days ago, as we can see from this graph here. It's been flaring up over the last 24 hours accordingly. Was first introduced in this release. Ill happening in this release. It looks like it's happening mostly on Chrome. Oh, yep. And here's a custom tag, which I'll show you later. You can set. But it's happening to my most important customers in production. On these releases. And if I want to get into all the event specific data, I can cycle through that right here. But here are all the tags associated with it. And we see who exactly it's coming from. And here is the probably the most important part for an error when it comes to a developer this factory specifically. So if we weren't using something like century, this is what we'd eventually see this obfuscated minified code. But since we uploaded those source maps to century, we got to the readable code. And then we're even showing you the context or the lines, exactly where the error happened, the stack trace, and the code context for each of these frames.

And we can go down through as necessary. And some of these are libraries. So we don't want to see those so we can do app only. And these are the relevant frames that developer will want to see it.

So here. Looks like an error was thrown on errors JS line 14. And underneath that we have breadcrumbs. So this is what happened prior to hitting the errors. So here redux was doing its thing. There was some console logging and this happened on a launch. So there's not much, but I'll show you another example tomorrow. But we'd also see XHRs here is clicks and other interactions.

This is the context that Sentry was able to capture, including the redux state, any of the user agent information. And we're going to be associating this with transactions, which I'll show you later. But long story short, it's as a developer, I now know the who, what, when, where and why. And I can fix this. I can resolve it. I can ignore it. Or if I never want to see it again, here are some of the steps I can take. But if this was something that was actuable, I'd want to fix it and go from there.

All right. So this was just a basic unhandled error on the front end. Let's increase the complexity a little bit. So here, what I'm going to do is let's go ahead and debug why the checkout was broken. Was it the front end? Was it the backend? And exactly what's going on here. So when I click Checkout and Submit here, there's an error. What's going on specifically? Let's go here. And once again, we're going to be alerted in just a moment. Just going to save some time. I'm going to go in here and really figure out what's going on.

So here, it happened X amount of times, affecting Y amount of users. Looks like we did not get a good response from the backend. Let's see what the user was doing here. So it looks like some things were clicked on in the products list and then eventually... looks like it issued a request to our backend which returned to 500, which bubbled up to our frontend. As such, and that's what we're looking at here. So this is an issue that manifested on the backend but also surfaced on the frontend because we weren't able to get a good response. And since I'm using Sentry on both my frontend and backend, I can just go in here and then click the related error. And now, within one click, I'm on the frontend to the backend and I see exactly what happened. It looks like we were trying to buy a bunch of items and we did not have enough inventory for that product. So an error was thrown. And fixing this issue will actually alleviate the both. So you can see, as a frontend developer, I was able to hop from the frontend to the backend and see exactly what was going on.

And I see that Ignas asked, it would be great to have variable values in the stack trace. So we do do this for Python and PHP, where is achievable, but it's actually very complicated in Node and JavaScript Lint. But the philosophy of Sentry is we want to be able to attach everything that we can. And if there was variable values, we would see a show more and we can click that and it would show that as well. I'll actually show a Python example at the end. But here, once again, I'm an express land server, JS line 177. And this is exactly why this happened.

Maybe I have to handle this better or add some inventory so I can start selling again. But probably we want to handle this better and handle it gracefully on the frontend and fixing that would fix the two. And as a frontend developer, I knew exactly what happened. They started on the checkout, there was an error on the checkout and there was an error on the backend and that's actually what produced all of this.

All right. So right now what we've done so far is just go through issues so far. Let's now go through errors or let's now go through performance now. So specifically we're debugging an unhandled issue on the front end and then maybe debug a more complex example that was due to the backend but manifested on the front end. Let's now debug that slowdown. So if you all remember what I'm talking about is when we pulled an application and clicked products it was really slow. Is this the front end? Is this the backend? Is it a combination of both? I don't know, but in this case I'm using Sentry. So what I can do here is one, if I don't have a loop set up for this I can just go into the performance tab here. I'm going to go ahead and select my front end project here. Let's start there. And transactions are being sent up to Sentry and we also leverage web viables if they're available here. So what I'm concerned about here is the product standpoint and I see that the user remissory index is pretty high here. It looks like it's taking about seven seconds to load. That's... Go ahead and filter down. I can see it's one of the related searches just to stay consistent to this user here. What I'm going to do is pull up this transaction summary. And... I can see the duration breakdown here is taking about, you know, 950 seconds to load, especially when it comes to a P95. I can go ahead and toggle web vitals and if you're not familiar with web vitals, this is basically... the largest contentful paint, first contentful paint, and first input delay. And some of these metrics that browsers provide outside of just basic transaction duration information so that you actually know front end loaded and it was usable. And it finished shifting and was actually... So here what we see is that there are a bunch of LCPs, which is the one that I'm using here that are super high in the seven seconds. I'm going to go ahead and filter on that here. Oh, what happened here? It's also not, yeah, that looks like it's also not. Measurements.lcp. You should use the auto predictor. And just for kicks, what I'm going to do is browse our name from. And let's go ahead and pull some of these transactions up. But on the transaction summary, we can see what's going on here on the aggregate just like we saw on the issues page. We have all the tags here. And here, cutting to the chase, I can see that most of the time is being spent on an HTTP request. And SpendTree is even identifying that right here. So it looks like this suspect's bin, this HTTP request is taking a lot of time, happening quite often, and a lot of time has been spent there. Let's go ahead and drill into this. So I'm going to click here, and now I see exactly everything that happened on the browser. So this is when I loaded up the products page. Page load, the browser did its thing, imported some resources, reacted to this thing. Here, it started the nav mounting for that component. And then products, which is what we're interested in here. And now we can see it took a very long time, specifically 86% of the time. And after that was loaded or retrieved, then it looks like it was rendered and the largestContentfulPaint check failed here. And here, we see it clearly as J, here's the red marker, here's the HTTP request, and here's everything else that happened in the browser as well from all the browser actions, resources being imported, react doing its thing. We can see the DOM content also being loaded and I'm using Sentry in the back-end here.

We can see the DOM content also being loaded and I'm using Sentry in the back-end here. So I can actually just click this and click View Transaction and go directly there. But better yet, I'm just going to take a step back. I can actually just un-collapse this right over here and see exactly what was happening. So this is the back-end transaction, inline here under the span on the front-end transaction, and I can see it reached Express, and it looks like we did a bunch of sequential querying, and this over here is the reason why this entire request was slow and we failed the LCP here. So I have all the context regarding the slowdown in one page here.

It looks like we have a couple questions I think I might have missed. What happens if the production code is minified? That's why you want to upload your source maps in regards to issues. For performance, that's not going to matter here. This is actually stuff that we auto-instrumented into. It looks like there was another question as well. Is there any way to send that data from Sentry to Google Analytics? Yes, there is. We do have service hooks and data forwarding and things like that that we can show you. So we just wanted to get that out of the way. But going back to here, once again, just to summarize, here is the products page, loaded, issued a request where 86% of the time was spent. That's why we failed the LCP. And here we can see exactly what was going on. We just uncollapsed it and got all the information and we'll have the breadcrumbs and all the other additional information here. So what we're looking at specifically is a transaction right here. All right.

Let's actually do one more example, and this one's going to be a little bit more complicated. Remember that when we click checkout, there was a slowdown in addition to an error. So let's go ahead and debug that. So what I'm going to do is just go to the front end. I'm just going to alt transactions. This, I believe, is the checkout transaction. And I can see once again all the information here. Specifically what I want to show is this is the front end checkout transaction. It's taking X amount of time. There's an HTTP request happening. And here are the related errors associated with that as well. So once again these transactions are slow and are impacted by these errors. We have all of that in one page. But let's go ahead and drill down into this. So here – let's actually go into here. So now if we click this, remember clicking here takes you to the back end error. But we can actually go into the transactions by clicking here and directly go into the back end or downstream transaction as well by clicking within here. All in all, if we take view full trace, we see exactly what happened. There were two transactions and both these transactions had errors, and this was the full picture here. And we can seamlessly go from each one of these to each one of these so that errors and slowdowns are in the same platform, as frequently errors have something to do with slowdowns because there might have been a retry, et cetera. But now I know the whole picture. All right. So that's great. So, so far I showed, you know, how we can monitor errors, how we can monitor transactions and how we can figure out what's causing them and then get all the context of who, what, when, where, and why, figure out what's causing the slowdown. Is it the front end, is it the back end, is the browser doing this thing? Is it my front end application code? And next, I'm going to go into releases. It looks like there was another question, which I can address. Yeah, you saw that user emails are displaced. Is there a way to anonymize these to be GDPR? Yes, there is. So you can do this on our server side end, saying that if you ever see a user tag, go ahead, anonymize it, mask it, remove it. We do have all of that scrubbing and all of that type of stuff on our end.

And you can also do that within the client side SDK as well, to make sure it never gets sent over the wire. But absolutely, that's cool. All right, next, let's go ahead and monitor a release, and then figure out what's impacting that release. Is it having some errors? Is it having some slowdowns? So once again, I'm going to go into Sentry, and I'm going to go to Releases here. And I recently put out a few releases. I'm going to go ahead and query by that. I think they were something like this. So here I'm querying by semantic versioning, and you can see that 20% of my users are still on this release and 80% of users are on this release. I have a 14-day view here. You can see that this was taking traffic, and now this one started taking traffic. It has such crash rate. It looks like I regressed a little bit, and it looks like there were some new issues introduced as well. So let's actually go ahead and debug this release here. It also debugs a few as well. But here now I see all of the session information, and I can go ahead and drag and drop this. On the right-hand side, I have the aggregate adoption in terms of sessions and users. I can see how this is going in regards to crash rate users over time. I see when this code was released, and specifically here I have the session information across all releases, this release, if it changed, and I can see other metrics as well. New issues that were introduced in this release, but this probably had something to constitute with the decreased percentage as well. And I can see all of those errors being surfaced and being aggregated here. And then I have the failing transactions here as well. I can also view slow transactions, any of that, all in one place. So, here, what we're doing is we've united all the data in terms of a release. And we can understand if it's being adopted properly, or if it's not, what's actually impacted, jump straight to the issue, jump straight to the stack trades, or jump straight to the transaction, and then go ahead and debug from there. So, that is release help. So, now what we've done is show how Sentry surfaces errors, surfaces transaction, correlates them, also shows you all of this in a release perspective so that you know what's going on as you're pushing your code out there, and we all know we're trying to accelerate release cycles. So, the more we put out there the better it is for the user, but we have to be able to monitor that, especially when it comes to web. Next, I'm going to showcase that we can query and slice and dice any of this data to really figure out what we want to, and we can set alerts on it, do all of that good stuff, and pin it as a dashboard. So, I'm going to go through two use cases here. So, first, let's go to discover. So, what I want is I want to understand which type of my customers are having errors, and then I want to get a browser breakdown of it, and let's figure out what those most popular errors are. And this is just to kind of showcase to you the power of what we can do with this data and how we can query this. So, here I'm in discover, which is basically our query builder and visualizer here. I'm going to go ahead, and let's actually just start. And right now I'm querying all of my projects, all of my environments. And what I'm going to do is I only care about errors right now. So, let's do something like this. And I also want to make sure these are ones that have this tag, and it's a custom tag I've set. Also, if you're interested in setting a custom tag, More or less, it's sentry.setTag, so if we go into here, and then Customized Tags, I'm doing it in my code. It's just sentry.setTag, customer type. And so, let's go back into here, As Customer Type, there we go. And now, let's go ahead and just define the columns. For instance, customer type. And let's just get a total count of them. And for kicks, why don't we just do Count Unique Users as well. There we go. So it looks like, you know, they're pretty well spread out. That's great. And we can also confirm that by doing something like this. What I'm actually interested in is let's just take the enterprise users.

These are the ones paying us, let's say, the most amount of money. I want to debug what's going on here. Let's see how they're having an experience on all the various browsers here.

So I can go ahead to changes. Bam. It looks like that's such. Most of them are using Chrome, it looks like, and having errors on that as well. I'm interested in that dataset, so let's go ahead, add that to filter. And clicking here will also add it to filter. So here you can see I'm now. And now what I want to do is actually. View the title of the errors and actually just be the issues as well. And we can see exactly what's going on, and then be linked into the data set as well.

And now, let's say I wanted to set. An alert for all of this. You saw some of the issue alerts firing earlier, but we have the power to even set metric alerts here, so I can just go here, and I think I would have to actually set a project. There we go. And then create an alert. Let's just do that. And I can go ahead and set any threshold. And let's say I want to be slack pager duty etc. It can all be done here. Very, very easy. Let's file that. Additionally, if I wanted to add this to any dashboards, I could do that as well. I'll get into dashboards a bit later, but so far I queried the error data set. Let's do one more use case here, and let's go ahead and query our transaction data so that we can figure out the failure rates of transactions. And the failure rate is usually dictated by if there is an error, and the response it gives.

So let's go ahead and first just filter down on this. So let's just say, event type.transaction. Let's go ahead and just look down, and you can see how easy it is to kind of construct all these queries. I don't have to know about query language or anything like that. Let's go ahead and just do transaction and let's do failure rate here, and let's just start from there. And here, I'm actually just going to start with my backend app. There we go. And I can see that the checkout transaction is failing quite often. That's interesting. Let's figure out, is it happening in all the various releases? So let's go ahead. Add that to the filter. Let's go ahead and change this to release. And let's go ahead. Now we can see all of this data in regards to how it's been behaving in all the various releases. And we have. Add that to a dashboard or once again, create any different alert. But now we know exactly what's happening. It looks like it's happening in these three releases in the last 14 days and it's been hovering around 75 percent, which is not good. We should probably get in front of this and figure out what was introduced and one point. So I'm not going to go ahead and add these to dashboard, but I'm going to go ahead and just show off a few quick dashboards. That should really show the true power of all this data. But here is a front end template.

I'm going to probably want to do some front end data for that. Here we go. And we can see all our issue data, the browser breakdowns. We can see how all of this would be grouped by issues or group by URLs to figure out which URLs are impacted. We can display this in a big number, a map, any other sort of visualization. And here is transactions, issues, web vitals all in one place. And we can go ahead and customize any of this as well.

So similarly, if we wanted to do a back-end one, you'd be interested in some of that information, but also throughput, appdex, all that type of stuff, and failure rate. And that's what we see here. Once again, you can pin from Discover to Dashboards and create any of this, and query any other dataset so that you can get the appropriate views. And the last thing that I wanted to show here is ecosystem.

But before I do that, it looks like there are some questions. If an error occurs, when the application is running, will there be a real-time alert? Yep, exactly. So what's going to happen, let's say the application is running, there is an error. Sentry is going to capture that, we'll attach to the global error handler, flush out that error to us asynchronously so we don't block anything within the application. We'll aggregate that, we'll source map it, process it, aggregate it, persist it, and then our alerting will fire accordingly. So you'll be notified within seconds of it happening. And I think I showcased some of that earlier when I caused an error. You saw that I pulled up Slack and within a couple of seconds I had been notified that this was going on, and then I actually pulled up the relevant sentry issue as well. All right, so we went through errors. We went through transactions or performance. We showed how we can monitor a release and see how it was adopted. We constructed some queries, showed off a little bit of dashboard, even showed a little bit of metric alerts as part of that, and that all stemmed from Discover. Last, I want to show how all of this can come together in your workflow. So let's say I'm a developer, right? I'm using GitHub to store my code as a repository system. I'm using Slack for notifications and just chat. And let's say I'm using PagerDuty for incidents as well, and I'm using JIRA for issue tracking. So let me take this. Let's say, you know, we had an alert fire as we saw earlier, and that alert pointed us to this issue here. Let's actually show how all of this comes together. So first, we had Slack alert us. That takes us to the issue, or we could have had PagerDuty do the same. And there's a bunch of stuff that you can do from within a Slack alert, we can resolve, ignore, assign, all that type of stuff. But long story short, you want to get to the context of who, what, when, where, why. Let's take a look at this. It looks like this is why it happened. I think someone talked about Stack Trace variable values. So here it is in Python. You can actually see the variable values at that point in time or each of the frames and see exactly what was going on here. And it looks like, and this is my favorite feature of Sentry, we integrate in with the sort code management system and we're able to identify which commit caused this error. So here it looks like Will committed this code or merged it in this code, which caused this error. So therefore, Will should be assigned this issue because he's the best firefighter for this job and he wrote this code. He knows what's going to be going on from this rich context here and he can fix it within five minutes rather than me trying to understand what's going on and it might take me a couple hours. Additionally, we also have stack trace linking. I don't have it configured in this example, but you could click here and it would take you to the appropriate line within GitHub as well or line on that revision in GitHub as well. And let's say now that we know Will caused this, let's create a JIRA issue for this. Let's assign it to Will. And it actually would have automatically assigned it to Will because we actually have a two-way binding with JIRA. So here is the JIRA ticket on the right-hand side. If we change the assignee or if we change the state, it will also do so in the product.

Let's pretend to Will. I just click done. Bam. Now it's done within Sentry as well. And it would have done it as well. From alerting to the deep context to the commit that causes this, getting the right person involved so that we can stabilize this. And you can even say fixes this Sentry issue and will automatically mark it as resolved in that release as well.

Long story short, we want to make sure the developer gets notified, has the context they need, has the information they need. They can trace it. They can fix it. They know what commit caused it, get the right firefighter on the job, and go back to development, or playing racquetball, or whatever it was that you're doing.

So that is mostly what I had for today. I wanted to showcase how we can use Sentry for knowing about our errors, getting the context we need for errors, transactions and performance, know about our releases as well, query our data, and integrate into our entire workflow. And now I just want to open it up for questions. And I see that there are a couple of questions in the chatroom, so I'll address those first.

Can you use Sentry for CICD? So a Sentry is an application monitoring tool, so when you deploy into any of your environments, Sentry will tell it you know that you're having these slowdowns or errors. So as part of your CICD process, where you're pushing out these releases, to production, to your staging environments, yep, you can use Sentry to monitor these things, detect that these issues are happening as you keep releasing.

Looks like Santiago asked, is Sentry a complement of some other tools such as Datadog or New Relic, or is Sentry a replacement for those APM tools? Good question. So Datadog and New Relic are traditional monitoring tools that are mostly used in the back end, and they're mostly agent based. What Sentry is doing is a little bit different. We're doing this from the front end, and we're an SDK in your code that starts typically from the front end, and we're able to trace all of these things. So what we're seeing is developers are using Sentry because it fits into their workflow, it's in their application, it starts from the user experience, and the operations teams use Datadog and New Relic to kind of monitor these back ends and some of these system level type of things. There is a little bit of overlap, but that is the major divide of where you use these things and the personas that typically use these things.

How would it work in a microservice environment? So as you saw earlier, I was debugging a 500 error. Let's say if we did have more microservices attached to this, or the back end actually was more complicated, we would see more transactions here, and we would be able to trace this all the way through. So what we're doing is we're passing these Sentry Trace Headers, and that's being set as contacts, and our server side is then making sense of all of this, establishing the parent-child relationship, and who requested to whom, and what happened, and then uniting all of these transactions and errors as well.

Serverless? Good question. So we do have serverless integrations. And the big thing that we have to make sure about serverless is that the event is flushed out. So that's one of the changes that we made here. So here's our AWS Lambda plug-in for Node. You can go ahead and use that.

Alright. Next question, can you – so for serverless it would be the same, and it's actually even more valuable because you have less context for serverless because things just fail and then things die and you aren't really left with much. Ignaz asks, can you set this up with Slack, email, and Discord? Exactly. Email, it comes out of the box. Slack, you can go ahead and configure it, and you'll get alerts, as you mentioned here. I believe we have a Discord plug-in as well. And you can go ahead. If you go here, test entry integrations, we can see exactly all the different things.

How does it work with server-side rendering? So for server-side rendering, you would have to include all of our – the SDKs that you would need, so whether it's the JavaScript SDK or Node SDK, and then you would upload the source maps, both for the server-side and client-side stuff. I don't have all of the information regarding that, but I can follow up with you, Steven. It just involves a little bit more configuration.

Santiago asked, does Sentry provide an interface to create synthetic events or a mechanism that I can use to create kernel events to Sentry? Synthetic events, not quite. We don't create synthetic loads and send that to our service, but in regards to a mechanism that creates custom events and reports them to Sentry, Sentry all-in-all is like an event ingestion engine and you can actually create your own SDK or hit our API directly to get that done. If you go ahead into here and then go Usage, there's Sentry.captureException, which takes in an error object. There's Sentry.captureMessage as well, and you can go ahead and use that to send a fan to Sentry, which will then aggregate into issues. And then for transactions, anything that we don't automatically instrument on, you can go ahead and start a transaction and specify spans as well, so we give you quite a bit of control there.

Yeah, no problem, Santiago. Any other questions at this point in time? Hopefully, I was able to show everyone how you all can use Sentry and not have to, you know, deal with this anymore and can then get in front of these problems, know about them, and, you know, help put out better releases or respond to releases.

Ah, if we have a DB connected, will it report slowness there? Yes. Maybe I could have spent a little bit more time highlighting this, but let's actually go to here and let's actually go to Express. Well, we're here and I believe I had a couple calls here. Let's go to checkout and post. So, if we go into products here and let's go ahead and view some of these transactions, you can see there's a DB integration here that's showing the select statements and exactly what's going on here. So, here in my code, you might've seen that I had the DB integration selected. Oh, not here, but let's go ahead and view the documentation. So, if we go into here, we go into node, we go into Express, we have a database integration for all of these. And I believe this is the one that you're looking for. All righty.