DEV Community: Jeison Arenales

Construye tu primer sistema de Observabilidad con Prometheus y Grafana

Jeison Arenales — Tue, 01 Sep 2026 15:04:02 +0000

En los posts anteriores estuvimos hablando de qué es la observabilidad y cuáles son sus señales (o pilares) fundamentales. Ahora que conocemos estos conceptos, no existe una mejor manera de entenderlos y aplicarlos que construyendo nuestro propio sistema de observabilidad en un ambiente controlado.

Para ello vamos a utilizar una plataforma que me gusta mucho y que todos podemos usar de manera gratuita: se llama Killercoda, y básicamente nos permite usar un servidor en la nube para hacer nuestras pruebas sin tener que preocuparnos por romper algo o por tener costos asociados.

En este post vamos a completar un laboratorio en Killercoda que nos permite construir una solución básica de observabilidad enfocada en métricas, utilizando Prometheus como nuestro backend de métricas y Grafana para la visualización. Primero vamos a responder algunas dudas que puedas tener.

1. ¿Qué servidor vamos a monitorear?

Vamos a utilizar un servidor en la nube gratuito con Ubuntu Linux que vamos a provisionar con Killercoda. Killercoda nos otorga 1 hora de uso de ese servidor sin ningún costo.

2. ¿Cómo vamos a recolectar las métricas?

Como vimos en el episodio anterior, las métricas nos indican un valor (unidad de medida) en un tiempo de ejecución. Esto está muy bien, pero ¿cómo obtenemos esas métricas desde nuestro servidor? Existen múltiples maneras de obtener métricas de servidores y/o aplicaciones, como la instrumentación o el uso de agentes. Por ahora no vamos a entrar en mucho detalle, ya que para nuestro caso en particular solo necesitamos obtener las métricas generales de nuestro servidor.

Para ello vamos a instalar un programa (Prometheus Node Exporter) en nuestro servidor en la nube que obtiene información del sistema y la expone mediante una URL (endpoint) específica: http://localhost:9100/metrics.

Algo importante a mencionar es que Prometheus Node Exporter expone las métricas del estado actual de nuestro servidor. No es responsable de almacenarlas ni de mantener un histórico de sus valores; para ello necesitaremos otro componente.

3. ¿Cómo mantener el histórico de las métricas?

Nuestro servidor ya expone las métricas mediante un endpoint específico, pero ahora necesitamos recolectar esa información a lo largo del tiempo y almacenarla para poder consultar el historial de su comportamiento.

Time Series: Una serie temporal es una secuencia de valores de una métrica registrados a lo largo del tiempo. Por ejemplo, podemos registrar el uso de CPU de nuestro servidor cada cierto intervalo: 35% → 42% → 51% → 47%.

Nuestra solución será Prometheus, que es un sistema open-source de monitorización y recopilación de métricas que incluye su propia base de datos de series temporales o TSDB (Time Series Database). Prometheus es muy útil para muchos escenarios, pero para nuestro caso en particular nos enfocaremos en 2 funciones principales:

Recolectar (en inglés: scrape) la información de las métricas de nuestro servidor conectándose a través del endpoint http://localhost:9100/metrics cada 15 segundos.
Almacenar esa información en una base de datos de series temporales o TSDB.

4. ¿Dónde visualizar las métricas de una manera amigable?

Nuestro sistema de monitoreo ya va tomando forma: nuestro servidor expone las métricas usando Node Exporter, Prometheus las recolecta cada 15 segundos y las almacena en una TSDB. En el artículo anterior utilizamos el tablero de un vehículo como analogía para entender las métricas. Ahora necesitamos una aplicación que nos permita construir nuestro propio tablero y visualizar esas métricas de forma amigable.

Aquí vamos a introducir a Grafana, que es una plataforma open-source para la visualización y el análisis de datos. Permite conectarse a diferentes fuentes de datos y convertir la información recopilada en dashboards, gráficos y paneles interactivos.

Arquitectura

Con estos componentes ya identificados, veamos cómo encajan entre sí a nivel de arquitectura:

Ubuntu Linux: servidor donde se ejecutará nuestro entorno de monitorización.
Node Exporter: componente que expone las métricas del sistema operativo, como CPU, memoria, disco y red. Se ejecuta directamente sobre el servidor Ubuntu.
Docker: utilizado para ejecutar Prometheus y Grafana en contenedores, sin necesidad de instalarlos manualmente en el servidor.
Prometheus: sistema de monitorización encargado de recolectar esas métricas cada 15 segundos y almacenarlas en su base de datos de series temporales.
Grafana: herramienta utilizada para consultar y visualizar las métricas mediante dashboards.
Web Browser: utilizado para acceder a la interfaz de Grafana.

Manos a la obra

Ya tenemos claro cómo funcionaría nuestro sistema de monitoreo y por qué necesitamos cada una de sus piezas. Ahora toca construirlo con tus propias manos.

Preparé un escenario guiado en Killercoda donde vas a instalar y configurar cada componente paso a paso, en el mismo orden en que los presentamos en este post:

Instalar Node Exporter directamente en el servidor Ubuntu y verificar que expone las métricas del sistema.
Instalar y configurar Prometheus con Docker Compose, y comprobar que está recolectando (scrapeando) las métricas de Node Exporter.
Instalar Grafana con Docker Compose y conectarlo a Prometheus como data source, verificando la conexión desde Explore.
Importar un dashboard de la comunidad (Node Exporter Full) para visualizar todas las métricas de tu servidor sin tener que construir los paneles desde cero.

Cada paso incluye las verificaciones necesarias para confirmar que todo está funcionando antes de avanzar al siguiente, así que no te preocupes si nunca has usado Docker o Prometheus — el escenario te lleva de la mano.

👉 Escenario en Killercoda: Construye tu primer sistema de Observabilidad con Prometheus y Grafana

Recuerda que Killercoda te da 1 hora de uso gratuito del servidor — es tiempo de sobra para completar los 4 pasos con calma.

En el próximo capítulo saldremos de las métricas y nos adentraremos en otra de las señales fundamentales de la observabilidad: los logs. Construiremos un nuevo laboratorio utilizando Grafana Loki para recopilar y consultar los registros de nuestro servidor.

Cuéntame cómo te fue con el escenario, si te trabó algo o si tienes dudas sobre alguno de los componentes — déjamelo en los comentarios 👇

Sígueme aquí en dev.to para no perderte los próximos artículos de la serie; voy publicando uno a la vez, sin relleno.

Happy Learning 🚀

Métricas, Logs y Trazas: los 3 pilares de la Observabilidad explicados sin jerga

Jeison Arenales — Mon, 24 Aug 2026 14:42:30 +0000

Este post es la continuación de nuestra serie dedicada a entender qué es la Observabilidad en ingeniería de sistemas. Por si no lo recuerdas, en el episodio anterior cubrimos el concepto de Observabilidad y lo explicamos de manera sencilla usando una analogía de un restaurante.

El día de hoy aprenderemos cuáles son los 3 pilares o señales de la observabilidad y cómo estas nos permiten comprender el estado o la condición interna de un sistema complejo.

¿Qué es una Señal en Ingeniería de Sistemas? Las señales son salidas del sistema que describen la actividad subyacente del sistema operativo y de las aplicaciones que se ejecutan en una plataforma. Opentelemetry

La primera señal que vamos a aprender son las Métricas (Metrics). Estas pueden resultar bastante familiares, ya que nos indican un valor (unidad de medida) en un tiempo de ejecución. Por ejemplo, en el tablero de un vehículo podemos ver varias métricas que nos dan información referente al estado del vehículo, como lo son:

Velocidad actual medida en Km/h
Cantidad de combustible disponible, medida en porcentaje (0% - 100%)
Temperatura actual del motor, medida generalmente entre Frío y Caliente
Revoluciones por minuto o RPM
Promedio de kilómetros que se pueden recorrer con nuestro depósito de combustible actual
Total de kilómetros recorridos por nuestro vehículo

Todas estas son métricas que nuestro vehículo reporta, y el tablero del vehículo puede mostrarlas para tener un entendimiento del estado actual. Esto es exactamente lo mismo en la ingeniería de sistemas: las métricas nos ayudan a entender:

Cantidad de requests por segundo en un servidor web
Porcentaje de uso de CPU en nuestro servidor
Porcentaje de memoria usada en nuestro servidor
Cantidad de errores registrados en nuestro servidor web
Uptime: cantidad de tiempo durante el cual nuestro servidor ha estado corriendo sin interrupciones

Con esto entendemos de manera general qué son las métricas y cómo funcionan en nuestros sistemas informáticos.

La segunda señal que vamos a entender son los registros (Logs). Para entender esta señal, imaginemos por un momento que nuestros servidores son amantes de escribir en diarios, diarios en los cuales registran todo tipo de eventos y el momento exacto (timestamp) en que ocurrieron, por ejemplo:

- 2025-05-16 10:42 Inicio sesión Samuel
- 2025-05-16 11:00 Samuel creó su primer archivo
- 2025-05-16 14:00 Samuel ejecutó el servicio web de nginx
- 2025-05-16 14:02 Nginx atendió una petición en nuestro servicio web

Esos diarios son guardados en archivos con rutas específicas en nuestros servidores para poder entender el comportamiento de nuestras aplicaciones y/o servidores.

En resumen: un registro es una línea de texto con fecha y hora que nuestras aplicaciones y/o servidores escriben para informar de los eventos sucedidos.

Por último, pero no menos importante, vamos a hablar de las trazas (Traces), que se componen de 2 elementos: la traza y los tramos (Spans).

Las trazas nos ofrecen una visión general de lo que ocurre cuando se envía una solicitud a una aplicación. Opentelemtry

Un tramo representa una unidad de trabajo u operación. Opentelemtry

Para entender mejor esta señal usaremos una analogía de algo que nos gusta hacer a todos: comprar en línea. Cuando hacemos una compra en línea, por lo general seguimos una serie de pasos:

1. Navegamos en nuestra página de compras online favorita
2. Iniciamos sesión con nuestra cuenta
3. Buscamos el producto que queremos
4. Comparamos con diferentes proveedores
5. Agregamos el producto a nuestro carrito de compras
6. Completamos todos los datos para el envío
7. Realizamos el pago

En esta analogía, nuestro objetivo, "Comprar un producto online", es nuestra traza, y cada uno de los pasos ejecutados son nuestros tramos. Entonces podemos entender que una traza es el período de tiempo que nos toma ejecutar una tarea específica, y los tramos son todos los pasos que debemos completar dentro de esa tarea.

Ahora bien, hay algo importante que vale la pena aclarar: un tramo puede a su vez dividirse en tramos más pequeños. Es decir, un paso que a simple vista parece una sola acción, en realidad puede esconder varias operaciones internas, cada una con su propio tiempo de ejecución.

Tomemos el paso 2 de nuestro ejemplo, "iniciar sesión". Aunque para nosotros como usuarios es un solo clic, por dentro el sistema en realidad ejecuta varias operaciones más pequeñas para completar ese paso:

Aquí, "Iniciar Sesión" sigue siendo un tramo dentro de nuestra traza general de "Comprar un producto online", pero al mismo tiempo funciona como el contenedor de otros tramos más pequeños (validar usuario, comprobar contraseña, cargar datos, mostrar perfil). A esto se le llama anidación de tramos, y es lo que nos permite bajar de nivel: no solo saber que "iniciar sesión" tomó 10 ms, sino exactamente en qué parte de ese proceso se fueron esos 10 ms.

Esta información nos permite entender realmente el funcionamiento de nuestras aplicaciones y nos ayuda a incorporar mejoras y ajustes en donde fuese necesario.

En ingeniería de sistemas, las trazas y los tramos nos permiten entender cuánto tiempo toma nuestra aplicación en cada uno de los sub-procesos y así descubrir cuellos de botella o fallos específicos.

Ahora que hemos entendido de manera general cómo funcionan los 3 pilares de la observabilidad, podemos responder muchas preguntas sobre el estado real de nuestras aplicaciones. Por ejemplo, digamos que recibimos una alerta diciendo que nuestro sitio web está cargando muy lento para los usuarios. Con nuestro sistema de observabilidad pudiéramos:

Ver cuál es el porcentaje de carga en CPU y memoria de nuestro servidor
Qué información está reportando nuestro servicio web
Cuánto tiempo está tomando la aplicación en responder una petición

Esto nos da una imagen mucho más profunda y detallada de toda la aplicación, y nos permite entender rápidamente dónde está el fallo.

En el próximo capítulo vamos a monitorear las métricas de un servidor real usando Grafana y Prometheus.

Coméntame si conocías todas estas señales y si puedes describir otras analogías para explicarlas. Cuéntamela en los comentarios 👇

Sígueme aquí en dev.to para no perderte los próximos artículos de la serie; voy publicando uno a la vez, sin relleno.

Happy Learning 🚀

¿Qué es la Observabilidad? Explicada con un restaurante

Jeison Arenales — Mon, 17 Aug 2026 19:49:09 +0000

Desde hace un tiempo he querido empezar a compartir el conocimiento que he adquirido a lo largo de mi carrera profesional. He decidido empezar este viaje explicando un tema que considero muy importante hoy en día: la Observabilidad de nuestros sistemas informáticos. Es un largo camino por recorrer, pero me gustaría empezar desde lo más básico e ir incorporando conceptos a medida que avanzamos y consolidamos bases sólidas.

Observabilidad: Es la capacidad de comprender el estado o la condición interna de un sistema complejo basándose únicamente en el conocimiento de sus salidas externas, específicamente su telemetría. IBM

Primero que nada, expliquemos qué es la telemetría. Básicamente, la telemetría no es más que toda esa información que un sistema va dejando sobre lo que hace: métricas, logs, trazas.

Leyendo el concepto de Observabilidad, probablemente todavía queden algunas dudas de cómo funciona; entonces, veámoslo desde otro punto de vista más entendible para nosotros. Imaginemos por un momento un restaurante famoso en nuestra ciudad en el cual vamos a disfrutar de nuestro plato favorito. Desde nuestro punto de vista, nosotros quisiéramos saber si:

El restaurante está abierto el día de hoy
Cuánto tardan aproximadamente en preparar nuestro plato favorito
Si el plato que ordené llegó correctamente
Si puedo usar mi método de pago en el restaurante

Entre otras cosas. Todo eso que el cliente quiere saber es fácil de ver desde afuera — pero el dueño necesita algo más: cuando haya un problema, quiere saber exactamente por qué se originó y cómo podría solucionarlo.

Por ejemplo: un día un cliente se queja:

"Llevo 40 minutos esperando mi comida."

El dueño mira el salón y ve que hay pocos clientes. Entonces se pregunta:

¿El cocinero está tardando demasiado? ¿Se acabó algún ingrediente? ¿Hay demasiados pedidos en la cocina? ¿El camarero olvidó el pedido? ¿La caja está teniendo problemas? ¿El proveedor no entregó los ingredientes?

El restaurante funciona, pero el dueño no puede explicar qué está ocurriendo dentro. Esto es exactamente el problema que la observabilidad intenta resolver en un sistema de software.

Digamos que el dueño decide empezar a instalar un sistema que le permita monitorear el estado de su restaurante, entonces instala algunos indicadores como:

Clientes: 120
Pedidos: 80
Tiempo promedio: 25 min

Esto es monitorización. Ya sabe que algo está pasando: "el tiempo promedio de preparación aumentó de 10 a 25 minutos." Mucho mejor. Pero todavía tiene una pregunta: ¿por qué?

Entonces el dueño decide implementar un sistema de observabilidad que le permita comprender el estado de su restaurante. Ahora el restaurante registra mucho más contexto. Su flujo de trabajo se registra de la siguiente manera:

Por lo tanto, el dueño puede saber la siguiente información:

Pedido recibido:       12:01:02
Cocina inició:         12:01:05
Hamburguesa lista:     12:08:31
Papas listas:          12:18:42
Pedido entregado:      12:19:01

Ahora el dueño puede descubrir: "Las hamburguesas están saliendo normalmente, pero las papas están tardando 10 minutos adicionales porque la freidora está saturada."

Eso es mucho más cercano a la observabilidad y a cómo puede ayudarnos a comprender el estado actual de nuestro sistema.

En resumen: la monitorización te dice qué está pasando; la observabilidad te ayuda a entender por qué está pasando. Ese salto —de ver números a entender causas— es el corazón de todo lo que viene en esta serie.

En la próxima publicación vamos a entrar de lleno en los 3 pilares de la observabilidad: métricas, logs y trazas. Si te ha servido esta forma de explicarlo o tienes tu propia analogía favorita para observabilidad, cuéntamela en los comentarios. 👇

Sígueme aquí en dev.to para no perderte los próximos artículos de la serie; voy publicando uno a la vez, sin relleno.

Happy Learning 🚀