Jorge Saavedrapythonobservabilidadmonitoreoplotlyprincipiantes
Todos hemos dicho alguna vez "en mi maquina si funciona." Es una frase tan comun en el desarrollo de software que ya se convirtio en meme. Pero la pregunta real no es si funciona en tu maquina, sino si funciona en produccion. Y mas importante aun: como lo sabes.
Sin monitoreo, la respuesta honesta es que no lo sabes. Estas confiando en que nada va a fallar, o peor, en que alguien te va a avisar cuando algo falle. Monitorear no es un lujo ni algo que se agrega "despues." Es la diferencia entre reaccionar a incendios y prevenirlos.
Este post es un primer paso practico hacia la observabilidad. No vamos a configurar infraestructura compleja ni a desplegar agentes en Kubernetes. Vamos a construir algo simple, concreto y util: un analizador de logs con Python.
observabilidad
Capacidad de entender el estado interno de un sistema a partir de sus salidas: metricas, trazas y logs.
Por que monitorear
Puede que tu aplicacion este funcionando "bien" ahora mismo. Pero "bien" sin datos que lo respalden es solo una suposicion. Hay tres escenarios clasicos donde el monitoreo te salva:
- Errores silenciosos que se acumulan. Un endpoint devuelve 500 una vez cada cien requests. Nadie lo nota, pero los usuarios si lo sienten. Sin metricas, ese error pasa desapercibido hasta que se convierte en una avalancha.
- Degradacion de rendimiento que nadie percibe. Tu API empieza a responder en 800ms en lugar de 200ms. No hay un error explicito, pero la experiencia del usuario se deteriora poco a poco. Sin trazas ni metricas de latencia, no tienes forma de detectarlo.
- Un deploy que rompe cosas de manera sutil. Subiste una nueva version y todo parece funcionar. Pero un cambio en la logica de negocio esta generando datos incorrectos en la base de datos. Sin logs estructurados, te enteras cuando un cliente se queja, dias despues.
Los tres pilares de la observabilidad
La observabilidad se sostiene sobre tres pilares fundamentales. No son herramientas ni productos, son tipos de datos que tu sistema debe producir para que puedas entender que esta pasando adentro.
- Logs: registros de eventos discretos. Te dicen que paso. Por ejemplo: "El usuario X intento iniciar sesion y fallo por credenciales invalidas." Son la forma mas basica y directa de observabilidad.
- Metricas: valores numericos medidos a lo largo del tiempo. Te dicen cuanto y que tan rapido. Por ejemplo: "La tasa de errores 5xx subio un 15% en la ultima hora."Metricas
Valores numericos que representan el estado de un sistema a lo largo del tiempo. Ejemplos: tasa de errores, latencia promedio, uso de CPU.
- Trazas: el recorrido completo de una solicitud a traves de tus servicios. Te dicen por donde paso. Si una peticion tarda 3 segundos, la traza te muestra que 2.8 de esos segundos se fueron en una consulta a la base de datos.Trazas
Registro del recorrido completo de una solicitud a traves de multiples servicios. Permiten identificar cuellos de botella y dependencias problematicas.
No necesitas todo desde el dia uno
No tienes que implementar los tres pilares al mismo tiempo. Empieza con logs estructurados. Es lo mas facil de agregar y lo que mas valor inmediato te da. De ahi puedes evolucionar hacia metricas y trazas cuando tu sistema lo requiera.
Un ejercicio practico: analizando logs con Python
Vamos a construir un analizador de logs simple pero funcional. La idea es que entiendas el flujo completo: desde tener datos estructurados hasta visualizarlos de forma util. Todo con Python, pandas y Plotly.
Paso 1: Logs estructurados
Antes de analizar cualquier cosa, necesitas que tus logs tengan estructura. Un log como
ERROR: algo fallo no te dice mucho. No sabes cuando paso, que componente lo genero ni que tan grave es. En cambio, un log estructurado te da toda esa informacion en un formato que puedes procesar automaticamente.Vamos a simular un conjunto de logs estructurados usando un DataFrame de pandas:
python
import pandas as pd
# Logs estructurados como DataFrame
data = {
"timestamp": [
"2025-06-01 10:00",
"2025-06-01 10:01",
"2025-06-01 10:02",
"2025-06-01 10:03"
],
"severity": ["ERROR", "WARNING", "ERROR", "ERROR"],
"category": ["Conexion", "Configuracion", "Conexion", "Archivo"],
"message": [
"Timeout al conectar con DB",
"Config deprecated",
"Connection refused",
"Disco lleno"
]
}
df = pd.DataFrame(data)
print(df)Cada registro tiene un timestamp, un nivel de severidad, una categoria y un mensaje descriptivo. Esta estructura es la base para cualquier analisis posterior. Si tus logs no tienen este nivel de detalle, el primer paso es agregarles estructura.
Paso 2: Clasificar y contar
Con los datos estructurados, puedes empezar a hacer preguntas concretas. Cuantos errores hay por categoria? Cuantos warnings vs errores? Pandas hace que estas preguntas sean triviales de responder:
python
# Conteo por severidad
print("Conteo por severidad:")
print(df["severity"].value_counts())
print()
# Conteo por categoria
print("Conteo por categoria:")
print(df["category"].value_counts())
print()
# Errores agrupados por categoria
errores = df[df["severity"] == "ERROR"]
print("Errores por categoria:")
print(errores["category"].value_counts())Con unas pocas lineas ya tienes una radiografia de tus logs. Sabes que la categoria "Conexion" concentra la mayoria de los errores y que los errores superan ampliamente a los warnings. Esa informacion, que antes estaba escondida en texto plano, ahora es visible y accionable.
Paso 3: Visualizar
Los numeros son utiles, pero una visualizacion te permite detectar patrones de un vistazo. Vamos a usar Plotly para generar graficas interactivas a partir de los datos que ya tenemos:
python
import plotly.express as px
# Distribucion de errores por categoria
fig = px.histogram(
df[df["severity"] == "ERROR"],
x="category",
title="Distribucion de errores por categoria",
color_discrete_sequence=["#ef4444"]
)
fig.show()La grafica de distribucion te muestra de inmediato donde se concentran los problemas. En este caso, la categoria "Conexion" domina el panorama de errores:
El histograma de frecuencias te da otra perspectiva, mostrando la distribucion de los mensajes de error individuales. Esto es util para identificar errores recurrentes que podrian tener una causa raiz comun:
Finalmente, la comparacion por severidad te permite ver la proporcion entre errores y warnings. Si los errores superan por mucho a los warnings, probablemente tus warnings no estan bien calibrados o tienes problemas serios que atender primero:
De aqui a OpenTelemetry
Este script es un punto de partida, no un destino. Analizar logs de forma manual esta bien para entender los conceptos, pero en un sistema real necesitas que la instrumentacion sea automatica y continua. Ahi es donde entra OpenTelemetry.
OpenTelemetry es un estandar abierto que te permite generar, recolectar y exportar metricas, trazas y logs desde tus aplicaciones de forma consistente. En lugar de escribir scripts que lean archivos de texto, instrumentas tu codigo una sola vez y los datos fluyen automaticamente hacia herramientas como Jaeger, Prometheus o Datadog.
Si quieres ver como se ve eso en la practica, en OpenTelemetry y Jaeger: Trazabilidad Distribuida con Spring Web y WebFlux configuro OpenTelemetry con Jaeger para visualizar trazas distribuidas. Es el siguiente paso natural despues de lo que vimos aqui.
Repositorio en GitHub
El codigo completo de este analizador de logs esta disponible en github.com/jesaavedrav/log_analyzer. Incluye mas ejemplos, visualizaciones adicionales y datos de prueba para que puedas experimentar por tu cuenta.
Proximos pasos
Una vez que tienes la base, hay varias direcciones en las que puedes evolucionar:
- Agrega monitoreo de logs en tiempo real usando
watchdogotail -fpara detectar problemas en el momento en que ocurren. - Clasifica patrones de error mas complejos con expresiones regulares. Puedes detectar automaticamente excepciones conocidas y agruparlas.
- Empieza a enviar metricas desde tus microservicios con
opentelemetry-sdk. Es sorprendentemente facil de configurar. - Configura dashboards con Prometheus y Grafana para tener visibilidad continua del estado de tus sistemas.
Para terminar
No puedes arreglar lo que no puedes ver. Esa es la realidad mas simple y mas importante del monitoreo. No se trata de tener la herramienta mas sofisticada ni el dashboard mas bonito. Se trata de dejar de trabajar a ciegas.
Empieza con algo pequeno. Un script que lee tus logs y te muestra donde se concentran los errores. Eso ya es mas de lo que muchos equipos tienen. Desde ahi, iteras, mejoras y escalas. Pero el primer paso es decidir que quieres ver lo que esta pasando.
Recuerda: el monitoreo no es un lujo. Es una responsabilidad.
