Software Engineering and Stuff

Modern telemetry libraries allow easily configuring auto instrumentation, to automatically gather observability data about frameworks and libraries.

There are two main approaches to architecting those auto-instrumentation libraries. As middlewares/wrappers, or as monkey-patches. I believe middlewares are much better, here’s why.

OpenTelemetry is making observability much easier, especially by providing the first widely accepted vendor agnostic telemetry libraries. The first signal the project implemented is tracing, which is now GA in most languages.

Ever since we need to operate hardware and software in production, we have needed to know how those behave. For example, when I brew craft beer, I use an iSpindle to monitor the temperature and the gravity of my wort.

In this article, I would like to suggest the use of a very common pattern in Go, Functional Options, but adapted to the Ruby language.

OpenTelemetry is a quite new tool meant to provide a standard interface to for handling metrics and traces.

It provides libraries in all main languages, and its collector component allows receiving data from any app in any language, and transmitting them to any observability platform.

Incidents are inevitable. Any platform, large or small will have them. While resiliency work will definitely be an important factor in reducing the number of incidents, hoping to remove all of them (and therefore reach 100% uptime) is not an achievable goal.

We should, however, learn as much as we can from incidents, so we can avoid repeating them.

Prometheus is an Open-Source monitoring system and time-series database. In this post, I am going to dissect some of the Prometheus internals – especially, how Prometheus handles scraping other components for their metrics data.

I recently finished reading How to Read a Book.

I didn’t read this book with programming in mind. However, while reading it I kept thinking that we could apply the same approach to reading and understanding a programming project.