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!
As of the latest release, Instana supports the monitoring of Ruby applications running on Fargate, a serverless container orchestrator managed by Amazon Web Services. This enables Ruby teams to take advantage of the benefits Fargate offers while still being able to use Instana’s world class observability and monitoring tools.
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.
In the latest Instana release (Instana Release 201), AutoProfile for Ruby is generally available. This allows teams developing and supporting Ruby based applications to continuously collect and analyze CPU profiles, without modification to their applications[1]. To help acquaint you with how AutoProfile for Ruby can enhance your observability workflows, let’s walk through a simple example of when profiling can enhance our tracing experience.
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.
This week we released Skylight version 5.0, which represents a major undertaking that has involved every person at Tilde and every part of our ever-growing stack. In addition to major internal refactors, this release also modernizes our native Rust code, and introduces Skylight's newest feature, Source Locations.
Logging is tricky. You want logs to include enough detail to be useful, but not so much that you're drowning in noise - or violating regulations like GDPR. In this article, Diogo Souza introduces us to Ruby's logging system and the LogRage gem. He shows us how to create custom logs, output the logs in formats like JSON, and reduce the verbosity of default Rails logs.
