Scroll down for the author’s photo and bio. Time series databases like InfluxDB index data by time. They are efficient at recording constant data streams like server metrics, application monitoring, sensor reports, or any other data containing a timestamp. The structure makes analyzing change over time a breeze. This tutorial will show you how to set up InfluxDB with a sample Ruby application.

OpenTelemetry is a project by the Cloud Native Computing Foundation aimed to standardize the way that application telemetry data is recorded and utilized by platforms downstream. This application trace data can be valuable for application owners to understand the relationship between the components and services in their code, the request volume and latency introduced in each step, and ultimately where the bottlenecks are that are resulting in poor user experience.

When running and maintaining an application in a production environment, we want to feel confident about the behavior of the application and know when it isn’t working as expected. At the least, we want to track errors, monitor performance, and collect specific metrics throughout the application.

If you maintain a Ruby gem, you are definitely familiar with the recurring manual tasks surrounding the release of a new version. After doing this for a while, you inevitably start thinking that some of these steps could be automated. They can! With a few lines of code, you can bring the amazing world of continuous delivery to your project and increase the reliability of the whole process while freeing up some of your time. Double win!

In this tutorial, we will go through a working example of a Ruby application auto-instrumented with OpenTelemetry. To keep things simple, we will create a basic “Hello World” application, instrument it with OpenTelemetry’s Ruby client library to generate trace data and send it to an OpenTelemetry Collector. The Collector will then export the trace data to an external distributed tracing analytics tool of our choice.

Google Cloud Platform provides developers with many tools to build scalable apps in a way friendlier than AWS. In this article, Olasubomi Oluwalana shows us how we can use the Google Cloud Engine, Storage, and PubSub offerings to build an uptime monitoring system in Ruby.

Tired of composing the same endpoint searches over and over while working on performance issues? We've got you covered with our new Saved Searches feature! It allows you to bookmark your commonly used endpoint searches by app component, so instead of having to remember an exact query, you can just save it so you don't have to sift through the endpoints list again. It's just another way we try to help our users get answers, not just a bunch of data.

Linting is the process of statically analyzing code in search of potential problems. What constitutes a problem, in this case, can vary across programming languages, or even across projects within the same language. I would put these problems under a few different categories: Let’s take a look at a few examples of each.

Setting up a proper monitoring overview over your application’s performance is a complex task. Normally, you’d first need to figure out what you need to monitor, then instrument your code, and finally make sense of all the data that has been emitted. However, with a few things set in place, and an APM that natively supports Ruby, it’s easier than ever to take this step. In this post, we’ll show you how you can do it too.