Observabilidad: Qué es y por qué es MUCHO más que Monitorización
Aprenderás qué es observabilidad (frente a monitorización) y a construirla con métricas y logs bien diseñados: nombres y etiquetas estables, tendencias y p95, logs JSON con correlation ID y mismo vocabulario/tiempo. Montarás una vista útil y un pipeline/almacenamiento adecuados (series temporales + logs por servicio) para pasar del síntoma a la causa rápido y sentar la base donde AIOps realmente aporta.
Este glosario pone en claro el vocabulario que usarás para pasar de “tengo alertas” a “entiendo lo que pasa”: observabilidad con métricas y logs bien diseñados, percentiles como p95, etiquetas que dan contexto, correlación temporal y la disciplina de un pipeline que no molesta a las aplicaciones.
- Observabilidad
- Es la capacidad de deducir qué le pasa por dentro a tu sistema mirando solo lo que ya emite: métricas, logs y trazas. Te la vas a encontrar cuando no baste con un semáforo rojo/verde y necesites responder rápido a preguntas tipo “por qué”, “dónde” y “desde cuándo” sin tocar el sistema ni abrir veinte pantallas.
- Monitorización (basada en umbrales)
- Es el enfoque de “si X supera Y, avisa”. Útil para detectar síntomas, pero corto para investigar causas. En tu día a día será el timbre que suena; la observabilidad es el mapa con el que sigues el hilo sin rehacer medio dashboard.
- Métricas
- Son números a lo largo del tiempo que describen comportamientos: latencia, tasa de errores, tamaño de colas o uso de CPU. Las verás en tus paneles cuando quieras decidir si un pico es ruido o un problema real y cuándo empezó a torcerse la cosa.
- Percentiles (p95)
- En lugar de quedarte con la media, miras la experiencia “peor habitual”. El p95 te dice que el 95% de las peticiones fue más rápido que ese valor. En el día a día te ayuda a detectar que una parte significativa de usuarios lo está pasando mal aunque el promedio te guiñe “todo bien”.
- Tasas y derivadas
- Son formas de mirar cómo cambia algo, no solo cuánto vale. En la práctica las usarás para ver acelerones en errores, crecimientos de latencia o colas que empiezan a dispararse antes de romper.
- Etiquetas (labels/tags)
- Son campos como operación, estado, versión, entorno o región que acompañan a métricas y logs. En tu día a día sirven para filtrar por lo que importa y agrupar señales en la misma historia sin perderte en generalidades.
- Cardinalidad de etiquetas
- Es cuántos valores distintos puede tomar una etiqueta. Si usas valores de alta rotación (por ejemplo, ID único por petición) revientas memoria y complicas las consultas. Te lo cruzarás cuando un panel vaya lento sin motivo aparente: suele ser cardinalidad disparada.
- Logs estructurados (JSON)
- Son eventos en una línea, con campos claros y consistentes, listos para buscar y correlacionar. En tu día a día te evitan leer novelas: filtras por operación, estado y versión y saltas directo a la línea que explica el gráfico.
- Niveles de log (ERROR, WARN, INFO, DEBUG)
- Marcan la importancia de cada evento. Los usarás para separar lo urgente de lo anecdótico y para no pagar almacenamiento de más. DEBUG en producción solo con fecha de caducidad, o tu futuro yo te odiará.
- Identificador de correlación
- Es un ID que viaja con la petición por todo el sistema. Te permite ir del pico de latencia en la métrica a los logs exactos que vivió esa petición. Lo notarás cuando, por fin, sigas el hilo sin búsquedas eternas.
- Correlación temporal
- Es alinear métricas y logs en la misma ventana de tiempo y con el mismo vocabulario. En la práctica convierte “veo un pico” en “ya sé qué lo provocó” sin saltos entre herramientas.
- Pipeline de observabilidad
- Es el camino disciplinado por el que entran, se validan y se almacenan tus señales. Lo verás en agentes y exporters que no bloquean apps, validaciones de campos obligatorios y filtros que quitan paja antes de guardar.
- Exporters de métricas
- Son componentes que exponen métricas en un formato estándar. En el día a día los pondrás junto a tus servicios para sacar latencias, tamaños de cola o estados sin tocar el código principal.
- Agentes de logs
- Recolectan, transforman y envían los logs sin estorbar a la aplicación. Te importan cuando hay picos: deben aguantar tirones, hacer backoff y no comerse la CPU porque alguien puso DEBUG sin fecha de fin.
- Series temporales (TSDB)
- Es el tipo de base de datos pensada para métricas con retención y agregaciones. En tu día a día te permite guardar finas a corto plazo y agregadas a largo, para investigar sin fundir almacenamiento.
- Retención por niveles
- Consiste en guardar señales a distinta resolución y coste según su antigüedad. Lo usarás para tener detalle de la última semana y, a la vez, históricos “baratos” para comparar versiones o temporadas.
- Tasa de errores
- Es cuánto fallas por unidad de tiempo o de peticiones. Junto a latencia por percentiles te da la foto real de la experiencia del usuario y te ayuda a priorizar arreglos con criterio.
- Señales de capacidad y saturación
- Son métricas que te cuentan si te estás acercando a los límites: CPU robada, colas llenas, conexiones agotadas. En el día a día te permiten prevenir en lugar de llegar tarde con el extintor.
- Diseño de panel para decidir
- Es ordenar las vistas para contar una única historia: arriba latencia por percentiles con su objetivo, debajo errores por tipo, a un lado capacidad, y al final los logs filtrados por la misma operación e intervalo. Si necesita manual, no es un panel: es un escape room.
- Privacidad y enmascarado
- Significa que lo sensible no se guarda o se oculta. En el día a día filtras PII en logs y defines políticas para no llevarte sustos legales ni exponer datos que no necesitas para diagnosticar.
- AIOps (sobre buenos datos)
- Es cuando la capa inteligente empieza a sumar de verdad porque las señales están ordenadas. En tu rutina se traduce en menos ruido, hipótesis con evidencias y propuestas de acción que no salen de la nada.
Este post no tiene contenido práctico
De esto trata el Vídeo
Observabilidad no es un eslogan ni un dashboard bonito: es capacidad operativa para entender qué le pasa al sistema leyendo las señales que ya emite, sin inventarse teorías. Es la diferencia entre mirar y explicar con evidencia por qué algo se degrada y qué decisión tomar ahora.
Frente a la monitorización, el cambio es claro: monitorización valida si se cumple un umbral que definí antes; observabilidad me permite investigar lo inesperado y hacer preguntas nuevas justo cuando algo se comporta raro.
En términos operativos, observabilidad es la capacidad de inferir el estado interno a partir de salidas del sistema. No va de acumular datos, sino de diseñar señales útiles, estructurarlas con cabeza y conectarlas para que los patrones salten a la vista.
Con métricas, busco nombres coherentes y etiquetas estables (operación, estado, versión, entorno, región), evito etiquetas de alta rotación que inflan cardinalidad, miro tendencias, tasas y derivadas en lugar del fotograma del instante y alerto con contexto: “CPU alta” sin historia alrededor no siempre importa.
El p95 me da una visión honesta de experiencia: si ordeno 100 latencias, el valor en la posición 95 indica que el 95% fue más rápido y el 5% más lento. Cuando sube el p95 en una región y operación concreta, ya tengo una historia accionable sin depender de medias que maquillan picos.
Los logs explican sin gritar cuando son estructurados (JSON), una línea por evento y con campos claros, comparten el mismo vocabulario que las métricas y viajan con un identificador de correlación. Los niveles se usan con criterio —ERROR impacto real, WARN sospecha, INFO hitos— y DEBUG en producción caduca por diseño. En privacidad, enmascaro o no guardo lo sensible: observabilidad es guardar lo necesario para entender y actuar.
Para investigar, trabajo con una vista única: latencia por percentiles con objetivos, tasa de errores por tipo, señales de capacidad para anticipar saturación y logs ya filtrados por operación/tiempo/región unidos por el correlation ID. Con misma línea temporal y mismo vocabulario entre señales paso del qué al por qué en minutos.
El pipeline sostiene todo: agentes/exporters no bloqueantes que aguanten picos, validación de campos obligatorios en tránsito y filtros para lo irrelevante. Separo almacenes: métricas en series temporales con retención inteligente y logs por fecha/servicio con niveles de coste según antigüedad y criticidad.
¿Resultado? Velocidad de diagnóstico, prevención de desviaciones antes de que molesten, confianza en los cambios midiendo impacto real por versión y AIOps con fundamento porque los datos están ordenados y alineados.
Idea para llevarte: primero orden, luego inteligencia. Con métricas honestas, logs claros y lenguaje común hoy, mañana cualquier automatización sumará sobre terreno firme. De eso va la observabilidad: entender mejor para decidir mejor.
