Observabilidad

La observabilidad es la capacidad de entender lo que ocurre dentro de un sistema mirando sus señales externas. Es el hábito de ver las relaciones de causa y efecto antes de que se conviertan en síntomas. Es la parte de la práctica de ingeniería que transforma «algo se rompió» en «sabemos exactamente qué y por qué». Hacemos nuestros propios proyectos, y para nosotros importa notar los problemas antes que los usuarios. Idealmente en el momento en que todavía es una pequeña desviación de métrica, mucho antes de que se convierta en un incidente con llamadas nocturnas.

Qué consideramos buena observabilidad

Una buena observabilidad responde a la pregunta «por qué y dónde exactamente». Ilumina el recorrido del usuario, muestra la degradación, detecta la regresión después de un despliegue, permite hacer rollback con calma. Calla ante nimiedades y habla fuerte cuando de verdad hace falta. Una mala observabilidad son diez alertas que nadie mira, un panel con treinta gráficos en el que no se encuentra nada, logs en texto plano que no se pueden filtrar. Una buena son tres métricas que describen realmente la salud del sistema y registros estructurados donde la búsqueda lleva segundos. Nos gusta el enfoque de los «tres pilares» — métricas, registros, trazas. Las métricas responden a «qué ocurre en promedio», los registros a «qué pasó en un momento concreto», las trazas a «cómo una petición atravesó el sistema». Cada pilar es útil por sí solo. La magia empieza cuando están enlazados: desde una alerta de métrica pasas a los registros, de los registros a una traza, de la traza al código.

Monitoreo frontend privado

Un cariño aparte es el monitoreo frontend privado. Ves los errores reales y el rendimiento en el navegador, y los datos se quedan dentro de tu infraestructura. Sin envío a servicios de terceros, sin dependencia adicional, sin que tus usuarios se conviertan en tráfico para el modelo publicitario de alguien más. Montamos un stack basado en Grafana Faro, OpenTelemetry y un backend propio para recibir eventos. Una solución así cuesta más que enchufar un SaaS en cinco minutos. Un año después tienes una infraestructura que funciona sin dependencias externas, sin límites de eventos, con un coste de propiedad predecible.

Cuando las señales de backend y frontend viven juntas, dejas de hilar los datos a mano y empiezas a ver el sistema entero de una vez.

Las alertas como práctica de ingeniería

Configurar una alerta es fácil. Afinarla para que dispare solo cuando de verdad se requiere una acción es difícil. Seguimos la regla: una alerta que disparó y no pidió ninguna acción es una alerta mala. Quizá el umbral esté mal puesto. Quizá la métrica sea mala elección. Quizá el problema ya se ha resuelto automáticamente, y la persona recibe una notificación en vano. Por eso en nuestra casa cada alerta pasa por un filtro: qué se ha violado exactamente, por qué importa, qué acción se espera, dónde mirar. Con respuestas claras a estas preguntas, la alerta se queda. Esas alertas disparan pocas veces y siempre con motivo.

Cómo se manifiesta esto en nuestros proyectos

Recogemos señales para que ayuden a tomar decisiones: qué experimentos llevar, qué optimizar, dónde está el cuello de botella, cuánto cuesta un error. Donde hace falta, añadimos formas rápidas de marcar eventos y experimentos, para reemplazar la creencia por el conocimiento. En productos con tráfico de usuarios tenemos por defecto un panel con Core Web Vitals, desglose por países y dispositivos, una mirada aparte a la «cola» de la distribución — porque los promedios mienten casi siempre. En servicios backend tenemos trazas a través de toda la cadena, sin las cuales es imposible entender por qué una petición concreta tardó siete segundos. Si quieres pasar de «parece que empeoró» a «aquí está la métrica, aquí está la causa, aquí está el momento de la regresión» — ese es justo nuestro estilo.

Estado

La competencia está activa y crece con nuestros proyectos — porque sin observabilidad cualquier sistema complejo se convierte rápido en un deambular. Estamos listos para tomar proyectos desde cero (poner el stack, configurar alertas, formar al equipo) y tareas para desmontar el zoo existente de paneles: qué mantener, qué quitar, qué reemplazar.

Siguiente

Búsqueda en la Biblia

Herramienta ortodoxa para buscar y estudiar textos bíblicos. Búsqueda rápida, comparación de traducciones, interpretaciones y modo infantil.

→