Besides just error reporting, Sentry also provides performance monitoring to help ensure your view applications are running quickly and smoothly. Performance monitoring has already been set up for us via the installation snippet we copied and pasted in an earlier lesson. The relevant pieces of that snippet include the import of integrations from the Sentry tracing package and the registration of the browser tracing integration. There's also one more Sentry configuration option worth mentioning that has to do with performance monitoring.
That is the Trace Sample Rate option. By default, this option is set to 1. This is the recommended value for when you're getting performance monitoring set up and testing as it ensures that every transaction will be sent to Sentry. Once testing is complete though, it's recommended to lower this value in production.
2. This means that only 20% of transactions will be sent. This is important because a value of 1 means that a new transaction is sent to a sentry each time a user loads any page or navigates anywhere in your app, which is a lot of transactions. Sampling only 20% on the other hand enables you to collect representative data without overwhelming either your system or your Sentry transaction quota.
Alright, if we head over to the Sentry dashboard now and go to the performance page, then we can see some of the performance data that Sentry has been collecting since the start of the course. We've got some web vitals here such as First Contentful Paint and Largest Contentful Paint, and you can see charts with the counts of those from the last 24 hours. You might be used to seeing such metrics in a tool like PageSpeed Insights. But the big difference is that these are real numbers from real users, not just numbers run from your own machine.
That's pretty cool. If you scroll down, you can also see some performance metrics for specific pages. That's pretty awesome that Sentry knows how to work with Vue Router so well. This is possible because the browser tracing integration creates a new transaction for each page load and navigation event.
Alright, let's click into the transactions for the About page and see what other juicy information is available. The first chart we're presented with here shows what percentage of transactions took how long over time. The lower the peaks here, the better. Scrolling down, we can even see each individual transaction that occurred for the About page.
We can also filter them to show slow transactions, fast transactions, outlier transactions, and the most recent transactions. By clicking into an individual transaction, we can see even more information, including the event duration, some web vitals, some tag details, and a waterfall chart breaking down all the steps in the transaction, known as spans. Clicking on each span also gives us more info about the individual spans. Very helpful.
Besides these built-in metrics, you can even provide what's called custom instrumentation to measure the performance of custom transactions in your code. For instance, you can measure the time it takes to validate and process a payment. We won't do this together, but you can see the specifics in the Sentry docs linked below. Lastly, Sentry will also attach a Sentry trace header to AjaxRequest made to your backend APIs.
So, That way, if you're using Sentry on your front end and back end, they can be combined into a single coherent trace in the Sentry dashboard. Besides just error reporting, Sentry also provides performance monitoring to help ensure your view applications are running quickly and smoothly. Performance monitoring has already been set up for us via the installation snippet we copied and pasted in an earlier lesson. The relevant pieces of that snippet include the import of integrations from the Sentry tracing package and the registration of the browser tracing integration.
There's also one more Sentry configuration option worth mentioning that has to do with performance monitoring. That is the Trace Sample Rate option. By default, this option is set to 1. This is the recommended value for when you're getting performance monitoring set up and testing as it ensures that every transaction will be sent to Sentry.
Once testing is complete though, it's recommended to lower this value in production. 2. This means that only 20% of transactions will be sent. This is important because a value of 1 means that a new transaction is sent to a sentry each time a user loads any page or navigates anywhere in your app, which is a lot of transactions.
Sampling only 20% on the other hand enables you to collect representative data without overwhelming either your system or your Sentry transaction quota. Alright, if we head over to the Sentry dashboard now and go to the performance page, then we can see some of the performance data that Sentry has been collecting since the start of the course. We've got some web vitals here such as First Contentful Paint and Largest Contentful Paint, and you can see charts with the counts of those from the last 24 hours. You might be used to seeing such metrics in a tool like PageSpeed Insights.
But the big difference is that these are real numbers from real users, not just numbers run from your own machine. That's pretty cool. If you scroll down, you can also see some performance metrics for specific pages. That's pretty awesome that Sentry knows how to work with Vue Router so well.
This is possible because the browser tracing integration creates a new transaction for each page load and navigation event. Alright, let's click into the transactions for the About page and see what other juicy information is available. The first chart we're presented with here shows what percentage of transactions took how long over time. The lower the peaks here, the better.
Scrolling down, we can even see each individual transaction that occurred for the About page. We can also filter them to show slow transactions, fast transactions, outlier transactions, and the most recent transactions. By clicking into an individual transaction, we can see even more information, including the event duration, some web vitals, some tag details, and a waterfall chart breaking down all the steps in the transaction, known as spans. Clicking on each span also gives us more info about the individual spans.
Very helpful. Besides these built-in metrics, you can even provide what's called custom instrumentation to measure the performance of custom transactions in your code. For instance, you can measure the time it takes to validate and process a payment. We won't do this together, but you can see the specifics in the Sentry docs linked below.
Lastly, Sentry will also attach a Sentry trace header to AjaxRequest made to your backend APIs. So, That way, if you're using Sentry on your front end and back end, they can be combined into a single coherent trace in the Sentry dashboard.