Metrics are used in a variety of domains, not just software. However I am a software developer: so in this article we’ll focus on some considerations worth keeping in mind when metrics are used for software observability, specifically timeseries metrics, with a deep dive in the Prometheus modelling for different types of metrics.

Let’s jump to a definition, how can we define a metric?

A metric is an aggregated measurement taken at a given point in time, sampled at regular interval.

Read more...

The OpenTelemetry collector is a software whose main responsibility is to act as a centralised receiving point for all your observability signals like Metrics, Logs and Traces, and forward these signals to your observability tooling of choice. In additon to that, the OpenTelemetry collector can filter and transform the incoming data: more importantly for today’s discussion, it can compute new data from the incoming one. There is a growing trend to compute metrics from traces, with connectors like the spanmetricsconnector or the servicegraphconnector. The fact that the distributed tracing scene is far more standardised around the OpenTelemetry standard compared to the metrics one makes this an appealing idea to also be able to produce a set of standardised metrics, in a language agnostic fashion: that’s exactly how solutions like Grafana Labs Application Observability try to achieve this promise of language agnostic observability solution. While I’m onboard with the idea, I am not convinced that it should be the OpenTelemetry collector responsability to compute these aggregation metrics from the traces.

In the era of “always on” services and cloud platform, observability practises have become a central enabler to achieve this. But what is observablity? For starter, observability is not something strictly related to Software: in fact the concept of observability can be defined in much broader terms.

Observability is a property of a system. A system is said to be observable if the internal state of the system can be inferred by the output signals generated by the system.

Read more...

This article explains Service Level Objectives (SLOs), a monitoring practice aimed at ensuring systems provide an acceptable level of service. As with any practice, it won’t make systems reliable on its own; developers need to follow it consistently for it to be fruitful. It requires discipline and time to become familiar with it, but it’s a rewarding journey that you can add to your CV. If you’re passionate about the topic, feel free to read the complete Google SRE books; if not, we’ll link specific chapters in the following paragraphs that will give you a good grasp of the subject.

At the beginning of my career, I was tasked with testing a ticket developed by a very senior developer on my team. When I opened the test instructions, to my surprise, I found this:

Just deploy the changes to the staging environment. If something is not working, we’ll get alerted.

It was only a few years later when I really understood the wisdom behind this sentence, and this article will try to explain why alerting should be tought as a superset of testing.

Recentely I was asked if I had any experience in Kubernetes: well, long story short, I don’t :)

But it poked my interest a bit, so I decided to give it a try and see what I can learn about it in a short time. It’s a rainy Sunday, so it seems like a perfect day to concentrate and take a deep dive on the topic. Ideally I’d want to be able to deploy a couple of services in Kubernetes and have them communicate with each other.

Hello there, welcome! You migth be wondering why does this corner of the web exist: let me try to answer the question.
I had the idea of creating a personal page in the back of my mind for a long time, mostly because I wanted to establish a stronger online presence than my empty LinkedIn profile. I wanted something that could represent me better than a CV, but that also would require little maintenance on my side.
On another note, I feel like I learn a lot of interesting things in my daily endevours and I would like to formalise these learnings in a written form to serve 2 main purposes:

About myself

Hello, it’s a me Stefano! Writing software for money and playing basketball for fun, although my younger self would have preferred the opposite :) Born in Italy and currently living in Barcelona.

Career

Ocado Technology (Aug 2019 - present)

Worked with all the things in the Observability domain. Developed in-house monitoring system as well as best practises and guidlinesusing third party tools, like GrafanaCloud, CloudWatch, NewRelic, and Pagerduty. Conducted internal trainings, talks and write-ups to spread the observability culture.