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
Próximamente contenido premium
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.
