It’s January 2021 and you’ve probably broken five out of six New Year’s Resolutions. I don’t want to be the reason for breaking your last one, so I’ll cut right to the chase. We just released an update to our JavaScript SDK with the ability to track the health of your releases and support for Web Assembly. Still with me? Great.
In order to continuously improve your Ruby application, you need to understand everything your code touches. That means visibility into how your frontend responds to the database queries that are central to your Ruby application. Sentry’s new Ruby SDK collects and monitors the data surrounding your traces, logs, and key metrics. With it, you now have the context to connect backend issues to frontend performance.
No matter your business, keeping customer data secure is critical toward keeping your customer’s trust. With the rise in data breaches (and subsequent security certifications), we don’t have to tell you why you should scrutinize every cloud service that you consider — including us. To that end, we believe in being explicit with our compliance. And that includes how we pursue independent certifications like ISO, HIPAA, and now, SOC 2 Type II.
Slow is the new downtime. What you once feared from a downed website — decreased conversion rates, lower page ranks, abandoned carts — now applies to a slow-loading experience. Problem is, slow is more nuanced than downtime; that is, while downtime is binary — the site’s either up or it isn’t — slow is in the eye of its beholder. It’s why asking what makes a slow website gets the same shrug from a developer as asking them how long an afternoon is.
Performance monitoring is great because it lets you see whether your application is fast or slow, and which parts need speeding up. For Node developers, those “parts” are most often endpoints handling incoming requests. Since the introduction of our performance monitoring offering in July 2020, Node devs have been able to use the Sentry SDK, @sentry/node, to measure the total time it takes to process each request, but we made some significant improvements since then.
To us, dogfooding means using Sentry to improve Sentry. Here in this article, you’ll see how we used Performance to improve our search infrastructure. Recently, we extended our performance monitoring solution support to PHP and Serverless. We’re bringing it to Ruby and Java + Springboot soon too. But as some of you may have noticed, there’s also a new view in Performance, Trends. Trends shows you the most improved and regressed transactions in relation to releases.
To improve front-end performance in your application, it’s important to understand what kind of problems users are experiencing. They may be encountering slow load times, seeing unexpected shifts, or having trouble interacting with UI components. The question is, how bad is it? Is it perpetual-rage-click bad? Is it ditch-your-app bad? Is it rant-on-Twitter bad?
Sentry is excellent at capturing runtime errors in your applications. With the recent additions of performance monitoring and release health, it can further help as you build and ship code. Recently we used Sentry to ensure we didn’t break Sentry while doing a large refactor. When replacing an API or code path with a new implementation you’ll likely ‘deprecate’ the old path, but how do you know when that old path is finally not in use?
While Spring Boot provides everything developers need build applications, it leaves operational aspects of debugging issues to the developers and third-party services. If up until now all you had was log aggregation, where you can browse and filter through a web UI, prepare to have your mind blown with Sentry’s automatic error grouping, alerting, breadcrumbs, and much more. Sentry has recently launched a major update to the Java SDK. In the post, we’ll focus on Spring Boot and Logback.
Troubleshooting production issues in Lambda environments is often challenging. CloudWatch requires developers to comb through logs, search for relevant terms that they may not always know of and has hard-to-consume stack traces. For obvious reasons, we recommend using Sentry to instrument your Lambda Functions code in order to report error stack traces and associated debugging context. Here’s a walk through on how to instrument a Node function.
