In this article, you’ll learn how to capture error logs in your Cloudflare Workers application using AppSignal. We’ll build a simple workers project and integrate AppSignal’s code to collect the necessary metrics. We’ll also learn how to utilize AppSignal’s dashboard to analyze and track errors. Let’s get stuck in!
Since the launch of uptime monitoring, we have received a lot of positive feedback. There were also a couple of much-requested additional features that we hope to address in this huge update.
Good logging practices are crucial for monitoring and troubleshooting your Node.js servers. They help you track errors in the application, discover performance optimization opportunities, and carry out different kinds of analysis on the system (such as in the case of outages or security issues) to make critical product decisions. Even though logging is an essential aspect of building robust web applications, it’s often ignored or glossed over in discussions about development best practices.
Today, we’re launching a major upgrade that will improve the way yourteam manages application errors, with more error states, error assignments,severity labels and a “my incidents” overview. Your team’s communication around incidents will improve significantly.You’ll know exactly how severe an error is, who’s responsible, and howyou handled this error historically.
We’re launching a new line-of-code based method of grouping errors. Ifyou enable this grouping method in “App settings”, we will find the lineof code that was the source of the error and use that to split out errorsthat otherwise have the same type. To access the feature, upgrade to the latest AppSignal APM for Node.js integration. This is especially useful for Node.js andElixir parts because in these languages different errors often have the same type.
It’s important to be able to look at the entirety of your application architecture, not just specific aspects of it, and understand how different parts connect. Observability comes first, followed by monitoring. In this post, we’ll dive into the database part of your architecture to show how you can monitor and optimize your database performance.
When we were moving an app to Kubernetes, we encountered a peculiar situation where other services running on Kubernetes started throwing a ThreadError from time to time, saying that a resource is unavailable. We started investigating, and it turned out that you want to know where your AppSignal error has occurred. A short reminder - Kubernetes works on two levels: So, you want to know which pod and which node ran a particular AppSignal transaction.
Even if you write the fastest code in the world, you can still be slowed down by external factors. In this post, we will deal with performance monitoring external APIs and how you can prevent these slow APIs from slowing you down.
Tests are an integral part of most well-working Rails applications where maintenance isn’t a nightmare and new features are consistently added, or existing ones are improved. Unfortunately, for many applications, a production environment is where they are put under heavy workload or significant traffic for the first time. This is understandable as such tests are costly.
We recently released uptime monitoring, a pretty big addition to our set of features. Our customers have often requested it, and it was a logical next step for us to add uptime monitoring to our app. In today’s post, we’ll explain how we went from considering uptime monitoring impossible to build, to building it in a week. We’ll break down how seemingly over-engineering can really pay off in the end.
