DEV Community: Cristian Spinetta

A deadlock on an uncontended Tokio RwLock (caused by futures::executor::block_on)

Cristian Spinetta — Mon, 09 Feb 2026 21:52:52 +0000

A weird test hang

I recently hit a Rust test that hung forever:

no panic
no error
no timeout
just… silence

The confusing part: the code path only used tokio::sync::RwLock::read(). No writers, no contention. Two reads succeeded. The third read().await never returned.

That sounds impossible if you're thinking in "classic lock" terms.

But the root cause wasn't contention. It was executor semantics.

The minimal reproducer

I published a tiny repro repo that demonstrates the behavior:

cargo run → hangs (expected)
cargo run -- --fixed → completes

tokio-block-on-deadlock

The repro intentionally forces Tokio's cooperative scheduler to yield, then attempts another uncontended read lock.

The mental model mismatch

A common assumption is:

If a lock is uncontended, acquiring it can't block.

That's true for synchronous locks, but async is different. In async Rust, .await means:

Poll the future
If it can't make progress right now, return Poll::Pending
The executor will poll it again later

Crucially:

Pending does not always mean "the resource isn't ready".

Sometimes it means "yield for fairness".

Tokio's cooperative scheduling (the key)

Tokio uses cooperative scheduling. Each task has a limited budget to prevent a single task from starving others.

When that budget is exhausted, Tokio can intentionally return Poll::Pending to force a yield — even if the underlying resource is available.

Under a normal Tokio runtime, that's fine:

the task gets re-polled
the budget is reset
the operation completes on the next poll

This is usually invisible.

Where it goes wrong: `futures::executor::block_on`

In my case, I discovered that part of the test setup was driving Tokio async code using:

futures::executor::block_on(async { ... })

This is a common pattern in tests/mocks when you have a synchronous callback but need to call async code.

The problem is: futures::executor::block_on is not the Tokio runtime.

What it does is roughly:

Poll the future on the current OS thread
If it returns Pending, park the thread and wait for a wake-up

So when Tokio returns Pending for cooperative scheduling reasons, block_on treats it as "I should sleep until someone wakes me".

But in this scenario, there isn't a normal "external wake-up" to wait for. Tokio expected the runtime to re-poll the task.

Result:

the OS thread parks
the future never gets re-polled
the test hangs forever

And the lock looks "deadlocked" even though it's uncontended.

Why it happened on the third read

Because the cooperative budget is cumulative.

The first awaits didn't exhaust the budget. The third happened to be the first place where Tokio decided "you must yield now", returning Pending.

With small code changes, the hang could move earlier/later or disappear entirely — which is part of what makes this class of bug hard to debug.

A practical fix

The simplest rule:

If async code uses Tokio primitives, it must be driven by Tokio.

If you need to run async code from a synchronous context (tests/mocks/callbacks), one safe pattern is to drive it with Tokio's runtime handle on a separate OS thread:

fn tokio_block_on<F: std::future::Future + Send>(fut: F) -> F::Output
where
    F::Output: Send,
{
    let handle = tokio::runtime::Handle::current();
    std::thread::scope(|s| s.spawn(|| handle.block_on(fut)).join().unwrap())
}

In the repro repo, cargo run -- --fixed uses this approach and completes successfully.

Takeaways

Poll::Pending doesn't always mean "waiting for a resource"
Tokio relies on its runtime to re-poll tasks; mixing executors can break that assumption
Avoid futures::executor::block_on for Tokio tasks
If you must cross sync/async boundaries, drive futures using Tokio itself (or redesign the boundary)

This bug is rare, but it sits in a very common pattern: sync test/mocking glue calling async code. When it happens, it's deeply confusing — and completely silent.

Kafka lag exporter Standalone

Cristian Spinetta — Thu, 23 Jul 2020 19:42:56 +0000

To research and diagnose issues of Apache Kafka consumer groups I usually use a docker compose made up of Kafka Lag Exporter, Prometheus, Grafana and a Dashboard.

Here is the repo:

cspinetta / kafka-lag-exporter-standalone

Docker Compose with Kafka Lag Exporter + Grafana + Prometheus. Ready to ingest and viewing lag metrics.

In this post I want to tell you what it is about and how it can be useful for troubleshooting in case you don't have much visibility of your Kafka consumer groups.

Why this docker compose?

The main idea was to have a docker compose with Kafka Lag Exporter, Prometheus and Grafana together, so that it can be quick and easy to get a dashboard for analyzing the consumer groups of a Kafka deployment. This is particularly useful when you don't have enough monitoring on your Kafka yet. If we had not made a docker compose, we would have to install and configure each part separately, which could be a bit cumbersome when faced with an incident that needs to be resolved quickly.

It aims to provide a quick installation for troubleshooting and not a final installation for permanent monitoring. It's perfect if you are facing an issue in production and need more visibility about what is happening internally in Kafka.

Example use cases

Consumer group lag in seconds

In this graph we can see the time between last commit and current time, this is also known as lag in seconds, and we can see it by consumer group.

This example was taken from a Kafka-Connect that commits every 30 minutes if everything goes well, if we analyze it we can say that some consumer groups by some reason fail on commit.

Consumers group lag in seconds and offsets

In this other example, we can see a particular consumer group status. It shows the consumer group lag in seconds and messages/events (the difference between current message and last commited)

Getting started

Next, the steps we do when we have to use it:

Download and unpack it:

curl -fsSL -o kafka-lag-exporter-standalone.tar.gz https://github.com/cspinetta/kafka-lag-exporter-standalone/releases/download/0.0.1/kafka-lag-exporter-standalone-0.0.1.tar
tar -xf kafka-lag-exporter-standalone.tar.gz

Specify kafka nodes on kafka-exporter-standalone/kafka-lag-exporter/application.conf.
Run with docker compose: docker-compose -f kafka-exporter-standalone/docker-compose.yaml up.

Then you can open the Grafana webapp exposed at port 3000 and navigate to the dashboard Kafka Lag Exporter.

On the first time you enter Grafana ask you to login. Type admin for the username and password. Then Grafana will ask you to choose a new password.

That's all!

top-threads: a script for viewing real-time runqueue latency per thread

Cristian Spinetta — Wed, 22 Jul 2020 14:29:15 +0000

A few years ago, when I was working at Despegar I wrote a little python script that helped me a lot observing and identifying issues related to CPU usage.

cspinetta / top-threads

A tiny command line tool that provides a dynamic real-time view of the active threads for a given process with stats of CPU, disk and scheduling.

It's a user-friendly command-line interface that provides a dynamic real-time view of the active threads for a given process with stats of CPU, disk and scheduling.

The metrics make it really powerful is those related to scheduling: time spent on the cpu / on the runqueue.

Why?

In some cases it's interesting to know how much time the threads spend trying to get onto CPU, instead of being on CPU. This type of information can be easily obtained with tracing tools like perf and BCC, but these tools require root privilege, something that is often not available in production servers, so you can't use them for troubleshooting.

What came up?

I ended up developing a script in Python that allows me to visualize in real-time the run queue latency per task by reading the /proc/{pid}/schedstat file.

In fact, it shows some extra stats:

CPU usage: total, %usr, %system, %guest and %wait
Disk usage: kB read per second and kB written per second
Scheduler stats:
- time spent on the cpu.
- time spent waiting on a run queue (runqueue latency)
- number of timeslices run on the current CPU.
Java details: in case the target is a Java process that can be attached with jstack, some extra details is shown such as thread name and stack traces.

It requires:

Python 3
systat

It only works in Linux since it uses /proc/{pid}/schedstat to get scheduling stats.

How to use it?

I kept the code in a single file, so it's as easy as downloading the script:

wget -O top_threads.py 'https://github.com/cspinetta/top-threads/releases/download/0.0.1/top_threads.py' \
  && chmod +x top_threads.py

Example of usages:

# watch <pid>'s threads with default values
./top_threads.py -p <pid>

# print output in the terminal
./top_threads.py -p <pid> --display terminal

# sorting by run queue latency
./top_threads.py -p <pid> --sort rq

# in case a java process, change the number of stack traces to display
./top_threads.py -p <pid> --max-stack-depth 10

# enable debug log for troubleshooting
./top_threads.py -p <pid> --debug

Some things to keep in mind:

The first output is with stats from the first execution of the process.
--display refresh provides a view similar to top or watch (the default) while terminal prints the output on each iteration in the terminal like pidstat.

What is a good use case for this tool?

I often use this script when I have to analyze a performance problem at thread level and I want to inspect the dynamic usage of CPU or Disk.

Some questions this tool helps me to answer:

Which thread is eating the entire CPU?
How long are the threads waiting to take the CPU?
What threads are using the disk right now?

Example in pictures

With --display refresh (the default):

With --display terminal:

Usage

usage: top_threads.py [-h] -p PID [-n [NUMBER]]
                      [--max-stack-depth [STACK_SIZE]]
                      [--sort [{cpu,rq,disk,disk-rd,disk-wr}]]
                      [--display [{terminal,refresh}]] [--no-jstack] [--debug]

Tool for analysing active Threads

optional arguments:
  -h, --help            show this help message and exit
  -p PID                Process ID
  -n [NUMBER]           Number of threads to show per sample. Default: 10
  --max-stack-depth [STACK_SIZE], -m [STACK_SIZE]
                        Max number of stack frames (only when jstack can be
                        used). Default: 1
  --sort [{cpu,rq,disk,disk-rd,disk-wr}], -s [{cpu,rq,disk,disk-rd,disk-wr}]
                        Field used for sorting. Default: cpu
  --display [{terminal,refresh}], -d [{terminal,refresh}]
                        Select the way to display the info: terminal or
                        refresh. Default: refresh
  --no-jstack           Turn off usage of jstack to retrieve thread info like
                        name and stack
  --debug               Turn on logs for debugging purposes

Monitoring Production Methodologically (Talk with the transcript)

Cristian Spinetta — Tue, 21 Jul 2020 01:17:30 +0000

Versión en Español

(English version)

Fecha: 11/06/2020
Autores:

DiegoFollow

Software engineer from Buenos Aires, currently interested in performance and distributed systems.

Cristian SpinettaFollow

Software engineer working on distributed systems, reliability, and applied cryptography. Opinions are my own.

Esta es una transcripción editada y sintetizada de la charla Monitoring Production Methodologically que dimos en Despegar el 11 de Junio del 2020. En los últimos 5 años hemos trabajado juntos en diferentes proyectos como desarrolladores, y en el camino, hemos investigado y probado diferentes herramientas y técnicas para monitorear las apps. Esta charla, incluye muchas lecciones y técnicas aprendidas durante estos años.

Transcripción:

Esta es una charla sobre los aspectos a tener en cuenta a la hora de armar nuestro sistema de monitoreo.

Estas son algunas de las preguntas que queremos responder. Intentaremos ahondar el tema desde un punto de vista práctico. Si bien mostraremos ejemplos con algunas herramientas concretas, el foco estará en hablar sobre los lineamientos y aspectos a tener en cuenta, no en qué herramienta podemos usar.

Las ideas que vamos a compartir son aspiracionales, es decir, lineamientos que creemos que sirven de guía para lograr un sistema de monitoreo exitoso. Luego cada uno tendrá que analizar y decidir cuál es la forma más conveniente de bajarlo a su propio sistema.

En algún momento seguramente nos hicimos preguntas como estas, que fueron disparadores para empezar a pensar cómo construir o elegir un sistema de monitoreo para nuestras aplicaciones.

Y es posible que después de un buen esfuerzo, lleguemos a responder todas las preguntas que se nos han ocurrido, e incluso en el camino se nos ocurrieron muchas más, y las fuimos agregando. Como en este ejemplo, en el que “total, ya que estamos…”, le agregamos hasta el clima y el pronóstico del tiempo.

Si bien ese dashboard puede parecer muy completo, ¿qué tan eficaz es para resolver problemas en producción? ¿Es útil para hacer troubleshooting o comprender qué está andando mal?

Lo que sucede muchas veces, es que terminamos con dashboards que son como una sábana laaaarga, llena de métricas de todo tipo. Y luego, en medio de un problema en producción, nos volvemos locos tratando de comprender qué gráfico mirar y qué información nos está mostrando.

Entonces, ¿Qué preguntas de verdad importan? ¿cuáles deberíamos responder con nuestro sistema de monitoreo?

Hay 2 preguntas claves que debería responder: qué está roto y por qué.

Estas dos preguntas deberían guiar nuestro sistema de monitoreo.

Cuando intentamos responder qué está roto, estamos hablando de los síntomas que presenta nuestro sistema, lo cual es equivalente al impacto que estamos generando sobre los usuarios (ya sean personas, u otras aplicaciones).

Cuando intentamos responder por qué se produjo ese síntoma, estamos hablando de la causa que lo generó.

Cindy Sridharan, en un post sobre Monitoring And Observability, dice que nuestro sistema de monitoreo debería hacer visible o evidente cuál es el impacto que estamos generando sobre nuestros usuarios (what’s broken), como así también comprobar que el impacto desapareció, cuando subimos un fix.

Dejamos un link al capítulo 6 del libro de SRE de Google, de donde extrajimos este primer lineamiento, respecto al qué y el cómo. Y a continuación, vamos a centrarnos en cómo estas dos preguntas pueden guiar el diseño de nuestro sistema de monitoreo.

Para comprender mejor a qué nos referimos, veamos 3 simples ejemplos de Síntoma Vs. Causa.

En el primer caso, tenemos una API que responde 500s. El síntoma, es decir, lo que se percibe externamente, y por ende, la forma en que estamos impactando al usuario, es el hecho de estar devolviendo 500s. Mientras que la causa en este caso es que la Base de Datos nos rechaza las conexiones.
En el segundo caso, la API está respondiendo, pero de manera más lenta de lo esperado. Ese es el síntoma que se puede observar externamente. Mientras que la causa es que se están encolando requests. Es una causa intermedia, habría que analizar por qué se están encolando.
En el tercer caso, el síntoma es que los usuarios no se pueden loguear, y la causa es que el cliente de autenticación, está recibiendo 503.

Se llama "monitoreo de caja negra" a aquellos que capturan los síntomas, ya que estamos obteniendo una visión externa del sistema. Mientras que son "monitoreo de caja blanca", aquellos que capturan eventos internos del sistema, y que generalmente permiten comprender la causa.

Se dice que distinguir entre el qué y el comó, nos permite diseñar sistemas de monitoreo con señales más claras, y con menos ruido. Esta cita es extraída del libro de SRE de Google.

Un detalle que está bueno notar, es que las causas de nuestro sistema podría ser un síntoma en otro. Ese sería el caso del tercer ejemplo, donde tenemos un cliente que recibe 503, es decir, del otro lado hay un servicio que tiene el síntoma de no poder atender las requests.

Hay diferencias claves entre monitoreo de caja negra y monitoreo de caja blanca. Conocerlas, nos puede ayudar a armar gráficas y paneles más efectivos, que hagan foco en lo que intentan mostrar, ya sea un síntoma o una causa.

En el caso de caja negra:

El monitoreo debe pensarse desde el punto de vista del usuario (o bien, desde el requerimiento de negocio). Por ej, preguntas como ¿Qué tan rápido esperan los usuarios que les responda mi API?, nos llevaría a armar un gráfico sobre tiempos de respuestas.
Suelen estar controladas a través de SLIs y SLOs (luego veremos que son).
Son relativamente fácil de conocer, dado que en general se conoce de antemano los requerimientos que el servicio intenta satisfacer.
Este tipo de sistemas nos permite visualizar problemas activos, es decir, que ya están ocurriendo e impactando al usuario.
Esto quiere decir que debemos actuar de forma reactiva: cuando vemos un problema, tenemos que salir corriendo a solucionarlo, porque se trata de algo que ya está impactando a los usuarios.
En general, las alertas de un sistema de monitoreo de caja negra, tienden a ser las últimas en saltar.
Usualmente se resuelven por las personas que están de guardia.
Y generalmente están compuestos de pocas métricas, dado que el usuario típicamente no espera cosas muy complejas de nuestros servicios, simplemente quiere que funcione en tiempos adecuados, de forma adecuada, que no haya errores, etc.

En el caso de caja blanca:

El monitoreo debe pensarse desde un punto de vista bien técnico, basado en la arquitectura de nuestro servicio. Generalmente se controlan a través de umbrales, dentro de los cuales podemos afirmar que nuestros componentes funcionarán bien.
En general, es más difícil saber qué nos interesa monitorear, y cómo, ya que depende de conocimiento y experiencia técnica sobre los componentes del sistema.
Detectan problemas inminentes, es decir, que quizás aún no produjeron ninguna consecuencia, pero que de continuar así, pronto lo harán.
Permiten accionar de forma proactiva, dado que permiten adelantarse a los síntomas que están por ocurrir. Por ejemplo, si vemos que el espacio en disco pasó un umbral, podemos afirmar que de continuar así, pronto nos quedaremos sin disco, lo cual puede ser algo que genere algún impacto sobre el usuario, y por lo tanto podemos reaccionar de forma temprana, previniendo el problema de quedarnos sin disco.
En general tiende a tener alarmas tempranas, que nos pueden prevenir incidentes.
Suele haber soluciones automáticas, por ejemplo, autoscaling, rollback automático, circuit breaker, etc.
Y aquí si queremos tener bastante métricas, tantas como el sistema lo necesite para demostrarnos que está bajo un estado aceptable.

De todas estas diferencias, hay una que es clave: el enfoque con el que se enfrentan los problemas. Mientras que en uno de caja negra, el enfoque es reactivo (es decir, reaccionamos cuando el usuario está siendo afectado), en uno de caja blanca, podemos actuar de forma proactiva, antes de que el usuario se vea afectado.

Ambos tipos de monitoreo son importantes y se complementan.

A continuación, algunas buenas prácticas que fuimos incorporando.

La simplicidad es la principal optimización de cualquier sistema. El sistema de monitoreo es como cualquier otro sistema de Software, fácilmente se puede complejizar y tornar inmanejable, entre otras deficiencias. Mantener las cosas simples, ayuda a que sea fácil de comprender, de mantener y de modificar.
Debe ser fácil de leer y comprender. En otras palabras, tiene que ser expresivo.
No desagregar innecesariamente. Por ejemplo, si estoy midiendo tiempos, elegir apropiadamente 3 o 4 percentiles, si quiero medir errores, elegir cómo contabilizarlos, si voy a contar cantidad de errores o cantidad de success, y contar solo uno, etc.
Mantener los gráficos limpios y ordenados.
Las métricas y alertas que rara vez usamos, son candidatas a ser eliminadas. O bien, deberíamos pensar que cambios hay que hacerle para que pase a ser más relevante.
En lo posible, tener pocas métricas, y no duplicarlas. A veces, tenemos la misma métrica tomada con distintos sistemas. Evitar la redundancia, si no, después no sabés que mirar.
Poner especial atención a cómo estamos midiendo. En general, usar series de tiempo, que permitan graficar líneas continuas, es preferible a hacer checks discretos, como haríamos con Nagios por ejemplo.
Evitar los promedios. Esto más que nada cuando estamos midiendo tiempos. Es preferible guardar los tiempos en buckets, y visualizar la distribución, por ejemplo, percentil 50 / 75 / 90 / 99 / 99.9 / etc. También tener presente cómo están configurados los buckets, y si son acorde a los tiempos que queremos registrar.
Poner un ojo en los picos, por ejemplo el percentil 99.9, o 99.99 (o más, eso depende mucho del servicio que estamos analizando). Es importante no olvidarnos de estos picos, que según la cantidad de tráfico, pueden ser significativos.
Seleccionar apropiadamente la resolución, acorde a lo que estamos midiendo. La mayoría de las veces, la default que traen los herramientas, no sirve.

Ahora vamos a mostrar 2 de las metodologías más utilizadas para monitorear.

USE Method es una metodología creada por Brendan Gregg, un especialista en análisis de Performance. Es una metodología orientada al análisis de performance, que se centra en analizar 3 aspectos de cada recurso: utilización, saturación y errores. El dice que analizando estos 3 aspectos de cada recursos, vamos a poder resolver el 80% de los casos.

La utilización es qué porcentaje del tiempo está ocupado el recurso.
La saturación se puede ver como una cola de tareas a despachar por el recurso. La cantidad de tareas que están encoladas, representa el grado de saturación del recurso.
Errores tiene que ver con las fallas del recursos. Se puede contabilizar como un ratio del tipo errores / total de requests.

Si bien esta metodología fue creada para hacer análisis de performance, puede servir como guía para crear nuestro sistema de monitoreo de caja blanca, ya que podríamos analizar estas 3 características en cada componente / recurso que nos interese monitorear.

The Four Golden Signal es una metodología presentada por Google en su libro de SRE. En este libro dicen que si solo pudieras medir 4 métricas de tu servicio, deberían ser la latencia, el throughput, los errores y la saturación. Esas métricas son suficiente para detectar la mayoría de los problemas.

Es una metodología para desarrollar un monitoreo de caja negra.

La Latencia, es el tiempo que tardamos en realizar algo que nos solicita el usuario. En general es el tiempo que tardamos en responder una request, o el lag en un pipeline de datos.
El Tráfico, es la cantidad de requests que estamos recibiendo. Es importante observar el tráfico, porque siempre debería cambiar de forma esperada. Si cambia de forma inesperada, puede ser síntoma de que alguien nos puso en una blacklist, o bien, que no está pudiendo consumir nuestro servicio.
Errores. Siempre es importante conocer cuántos errores tenemos y si estamos bajo una cantidad de errores aceptables.
Saturación, ¿Qué tan estresado está nuestro servicio?. Esta métrica puede estar compuesta por diferentes aspectos de nuestro sistema. Depende mucho del tipo de servicio que estemos ofreciendo. Podría ser la cantidad de requests encoladas, o bien, si es una app CPU Bounded, si la CPU está saturada podría indicarnos si el servicio está saturado o no, etc.

Este es un ejemplo de uno de nuestros servicios, monitoreado con The 4 Golden Signals. En el caso de esta aplicación, como hace un procesamiento asincrónico de los eventos que recibe, un indicador de que el servicio está saturado es la cantidad de eventos que estamos reteniendo en la cola.

Para armar nuestro sistema de monitoreo, podemos tomar algunas ideas y prácticas de SRE, ya que monitoring es una parte core de este rol.

Por supuesto que SRE es mucho más que monitorear aplicaciones, y ni hablar si tomamos en cuenta cómo lo aplica Google. Siendo consciente de que no somos Google, ni Twitter, ni Netflix, sí creemos que es interesar tomar las cosas que nos sirven de estas prácticas, y llevarlo a nuestra realidad.

Uno de los objetivos centrales de SRE es medir qué tanto se está cumpliendo con las expectativas del usuario. Para poder cuantificarlo de manera objetiva, selecciona una serie de indicadores claves, llamados SLI (Service Level Indicator), que permitan medir si se está cumpliendo con la calidad de servicio que se pretende brindar.

En Google, hay un "menú de SLI", que tiene una lista de SLIs a aplicar en cada tipo de servicio, según la forma de interactuar que tenga el servicio con los usuarios. Por ejemplo, en un servicio donde los usuarios interactúan a través de un esquema Request / Response, 3 SLIs claves serían la disponibilidad, la latencia y la calidad de las respuestas. La calidad puede ser una métrica interesante, si tenemos algún mecanismo de graceful degradation. Del mismo modo, si tenemos un servicio que funciona como un pipeline de datos, donde los usuarios ingresan un evento para que este sea procesado y disponibilizado, nos va a interesar observar otro tipo de indicadores, y sí podemos continuar con otros tipos de servicios.

El menú sirve como una guía inicial, luego hay que analizar las necesidades particulares de cada servicio.

Entonces, la forma de elegir los SLIs apropiados para mi servicio sería la siguiente:

El primer paso sería elegir los SLIs apropiados para el servicio que quiero monitorear.
El segundo paso sería especificar qué eventos vamos a considerar válidos para el SLI, y qué condición deben cumplir para ser contabilizados como eventos exitosos o buenos.
Finalmente, como tercer paso, deberíamos especificar desde donde vamos a obtener estos eventos, básicamente que tan cerca del usuario o de las apps nos vamos a situar.

Aquí un ejemplo sobre cómo podríamos agregar 2 SLIs para medir la disponibilidad y la latencia de un servicio que expone información de los usuarios.

En el caso de la Disponibilidad, podemos especificar que queremos observar el porcentaje de GETs que se completan con éxito, y como implementación, podemos especificar que vamos a registrar como eventos válidos todas las requests que devuelven 200s o 500s como status code, y como eventos exitosos, los que devuelven 200s. Entonces, podemos hacer un ratio de cantidad de 200s sobre cantidad de 200s + 500s, obteniendo el porcentaje de GETs completados con éxito.

Para la latencia, podemos especificar que nos interesa medir el porcentaje de requests que devuelven un 200s como status code, en menos de 500 milisegundos. Como implementación, podemos especificar que los eventos válidos son todos los 200s, y los exitosos son los 200s que se resuelven en menos de 500 milisegundos.

Lo interesante es que definiendo eventos válidos y eventos exitosos para cada SLI, podemos llevar todas las mediciones a porcentajes, es decir, tendríamos una unidad en común para todos los SLIs. Luego, dado que son porcentajes, podemos establecer fácilmente objetivos sobre los mismos. Estos objetivos, se los llama SLO (Service Level Objective), y tienen que tener una ventana de tiempo sobre las que van a ser medidos. Por ejemplo, para la disponibilidad podemos establecer un SLO de 99.9%, medido a través de todos los servidores que exponen el servicio, y en ventanas de tiempo de 24 horas. De forma análoga, podemos definir otro SLO para la latencia, definiendo que queremos que por lo menos el 95% de las requests GET que terminan con 200s, se completen en menos de 500ms, medido a través de todos los servidores que exponen el servicio, en ventanas de tiempo de 24 horas.

Este es un ejemplo de una de las aplicaciones que mantenemos.
Es una app que expone un servicio para ingresar eventos y procesarlos asincrónicamente. En este servicio elegimos 3 SLIs: disponibilidad, latencia y el tiempo transcurrido desde que ingresa el evento, hasta que termina de procesarse.

Aún no definimos SLOs, porque queremos tener un mayor historial sobre cómo usarán el servicio, pero lo que sí hicimos, es elegir algunos valores como sugerencia, y los dejamos en el título y descripción de cada panel.

Un tema muy importante en nuestro sistema de monitoreo son las alertas. Mal usadas, pueden generar más problemas que si no las tuviéramos.

Las alertas tienen que saltar solo cuando se trata de algo urgente, algo que no se puede postergar. Si la alerta está bien configurada, cuando aparece, debería querer salir corriendo. Tienen que estar basadas en síntomas, es decir, tiene que avisarme solo si estamos generando, o estamos en camino a generar, algún impacto negativo sobre el usuario.

Cuando esto no sucede, cuando las alarmas nos avisan de algo que puede esperar al otro día, o de algo que ni siquiera es un problema, entonces empiezan a surgir otros problemas que también son bastante serios:

Acostumbrarnos a la falsa alarma y no ver a tiempo una alarma importante.
Malgastar el tiempo, ya sea por el switch mental, o por interrumpirte en un momento personal.
Desmoralizar, desmotivar, generar mal predisposición a monitorear.

Dejamos algunas preguntas que tomamos principalmente del libro de SRE de Google, que creemos que pueden servir de guía para armar bien las alarmas:

La alarma que estoy creando, va a detectar una condición que me haga reaccionar con urgencia? La situación, tiene algún accionable? Le estará impactando inmediatamente a los usuarios? Por ej, si la situación es que se cortó la red en una región, y no queda otra que esperar, no hace falta que me molesten por eso. En todo caso, cuando vuelva, si mis servicios no se pudieron recuperar solos, ahí si debería haber alguna alarma.
Cuando suceda, voy a poder tomar alguna acción? Es realmente urgente o puede esperar al otro día? Por ejemplo, si en el cluster de un servicio se cayeron algunas instancias, pero el tráfico se puede seguir sirviendo con las instancias que quedaron activas, no hace falta lanzar una alerta. En todo caso notificarlo por otra vía, tal de que al día siguiente lo pueda ver.
La acción podría ser automatizable? Siempre que una acción se pueda automatizar, es preferible eso. Se ahorra tiempo, es menos error prone, y no depende del conocimiento de una persona en particular.
La alerta, va a molestar a otra gente innecesariamente? Ojo con el encadenamiento de alertas, debería haber una dependencia. Hay sistemas de alertas que permiten configurar eso.

¿Que hacemos con las alertas que no son urgentes? Por ej. que se caiga un nodo de un cluster. Se puede usar otro canal de comunicaciones para este tipo de notificaciones. Uno que se revise en horario laboral, y que sea parte de las tareas de mantenimiento, no de la guardia.

Ok, pero hasta acá no hablamos de logs, ni de trazas, ni de nada de todas esas herramientas que tanto se estuvieron hablando estos días. Al contrario, dijimos que el monitoreo no debe contener muchas métricas, solo las necesarias para responder Qué está roto y Por Qué.

Bueno, ahora vamos a ver que para todo el resto, están las herramientas de observability. Y vamos a hacer un breve repaso sobre las más importantes, dado que complementan con todo lo que nuestro sistema de monitoreo no nos alcanza a responder en momentos de troubleshooting y debugging.

El objetivo de Observability es diferente al de monitoring. El objetivo es permitirnos conocer con el mayor nivel de detalle posible, el comportamiento y estado interno de nuestro sistema. Algo que es muy importante para comprender el estado interno, es el contexto de ejecución, ya que nos permite comprender la causalidad de la serie de acciones o eventos que suceden internamente.

Como se puede ver en la imagen, observability incluye las herramientas de monitoring y va más allá. Se dice que abarca todo lo que monitoring no llega a cubrir.

Otro punto importante es que debe estar basado en evidencias, no en conjeturas u opiniones.

Observability es un término que generó bastante debate en estos últimos años, y se lo uso mucho de forma marketinera. Sus orígenes vienen de teoría de control, y en lo que sí podemos ponernos de acuerdo a lo largo de todo el debate que se fue dando, es que tiene que ver con conocer el estado interno y el comportamiento de un sistema.

A continuación, vamos a hacer un breve repaso sobre las herramientas de observability más usadas en un contexto de sistemas distribuidos.

Cuando intentamos resolver un problema, probablemente en algún punto queramos pasar a revisar el log.

Los logs son eventos discretos que generan las aplicaciones a medida que ejecutan su propia lógica. El log que se genera para hacer observability, en general tiene datos y detalles asociados a las decisiones y caminos que que la aplicación fue tomando, tal que luego sirva para hacer diagnóstico o evidenciar lo que la aplicación hizo. Algo importante es que el log siempre nos habla sobre qué hizo la aplicación en el pasado.

Algunos detalles a tener en cuenta cuando agregamos logs, son:

Loguear con contexto. Ya sea un identificador por request, o algo que nos permita correlacionar varios logs asociados a un mismo evento.
Estandarizar el log, tal de tener el mismo tipo de información en cada nivel de logueo.
En lo posible, usar logs estructurado. Tal de que no esté limitado a ser leído por un humano, sino que también pueda procesarse programáticamente. Y por ejemplo, sacar métricas, agrupar, indexar fácilmente por campos específicos, etc.

Respecto a logs estructurados, dejamos una imágen mostrada en una charla en la GRAFANACON de este año, donde a partir de unas líneas de logs, se puede sacar información extra sobre la cantidad de requests, por endpoint y status code, lo cual puede ser muy útil en medio de un incidente en producción. En este caso, lo están haciendo con una query sobre Loki, usando LogQL, parecido a PromQL de Prometheus.

Aquí se ve un ejemplo de cómo listamos los logs de una aplicación, en este caso llamada data-stream-in, usando Loki.

Aquí otro ejemplo, filtrando solo los warnings.

Y aquí otro ejemplo, armando una métrica de cantidad de logs por minuto, agrupado por nivel. En este caso vemos que tenemos logs en INFO y en WARN.

Otra herramienta fundamental, son las métricas. A diferencia del log, las métricas son valores agregados, tales como contadores, histogramas, gauge (valores que pueden crecer o decrecer). Las métricas se usan tanto para conocer el estado actual de un sistema, como la tendencia o evolución que está teniendo. Esto significa que son útiles para predecir hacia donde va el sistema. Por ej, con una métrica del espacio en disco utilizado, podemos ver si estamos agotando el espacio libre y si la tendencia es quedarnos sin disco, o por el contrario, estar ganando espacio en disco.

Además de las métricas del sistema en sí, como latencia, throughput, errores y saturación, es importante tener en cuenta otros aspectos subyacentes al sistema. Aspectos como los hiccups que puede tener la VM, el uso de CPU y cantidad de pausas introducidos por la GC, son algunos de los que también hay que observar para comprender mejor la performance de nuestro sistema.

Aquí un ejemplo de métricas de sistema que tomamos en nuestras VMs.

Tracing es otra herramienta muy útil que permite, no solo analizar y responder preguntas sobre una aplicación en particular, sino también responder preguntas que tienen que ver con la interacción de un conjunto de aplicaciones a lo largo de un flujo que recorre una request.

Una traza es un conjunto de eventos individuales que se desencadenan a través de un evento padre (en general una request). Lo interesante es que se puede visualizar en una sola imagen la causalidad de los eventos que están relacionados con una traza en particular. Algunas preguntas interesantes que permite responder, son:

Cuál es el camino que recorre una request?
Dónde está el cuello de botella, que ralentiza toda la ejecución?
Cuanto tiempo se va en el lag de la red?
Qué ocurre en cada servicio, para una request en particular?

Esta slide está tomada de una charla sobre tracing distribuido que dimos hace unos años, les dejamos el link a la presentación.

Este es un ejemplo de una traza distribuida entre 2 aplicaciones. Se puede visualizar fácilmente el momento que ocupó cada aplicación, y una serie de detalles interesantes en cada span, como headers, tiempos, status code, etc.

En resumen:

Usemos The Four Golden Signal y USE Method para monitorear nuestros servicios.
Instrumentemos nuestros servicios tan pronto como sea posible.
Combinemos profiling, logs y trazas, como herramientas auxiliares para hacer troubleshooting.
Iterar. Esto es un proceso iterativo. Empecemos de a poco, como dijimos, manteniendo la simpleza, y evolucionemos iterativamente nuestro sistema de monitoring.

Después de desarrollar todos estos temas algunas de las preguntas abiertas, y otras no tanto, que se nos ocurren son:

Algunas de las preguntas anteriores nos lleva a una línea de pensamiento donde la controlabilidad es el fin de la observabilidad, y en un sistema que se autocontrola a partir de su dinamismo y donde no está solo en el universo sino que se comunica enviando y recibiendo señales que influencian a otros, y que con el tiempo ayudan a inferir el estado de los demás y el de uno mismo.

Si seguimos la idea de la controlabilidad caemos en la Teoría del Control que hace 2000 años atrás fue usada por los egipcios en un reloj de agua (Clepsidra), o un poco más acá cerca, en la segunda guerra mundial se desarrollaban armas que se apoyaban en esta idea como por ejemplo los cañones antiaéreos.

Se usa de manera intensiva en:

Control de Procesos.
Electrónica.
Industria Aeroespacial.
Automatización de manufactura.

El principio básico es comparar de manera continua la salida actual del sistema con el valor de referencia, y aplicar cambios a la entrada del sistema para contrarrestar cualquier desviación que exista entre la salida y el valor de referencia.

Si pensamos en código, dentro de un while(true) tenemos el estado actual y el deseado, e intentamos en todo momento que se llegue al valor deseado aplicando correcciones con el feedback loop.

while(true) {
    currentState = getCurrentState()
    desiredState = getDesiredState()
    makeConform(currentState, desiredState)
}

Algunos ejemplos conocidos donde se utiliza son:

Control de velocidad de un auto.
Cooler del CPU donde la métrica que trackeamos es la temperatura y lo que ajustamos es el voltaje aplicado al cooler.
Kubernetes y el autoscaling utiliza un PID (Proportional, Integral, Derivative) Loop con algunos checks y algún que otro artilugio.
Control plane de Amazon.

Gracias!!