Remix Conf Europe

Remix Conf Europe 2022

How to Solve Real-World Problems with Remix

Michael Carter

DevOps.js

DevOps.js Conf 2022

Monitoring Errors and Slowdowns Across JS Applications

Hi there, my name is Simon. I'm a Solutions Engineer at Sentry, and we'll be talking about monitoring errors and slowdowns across JS applications. Sentry is designed squarely for developers. We'll tell you when your code is slow, when it's broken, and clues on why. We're connecting the end-user experience as closely as possible to the developers that make those experiences happen. With the Sentry SDK on your apps, we'll alert the necessary team members and developers when those errors and slowdowns happen, let them make those commits and the changes to optimize that developer and customer experience. The Sentry platform is divided into these five pillars here. We'll be focusing on the first three on the left. That's the error monitoring, performance monitoring, and release health side of Sentry. Now to get started, we would be on the Sentry documentation page. We support all major languages and frameworks button here to get into all of that. But prior to place, we have Node.js in the front page. To get started with that, the install on the packages that are necessary with a Yarn add or NPM install and configure with Sentry init, including that DSN, so that's a data source name. It'll tell your application where to send error and transaction events to, and that's your project in Sentry. Now I've got an app here for us to take a look at together. We'll generate some transaction and some error data, and we'll take a look at how that's represented in Sentry, how it's organized by releases as well. Now to get started, we'll click into browse products to take a look at the available plant things to buy. It's taking a few seconds here. We'll take a look at that slowdown momentarily, but I'm going to finish up with this user flow, added a couple items to our cart, checking out to purchase them. We've encountered an error, surprise, surprise, but let's take a look at how that's represented in Sentry. Now I've got a Slack alert set up. In a few seconds here, we'll be notified of the error that we just triggered from that checkout process. Click into this notification with some context behind the scenes as well, of what just happened, but let's take a deeper look. From that link, I'm taken to the who, what, when, and where of the error that we just experienced together. This error, this 500 error has happened 160 times to 60 users, some context about its frequency over the past day, 30 days, first and last seen across releases. That's really helpful, and also some aggregated tag information on the right over here. We've taken all 160 times this error has happened, gotten some contextual data and heat mapped, organized it as you see here. Customer type is small, planned, large, medium, enterprise. It's affecting all our users. We want to take a deeper look into that. Now let's focus on the middle pane here. These are the details of one of the 160 times this error has happened. We can page through to other ones. In any case, let's take a look at these tags. The key value pairs for this specific occasion, Mac OS, Chrome, it was a large customer, some other details. But what we care most about at this point is probably the stack trace. Without Sentry, we'd be dealing more with this minified not human readable stack trace. But since we've uploaded our source maps at build time, we see this very beautiful human readable stack trace, and we can take a look at the exact line of code where it happened. Looks like the response from the back end was not okay, so we can dive a little deeper into that. We've also got a timeline of activities that led up to our error, which we can filter by as well. Now, just going back to the top of this issues page, I see there's a connector to a child event. That's our node back end. Now clicking into that, we can see everything that we just reviewed, but now from the back end. The who, what, when, and where. With the stack trace as well, we've got our node stack trace, and we got an error because there was not enough inventory for our product because the inventory item count and quantities just weren't happy together. We can work with our back end team, figure that out. Great. That's the first item here, error monitoring. Let's jump into performance. Going back to our front end and our performance tab, we got our web vitals right away. That connects that end user experience to what we as developers care about and what is actionable for us. Our products transaction, which took a few seconds to load, as we noticed earlier, that list of products, it's failing on our largest contentful paint web vital. Let's dive a little deeper into that. We've got our transactions table, look into a transaction summary of how it's been performing over the past day. We can adjust the time frame or this is a really fun graph to work with and highlight over a specific period. But in any case, what we care about is getting into the details of a specific transaction. Clicking into that, we have the operation breakdown of what just happened, how it's performing against our web vitals. It's failing on that LCP, 10.6 odd seconds over that 11.18 total transaction time. Super problematic, but a lot of the operations looking down is not taking too much time. We see this one HTTP client operation that's taking 10.5 seconds. Let's dive into that and look at what operations are happening. Here we can see that there are some database queries, some select statements that are sequential, and we can work with our back-end team to figure out how to optimize that, reduce that LCP problem, and improve that transaction time. Great. That's two checks off the box here. Now let's take a look at release health. We organize our details about our projects in releases. We can sort by specific properties as well. We support semantic versioning. Here we've organized it by 22.x releases, and we can adjust to see details about our production environment over the past 14 days in the terms of sessions, or users are available as well. In any case, once you filter according to that, we get all the details about these releases. Our crash free rate in the latest version is 84 percent, adopted seven percent of the time, that's okay. Crashes aren't too bad, but jumping into a specific one, we get the specific details about these releases. We can organize by different series of graphs. Take a look at the issues as well and the regressed issues, unhandled ones, figure out which ones to delve into, and go back to where we started with the issues page, and also take a look at how it fits into the transactions behind the scenes as well. In this case, two transactions, two errors, everything just fits together with Sentry in the ways of going into a release, taking a look at the errors behind the scenes, and also the performance details all connected together. Great. Thank you so much for spending time with me, taking a look at these errors and slowdowns across my JS apps. Thank you.


Simon Zhong

Node Congress

Node Congress 2022

Monitoring Errors and Slowdowns with a JS Frontend and Node Backend

Hey everyone, my name is Chris. I'm a solutions engineer at Sentry and I'm here to talk to you today about monitoring errors and slowdowns in JavaScript. Sentry is code monitoring for developers. So we tell you when your code is broken, we tell you when your code is slow. We're not infrastructure monitoring, not analytics monitoring, specifically we live at the application layer and we're designed for developers. Today we're going to talk about two main areas, the error monitoring and performance monitoring sections. We'll head to docs.sentry.io, take a look at the node documentation, it's a simple npm install and initialize the SDK with sentry.init and a few configuration options. Very easy to get started. We land here on our demo site where we're going to purchase some e-commerce products. We notice that the products endpoint is taking a while to load, so we'll come back to that in a little bit. Go ahead and add some products to the cart. Check out and wait to get our products and we see an error. So without something like Sentry, we're not going to know that something was wrong, both in terms of the products endpoint being slow, as well as more importantly, in terms of having this error. So what we'll see here is at the current time, we just get an error and it shows up in Slack. We can see that it's a 500, we can see it's happening in production, we can see the release it went out at, maybe this was something that got released earlier today, recently, but we know it's happening in production, it's important, we're going to click through. Here we're on the issue page. This is the who, what, when, where, and why of the error. We can see what the error is, it's 500, it's happened 45 times to 22 unique users, it's happened however many times in the last 24 hours, and this many times in the last 30 days. It looks like it was originally seen back five months ago, and it was most recently seen, understandably, because we just triggered it a few seconds ago in this more recent release. We can see that the user was on Chrome, they were on Mac OS X, we get a little information about their email address, and any other custom tags that we've set here. We've got the stack trace that tells us the error type and message, you can see, all right, if the response wasn't okay, then we're going to manually call capture exception, Sentry SDK, Sentry attaches to the global error handler, and it will automatically capture any uncaught, unhandled errors as well, and you can also manually, for instance, if you're handling errors, like in this case, you can also manually capture them. Breadcrumbs give us a sense of the user journey leading up to the error, so what was the user doing right before the error occurred? You can see that just before, there was a post request to the checkout endpoint, some print statements, a click. The other thing that's really important to mention is we're seeing a human readable version of this, so if you have raw, your raw minified stack trace, because you have bundled JavaScript code that's been minified, you're going to see something not useful like this. When you upload source maps, you're going to be able to see the original human readable source code. We also have integrations with different source code management tools, so for instance, you can see these suspect commits, and this gives us a sense of who might have committed code that caused this problem. We can also see that there's a child error event, and we can trace that across. There's another project, in this case, our Node Express app, and we can see that there's a different error message, not enough inventory for product. It's happened 87,000 times to 85,000 unique users, so clearly this is not a new issue. It's happened a lot more frequently in the last 24 hours and 30 days than the prior issue. We can see when it was most recently seen, first seen. All the same deal, the who, what, where, why, so, not enough inventory for the product, and we throw a new error. At this point, we trace it down to the root cause. We can consider this solved, and turn our attention to performance. So if you recall, back here, we clicked on the product's end point, and we saw that there was some slow performance. Now, we can also see that reflected within Sentry itself. You can see a number of Google's Web Vitals, so just the standard SEO-related things, like how long it takes for the biggest thing to show up on the page, the first thing to show up on the page, and we can also head over to look specifically at our general transactions. You can see there's a user misery score that's quite high here for the product's end point, so if we didn't already know what we were looking for, we'd be able to see this. This is also configurable. If you have end points, you know we're going to take a long time, but basically, it's a way to helpfully see what are different transactions that are taking a lot longer than we expected. We'll click through to here, take a look at some of our recent transactions, and we can likewise see this shows a lot of different resources and assets that the browser's loading. You can see that React components were mounted and being updated. We're able to expand this and see that in our backend project, there was an HTTP request that took about 7.2 seconds out of the total 7.8, so in this case, there's a slowdown. It looks like most of these things are not contributing to it, but this is the culprit. Here on this page, we also get context. We have similar breadcrumbs, so what was the user doing during the time leading up to this point. Any more information here, we have a bunch of different tags we can access, as well as, you can also use Sentry's tracing feature to head over to, again, our node project on the backend and realize, OK, this is where things are actually going wrong. So it looks like there's some database queries happening here, and in this case, looks like we're doing some sequentially, so we're fetching individual product IDs rather than all of the products at the same time or a set of product IDs, so this might be an area where there's room for improvement. So we traced it from the frontend over to the backend without having to do a bunch of looking at logs for both applications. Sentry's goal is to basically consolidate all the context that you need to solve errors and performance problems and put them in the same place, automate a lot of the things that would have taken your time. At this point, we could go back. We could also even set up an alert in the same way so that we get notified in Slack in kind of the same way. So you might see, if we go back to the products page, we can create an alert directly from here. That'll give us a sense of the transaction slash products. Let's say if it's above eight seconds, it's considered critical. If it's above four seconds for this transaction, maybe six seconds, it's considered warning. Consider resolved if it's below three. And you can see that reflected here. So what we can then do is add an action, so maybe on critical status, on warning status, we email the team. And on critical status, we also go ahead and send something over via Slack. So now we've surfaced. We're going to be helping ourselves to surface any problems with this endpoint, this transaction, in the future. We've surfaced an error. In this case, it showed up in Slack. We had instant context into, okay, is this important or not? Do I need to do something with it? We clicked through and we got the who, what, where, when, and why of the error. We looked at how many times it had occurred, how many people it was affecting. And when we decided it was worth our time solving, we dug in, we traced it across to a different project that we had that implemented Sentry, and we went ahead and found the root cause. And that tracing feature is going to be enabled if you just have two projects, two applications that both have Sentry initialized and configured correctly. But that's a very easy thing to do. Performance monitoring, same deal. We surfaced a slowdown. We figured out what went wrong. Thanks, everyone, for watching, and good luck smashing those bugs out there.


Chris Stavitsky

Mastering Error Handling Node.js

Lizz Parody

Tracking errors and slowdowns in Node + JavaScript using Sentry

Neil Manvar

React Advanced

React Advanced Conference 2021

Track Slowdowns and Crashes in your React apps

Hi there, my name is Simon. I'm a Solutions Engineer at Sentry. What we focus on is code observability. With Sentry, you can understand the health of your application from the front-end to the back-end. Sentry is designed for all developers, meaning we support all major languages and frameworks, including and especially React. With the Sentry SDK on your application, you can alert the necessary team members and enable developers to optimize that developer and customer experience. The Sentry platform provides multiple perspectives on the health of your application. But what we'll be focusing on today is error monitoring and performance monitoring. With that in mind, I have a React app for us to take a look at, and it's in this e-commerce site. Let's click in and browse our products. It's taking a long time for this to load. We'll have to look into that a bit later, but we'll just have to continue on with the user flow here eventually. I'll add a couple of items to our cart here, proceed to checkout, and I think we'll proceed to checkout. This is a horrible demo site, obviously. We encountered an error, surprise, surprise. But let's take off our end-user hat for a moment, put on our developer hat, and see what's going on. Let's open our developer tools, look at the console, reproduce it, look at the network tab, cross-reference our source code. I mean, there's plenty of things we can do and gets a bit tedious. Thankfully, we've got Sentry set up and we can do it all in that one place. I'll show you how we got started. That's in the Sentry documentation page, docs.sentry.io, write it down. In any case, we've got our supported platforms in this button here. Pride of place, we have React on the front page, so you don't have to go far. Click into that, it's an easy installation, NPM install or Yarn add, and a few lines of code to configure it. What this will do is get Sentry on your application, hook it onto your global error handler. As users are interacting with your application, events and transactions are sent to Sentry, and that's where we can look and understand the health of our application. During that checkout fiasco, we did get notified through an alert that was set up. We don't have time today through this lightning talk to go into alerts, but just know that it's there. We've got our summary of our error right away, including the magnitude, how many times it's happened to how many users, contextual tags as well. We can add our own tags if we'd like, but let's just skip ahead and go to what we're all thinking about. That's the stack trace. In a Sentry-less world, we'd get minified stack trace, which is not the funnest thing to understand. But during our build process, we've uploaded our source maps and Sentry is able to take our source maps against the stack trace that was provided and unminify in this beautiful stack trace we've got here, human readable, highlighting the exact line that it hit on for this error. We've even got this if statement details on that, and the response that okay was false. That's not good, but we'll keep that in mind and continue looking at more context. We've also got a timeline of the events which we can filter by. We can change the time frame to a more T minus style, and we can add our own breadcrumbs as well. That'll help us with understanding what led up to this error. Since this error happened multiple times, around 60 times, we've collected the tags from all the errors in this heat map on the right. We've also got all our issue tracking integration set up handy over here where we can link to existing tickets or create a new ticket from here as well. Now that we've got all the context and content from our stack trace from the front-end perspective, I want to call our attention to distributed tracing. This feature that we have since we've also got Sentry set up on our back-end service. Clicking here, we can see that there's a related error. There's this exception that happened on our back-end. We might want to work with our back-end team to figure out what was going on with that. I'll just give us all a hint since we don't have that much time. It's a problem without enough inventory and there wasn't a good way to deal with that. An error happened in the back-end, happened on front-end, blah. In any case, let's switch gears and go to our performance page. This will give us our performance health of our application. Web vitals are listed out on the front, how long things took for the first thing to load, largest thing to load, input delay, latency distribution, and over time, we can adjust the time-frame from the past day to another time-frame. But let's remember that the products page took a long time to load. We can see that evidence on the high user misery score as well. You can highlight each of these metrics and it'll give you more details on how it was calculated. But let's follow our nose, go into the products page. We have our duration breakdown, how long it took for these transactions. This is an interactive graph, so I can adjust the time-frame over by highlighting or changing it up here as well. But what I think might help most is taking a look at the operation duration. It's highlighted in this HTTP red, it's covering basically all of it. That's very curious. HTTP red is not an official color, but that's what I'm calling it. Clicking into a specific event, we can see the operation duration in this waterfall type of graph. If we just had Sentry installed on our front-end, this is exactly what we'd see. But we also have this plus. That indicates we've got Sentry set up on the back-end as well, and we can see how the transaction was carried over from a front-end request to the back-end to get the details on our products and get it returned to us on the front-end. A lot of the details are on these database queries and we can see it's sequential, not the most optimal. We might want to work with our database team, our back-end team to optimize these database queries, maybe asynchronous processing. In any case, we've got a way to move forward. Just to recap for us, our React app was slow on loading the products, and we also got an error in our checkout process. Since we were notified, we could take a look at all the details on the back-end side and the front-end side with that distributed tracing. On the performance end of things, our performance health and web vitals are listed out in our performance page, followed our nodes and saw that high user misery score, and that led us to this page where we have our operation breakdown and we know that we can make improvements on our database queries. Thank you so much for walking through these problems in our demo site with me. Have a wonderful rest of your conference. Thank you very much. Thank you.


Vue.js Live Conference

Vue.js London Live 2021

Identify Issues and Prevent Slowdowns in your Vue.JS Apps

Hi there, my name is Simon. I'm a Solutions Engineer at Sentry. What we focus on is code observability. With Sentry, you can understand the health of your application from the front-end to the back-end. Sentry is designed for all developers, meaning we support all major languages and frameworks including Vue. With the Sentry SDK on your application, you can alert the necessary team members and enable your developers to optimize the developer and customer experience. The Sentry platform provides multiple perspectives on the health of your application. But what we'll be focusing on today is error monitoring and performance monitoring. To get started with Sentry, we would go to the Sentry documentation site, search for Vue, or click to see all 99 supported platforms. In this JavaScript section, we have a link to Vue. The installation process is very easy. It's an NPM install and a few lines of code to configure Vue on your application. What this will do is hook Sentry onto your global error handler, and as users are interacting with your application, events and transactions are sent to Sentry. What I've got on the side here is a demo Vue app, which is very basic, but let's just take a look together. I just refreshed it for us because I've set it up so that an HTTP request is sent on page load. We'll review what that means on the performance side of things, but for now, let's click onto these error buttons. As these errors are happening, they're also being sent to Sentry. I've configured some alerts for us, so we're actually getting notified of these errors as they're happening. On Slack, I just clicked into a notification that'll take us straight to this error, and these details on the error are all displayed in front of me. We got the error, the error message, the magnitude of this error, how many times it happened, against how many users. We also integrate with source control management systems, so we have details on maybe the commit that could have caused this as well, links to those commits, contextual information through these tags like the user details, the environment they're in. We can add our own tags, but what we probably care about the most at this point is the stack trace. That's right below, and in a Sentry-less world, we'd be dealing more with a minified stack trace, optimal for performance, but not great for human readability. But thankfully, Sentry helps out with that. During our build process, we had uploaded our source maps, Sentry took that, translated the stack trace for us, and we have this beautiful human readable stack trace, including highlighting the line where the error happened, and we see that the response at okay was false. We also know the file to take a look at as well. Let's all keep that in mind, very curious stuff. But just below that, we have more context, a timeline of the activities in our breadcrumbs. We can add our own breadcrumbs as well, and this is all automatically instrumented. We can adjust the time to a more T minus format where when we hit time equals zero, we hit that internal server error. This is all great to get more context. If that wasn't enough, this error had happened about 50 times. We've actually gathered all the tags from all these errors into this heat map section to the right. With all this information, the context and content from the front-end perspective, we can consider creating a new ticket or linking to an existing ticket through these integrations with issue tracking tools. I also want to bring our attention to the distributed trace feature we have in Sentry. Since we have Sentry installed on our back-end as well, we see a relationship. We see that there is a child event and a related error that we should take a look at. This is referring to that response that okay was false, coming in from our back-end. If we click into this, we can see the back-end tags, back-end stack trace, back-end breadcrumbs, everything that we see here, but just from the back-end perspective. Let's just switch gears for a moment here. There's a lot on the issue side and we've got just enough time to check out the performance health that is provided by Sentry. Right away, we see our web vitals. That's how long it takes for the first thing to load, largest thing to load, input delay, stability of our page, latency over time, and distribution over the past 24 hours. That was quick, right? Lightning talk. But what is standing out here is the user misery score. As I highlight over it, it gives us a definition of this metric. The same goes for all these other metrics as well. But let's just follow our nose, click into the homepage transaction here, and you can see the duration breakdown, how long it took for these transactions to complete over the past, in this case, 24 hours. We can interact with this graph, highlighting a different section. That'll update the time-frame, of course, and also the events that show up. Most of the operation is covered in this HTTP red. Clicking into an event ID, we can take a look at the operation breakdown in this waterfall type of graph. It took about 15 seconds for this transaction, and most of the operation time was coming from this HTTP client request. This is going to our backend, and we can see that because we got this plus icon here. We got distributed trace setup. If we didn't, we would just not see this plus icon and we can't expand it. Luckily, we can and we can see that a lot of this time is through these sequential database queries. Now we have a way to move forward, work with our backend team, optimize these database queries, make it like an asynchronous processing type of situation, and that'll improve that user experience, reduce that user misery as well. Just to recap for a moment here, on our view app, we clicked a few of these error buttons. We're notified through our integration with Slack to get to our error page, looking at the full context and content from the front-end perspective, and with distributed trace, could also do it from the backend perspective. On the performance health side of things, we have a summary of that health through these web vitals, followed our nose through that user misery score on that homepage transaction, took a look at the operation breakdown, and we can make some improvements on these suboptimal database queries. In any case, thank you so much for reviewing this view app with me. Have a wonderful rest of your conference. Thank you very much. Thank you.


Building a Sentry: 7 years of open-source React

Evan Purkhiser

David Wang

#error monitoring