Don’t you hate it when you see an uncaughtException error pop up and crash your Node.js app? Yeah… I feel you. Can anything be worse? Oh yeah, sorry, unhandledRejection I didn’t see you there. What a nightmare you are. 😬 I maintain all Node.js open-source repos at Sematext. A few of them can help you out with error handling, but more about that further down. Here at Sematext, we take error handling seriously! I want to share a bit of that today.

APIs have become the de-facto standard in building and running modern applications. They are an integral part of the automation workflow of any business and as more users rely on your APIs to power their applications, the need for them to be reliable is important. Any degradation in their health, availability, and performance will impact your business, so ensuring its reliability depends on proactively monitoring your APIs.

Let’s say you get an alert that one or more queries is slow. Or that your users complain, whichever comes first 🙂 We’ve all been there… How do you find the root cause for this slowness and then fix it? In this article, I’ll go through my usual thought process: first, I’d try to find which queries are slow. Then, I’d dig deeper: Let’s take a specific example and run through each step.

A large amount of data requires special tools. Apache Cassandra is one of those databases that can handle a large amount of data spread among many commodity servers, providing high availability and fault tolerance without a single point of failure. Developed under the umbrella of Apache Software Foundation, it ensures full visibility into the code base and being free of charge.

Sematext Logs is a Log Management-as-a-service. Think of it as your own central location for logs in the cloud. If you prefer or need to keep logs in your own environment instead of shipping it to the cloud Sematext Enterprise, designed to run on your own infrastructure, makes that possible. You can collect logs from any part of your software stack or infrastructure, IoT devices, network hardware, and much more.

Building SaaS products is hard. Making customers happy is even harder. I should know, I’ve built a start-up that failed! But, not everything is that bad. I learned a lot. Now I maintain a few open-source Node.js projects at Sematext. It’s an observability SaaS. I joined to help make the log management features as good as they can be. If you’ve never heard that term before, my co-worker wrote a great introductory explanation of what Log Management is right here.

Synthetic monitoring has been a staple of performance testing for years now and it’s probably going to stay that way for quite some time. Also called proactive monitoring, this relatively simple way of keeping track of the performance of your website, and is your safest bet to ensure you can rise to your visitors’ expectations.

When providing services to your customers you need to keep an eye on everything that could impact your success with that – from low-level performance metrics to high-level business key performance indicators. From server-side logs to stack traces giving you full visibility into business and software processes that underpin your product. That’s where cloud monitoring tools and services come into play.

This article is part 2 of a four-part series of articles about Elasticsearch performance monitoring. Part 1 explains what Elasticsearch is and how it works, while in this part, we’re going to look at Elasticsearch’s capabilities and potential use cases, and how to check its status. We’ll identify key metrics that you need to monitor to maintain the health and performance of your Elasticsearch cluster.

Imagine some users complaining that querying PostgreSQL is slow (this never happened right?), and we have to troubleshoot this problem. It could be one of two things: I would normally first check on the environment, specifically PostgreSQL metrics over time. Such monitoring shows if the CPU is too high or how many disk reads were buffer reads. PostgreSQL logs also give information about the environment, such as how many statements were run and if any errors occurred.