Learn about tools to trace frontend to backend data and increase visibility on errors and performance. We'll go through how to know which teams are responsible for which error, what the impact is, and all the context needed to solve it.
![Remix Conf Europe 2022](https://gitnation.imgix.net/stichting-frontend-amsterdam/image/upload/v1661425206/dev/guI6jYXx_400x400_nfiekh.jpg?auto=format,compress&fit=scale&w=60)
Learn about tools to trace frontend to backend data and increase visibility on errors and performance. We'll go through how to know which teams are responsible for which error, what the impact is, and all the context needed to solve it.
Sentry is a monitoring platform designed for developers to track errors and slowdowns in applications. It provides real-time alerts, insights into code performance, and detailed information about issues such as error occurrences and transaction failures.
Sentry provides error monitoring, performance tracking, and release health checks specifically tailored for JavaScript applications. It alerts developers about code slowdowns and errors, allowing them to quickly identify and resolve issues to optimize both developer and customer experience.
To set up Sentry for a JavaScript project, you need to install the necessary packages using Yarn add or NPM install, configure the project with 'Sentry init', and include a Data Source Name (DSN) which tells your application where to send error and transaction events.
Sentry's error monitoring features include real-time alerts, detailed error tracking across releases, and contextual data aggregation. It also provides human-readable stack traces and a timeline of activities leading up to an error, helping developers diagnose and fix issues efficiently.
Sentry's performance monitoring includes tracking of web vitals like Largest Contentful Paint (LCP), detailed transaction summaries, and operation breakdowns. It identifies performance bottlenecks in real-time and helps developers optimize their code based on specific insights.
Sentry's release health monitoring organizes project details in releases, supports semantic versioning, and provides metrics like crash-free rate and adoption rate. It allows developers to sort and filter data to assess the stability and health of each version in production environments.
Sentry offers real-time notifications through various channels such as email and Slack. These notifications provide immediate alerts when errors or performance issues are detected, along with context and links to detailed views of the issues in the Sentry dashboard.
Sentry is an error monitoring platform that helps developers optimize the customer experience by alerting them of errors and slowdowns. It supports all major languages and frameworks, with a focus on error monitoring, performance monitoring, and release health. The Talk explores how Sentry organizes and represents error data, analyzes error details and tags, and investigates backend issues, performance problems, and release health. Collaboration with backend teams is emphasized to resolve issues and optimize transaction time. The Talk also highlights the importance of analyzing graphs, issues, and regressions to identify areas for improvement in release health.
Hi, I'm Simon, a solutions engineer at Sentry. We monitor errors and slowdowns in JS applications, connecting developers to the end user experience. With the Sentry SDK, we alert team members and developers of errors and slowdowns, optimizing the developer and customer experience. The Sentry platform focuses on error monitoring, performance monitoring, and release health. We support all major languages and frameworks, with Node.js as a starting point. We'll generate transaction and error data to demonstrate how Sentry organizes and represents them. Let's take a look at how errors are represented in Sentry, including frequency, contextual data, and tag information.
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, so 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 probably the 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 ad 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. And 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, right? 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. So 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, you know, some context behind the scenes as well of what just happened, but let's take a deeper look. So from that link, I'm taken to the who, what, when, and where of the error that we just experienced together, right? So 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. So that's really helpful. And also some aggregated tag information on the right over here. So 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 plan, large, medium enterprise. It's affecting all our users. So we want to take a deeper look into that.
Let's focus on the details of one of the 160 times this error has happened. We'll look at the tags, the stack trace, and the timeline of activities that led up to the error.
Now let's focus on the middle pane here. So 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. So the key value pairs for this specific occasion, MacOS 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. It 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.
We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career
Comments