En 06-04 montaste el primer pilar de la observabilidad. AlpinaShop tiene ahora un panel, comprobaciones de disponibilidad desde cuatro continentes y tres alertas que llegan al móvil de Marta. Es un salto enorme respecto a esperar el correo de un cliente.

Pero fíjate en lo que ocurre cuando esa alerta salta de verdad. Son las once de la noche y el móvil de Marta muestra: "Tasa de error 5xx por encima del 2 % durante 5 minutos". Marta abre el panel. Confirma: el 4,3 % de las peticiones fallan, la latencia p95 ha subido de 400 ms a 3,2 segundos, y empezó hace unos veinte minutos. Y ahora, ¿qué?

La métrica le ha dicho que algo va mal. No le dice qué. No le dice qué excepción se está lanzando, ni a qué clientes les pasa, ni si es en el catálogo o en el carrito, ni si el culpable es la aplicación, la base de datos o una llamada a una API externa. Para eso hacen falta los otros dos pilares.

Esta lección los construye. Y termina con el recorrido completo de ese incidente, desde la alerta hasta la línea de código exacta, porque esa correlación —saltar de la alerta a la métrica, de la métrica al log y del log a la traza— es la razón por la que existe la observabilidad.

1. La entrada de log estructurada
2. De dónde salen los logs automáticamente
3. Emitir logs bien desde la aplicación Flask
4. El explorador de logs y su lenguaje de consultas
5. Consultas que resuelven incidentes reales de AlpinaShop
6. Buckets, retención, vistas y ámbitos
7. Sumideros: exportar a BigQuery, Cloud Storage y Pub/Sub
8. Filtros de exclusión: no pagar por ruido
9. Métricas basadas en logs
10. Cloud Trace: qué es el rastreo distribuido
11. Instrumentar Flask con OpenTelemetry
12. Leer una cascada y encontrar la consulta lenta
13. Muestreo y coste de las trazas
14. Cloud Profiler: perfilado continuo
15. La correlación que lo une todo: un incidente de principio a fin
16. Coste por volumen y las tres decisiones que lo controlan

Un log no es una línea de texto. En Cloud Logging, una entrada de log es un objeto con campos, y entender esos campos es lo que convierte los logs de un vertedero en una base de datos consultable.

La diferencia entre textPayload y jsonPayload es la diferencia entre poder investigar y no poder.

Sin estructura:

Es legible para un humano y opaco para una máquina. Para responder a "¿cuántos pedidos fallaron por timeout de la pasarela en la última hora, y de qué importe?" hay que analizar texto con expresiones regulares, y basta que alguien cambie el mensaje para que todo se rompa.

Con estructura:

Ahora esa pregunta es un filtro. Y la penúltima línea permite algo más potente todavía: saltar directamente a la traza completa de esa petición, con todo lo que ocurrió antes y después. Volveremos a ello.

Igual que con las métricas, hay una buena noticia: buena parte de los logs ya se están recogiendo sin que hayas hecho nada.

Dos casillas merecen atención.

Los logs del balanceador no están activados por defecto, y son de los más valiosos que existe: contienen cada petición a la tienda con su latencia, su código, su país de origen y el resultado de la caché de CDN. Activarlos:

El --logging-sample-rate=1.0 registra el 100 % de las peticiones. Es lo correcto mientras el volumen sea moderado; con millones de peticiones diarias se baja a 0,1 o 0,05 y se acepta perder detalle a cambio de coste. Empieza por 1.0 y ajusta cuando veas la factura.

Los VPC Flow Logs registran las conexiones de red y son imprescindibles para diagnosticar problemas de conectividad y para investigar incidentes de seguridad. Su volumen es alto, así que se activan con muestreo:

Y los logs de auditoría merecen una mención con remisión: los de actividad de administración —quién creó, modificó o borró un recurso— están siempre activos y son gratuitos. Los de acceso a datos —quién leyó qué— hay que activarlos, generan un volumen enorme y se pagan. La política de auditoría a nivel de organización, con sus implicaciones de cumplimiento, es tema de 07-07; aquí basta saber que existen y que responden a la pregunta "¿quién borró ese recurso?".

Aquí es donde el equipo de AlpinaShop tiene más margen de mejora. El catálogo hoy hace esto:

Funciona en el sentido de que el texto acaba en Cloud Logging —en GKE, todo lo que va a stdout se recoge—. Pero produce entradas con textPayload, todas con severidad INFO aunque sean errores, sin ningún campo consultable y sin identificador de traza.

La forma correcta, con la biblioteca cliente:

Y su uso, con los campos como datos y no como texto:

Las cinco reglas de un log útil, que valen más que cualquier biblioteca:

La tercera regla no es negociable y va más allá del buen gusto. Los logs se retienen, se exportan a BigQuery, se leen por varias personas y sobreviven meses. Un correo electrónico o un número de tarjeta escrito en un log es una fuga de datos personales con implicaciones de RGPD, coherente con todo lo visto en 04-07 sobre DLP. Si necesitas identificar a un cliente en los logs, usa un hash estable que permita correlacionar sin identificar.

Sobre la severidad, un criterio práctico que evita discusiones eternas:

La distinción entre WARNING y ERROR es la que se hace mal más a menudo: un reintento que después funciona es WARNING —el usuario no se enteró—; un reintento agotado que devuelve un error al cliente es ERROR.

El explorador de logs es la interfaz de consulta, y su lenguaje es sencillo pero tiene detalles que conviene conocer.

Los operadores básicos:

Tres consejos de rendimiento que cambian mucho la experiencia, porque una consulta mal escrita sobre semanas de logs tarda minutos:

1. Acota siempre el tiempo primero. Es el filtro más eficiente con diferencia.
2. Filtra por resource.type pronto. Reduce el espacio de búsqueda de golpe.
3. Evita la búsqueda global de texto libre si puedes filtrar por un campo concreto: buscar en jsonPayload.causa es órdenes de magnitud más rápido que buscar la palabra en todo el contenido.

Desde la línea de comandos, para guiones y para automatizar:

La teoría es corta; lo útil son los patrones. Estas cinco consultas cubren la mayoría de las investigaciones reales.

Consulta 1 — Los errores 500 desde el último despliegue. La primera pregunta ante cualquier incidente:

Y refinada, para ver si el problema es de una versión concreta —lo que enlaza con el $COMMIT_SHA de 06-01—:

Consulta 2 — Aislar la petición de un cliente que se ha quejado. Un cliente escribe diciendo que su compra falló a las 20:34:

Aquí se ve el valor de la regla de los datos personales: el hash permite encontrar al cliente sin haber escrito nunca su correo en un log. Atención al cliente convierte el correo en hash con la misma función, y la investigación funciona igual.

Consulta 3 — Quién borró un recurso. Los logs de auditoría, que responden a la pregunta más incómoda:

La respuesta incluye protoPayload.authenticationInfo.principalEmail —quién— y protoPayload.resourceName —qué—. Es la consulta que resuelve en treinta segundos discusiones que de otro modo duran una tarde.

Consulta 4 — Peticiones lentas del balanceador con su origen. Sobre el log de acceso del apartado 2:

Y el mismo log responde una pregunta de coste de 03-03, el ratio de aciertos de la CDN:

Consulta 5 — Errores de la función de imágenes. Cerrando el círculo con 06-03:

Y la que habría detectado el bucle infinito del ejercicio de aquella lección, contando invocaciones por hora:

Los logs se almacenan en buckets de logs, que no tienen nada que ver con los de Cloud Storage.

Todo proyecto tiene dos por defecto:

Y se pueden crear buckets propios, que es lo que hace falta cuando distintos tipos de log necesitan distinto tratamiento:

Elegir la retención tiene dos dimensiones que conviene separar:

Guardar años de logs en un bucket de logs es la forma más cara de conservarlos. Para retención larga, el patrón correcto es exportar a Cloud Storage con clase de almacenamiento fría, que es el tema del apartado siguiente.

Las vistas de log (log views) permiten dar acceso a un subconjunto de un bucket. Es la pieza que resuelve un problema real de permisos: dar a Lucía acceso a los logs de la aplicación sin exponerle los logs de auditoría ni los de pagos.

Sin vistas, el permiso de lectura de logs es todo o nada, y "todo" incluye los logs de auditoría. Con vistas, el acceso se acota, coherente con el mínimo privilegio de 03-04.

Un sumidero (sink) es una regla que dice: "las entradas que cumplan este filtro, envíalas también a este destino". Es el mecanismo que conecta los logs con el resto de la plataforma.

A BigQuery, para analizar. El caso de AlpinaShop: analizar el log de acceso del balanceador con SQL, cruzándolo con los datos de alpinashop_analitica:

El paso del writerIdentity se olvida constantemente: el sumidero se crea, parece funcionar, y no llega nada al destino porque falta el permiso. Es el primer sitio donde mirar si un sumidero no entrega.

El --use-partitioned-tables es importante por coste: particiona por fecha, así que una consulta sobre un día no escanea meses, aplicando lo aprendido en 04-01.

Y entonces se pueden hacer análisis que con el explorador serían imposibles:

A Cloud Storage, para archivar barato. El destino de la retención larga:

Con una regla de ciclo de vida en el bucket (02-02) que baje a Nearline a los 30 días, a Coldline a los 90 y a Archive al año, siete años de logs de pagos cuestan una fracción minúscula de lo que costarían en un bucket de logs.

A Pub/Sub, para reaccionar. El sumidero más interesante conceptualmente, porque cierra el círculo con 06-03:

Cada vez que alguien toca una regla de firewall o una política de IAM, llega un mensaje al topic, y una Cloud Function de 06-03 puede publicarlo en el canal de seguridad de Slack. De un log a una reacción automática, sin intervención humana.

Un sumidero copia; un filtro de exclusión descarta. Y es la palanca más directa sobre la factura de logging.

El razonamiento es sencillo: hay logs que se generan en volumen enorme y no aportan nada al diagnóstico. En AlpinaShop, los principales son las comprobaciones de estado —hc-catalogo golpea /salud cada pocos segundos desde varias sondas, generando decenas de miles de entradas idénticas al día— y las peticiones a recursos estáticos que sirve la CDN.

El parámetro percent=95 es muy útil y poco conocido: excluye una muestra aleatoria en lugar de todo. Conservar el 5 % permite seguir viendo tendencias y detectar problemas con los estáticos, pagando la vigésima parte.

Y la advertencia imprescindible: una entrada excluida no se guarda en ningún sitio y no se puede recuperar. Si excluyes algo que después resulta necesario para investigar un incidente, no hay vuelta atrás. Revisa cada exclusión con la pregunta: ¿podría necesitar esto durante una investigación? Ante la duda, muestrea en lugar de excluir del todo.

Aquí se cierra el vínculo con 06-04. Una métrica basada en logs convierte entradas que cumplen un filtro en una métrica de Cloud Monitoring, sin tocar el código de la aplicación.

Es la técnica más rápida para instrumentar algo que ya se está registrando.

Métrica de contador, para contar ocurrencias:

Con etiquetas para poder desglosar, definida desde un fichero:

Fíjate en la etiqueta version: permite responder de inmediato a "¿estos fallos empezaron con el despliegue de ayer?", correlacionando con el SHA de 06-01. Y respeta la regla de cardinalidad de 06-04: canal tiene tres valores, version unas decenas. Nunca extraigas id_pedido como etiqueta.

Métrica de distribución, para valores numéricos:

Eso permite pintar el p50 y el p95 del importe medio de pedido, un dato de negocio puro obtenido sin escribir una línea de instrumentación específica.

La recomendación práctica: empieza con métricas basadas en logs para validar rápido qué merece la pena medir, y promociona a métricas personalizadas las que resulten importantes de verdad. Y ten presente el riesgo: si alguien renombra un campo del jsonPayload, la métrica deja de contar silenciosamente y la alerta asociada deja de saltar. Un cambio en el formato de un log es un cambio con consecuencias, y merece mención en la revisión de código.

Las métricas dicen que el p95 es de 3,2 segundos. Los logs dicen que hubo errores. Ninguno de los dos dice dónde se fueron esos 3,2 segundos.

Ese es el hueco que llena el rastreo distribuido, y su necesidad crece con el número de piezas. Una petición al catálogo de AlpinaShop atraviesa hoy: el balanceador, Cloud Armor, la CDN, el pod de GKE, una consulta a Cloud SQL, una lectura de Firestore para el carrito y quizá una llamada a la Vision API. Si tarda tres segundos, ¿quién tiene la culpa?

Dos conceptos:

• Una traza representa una petición completa a través de todo el sistema, identificada por un trace_id.
• Un span representa una operación dentro de esa traza, con inicio, fin y un span padre. Los spans forman un árbol.

Con solo mirar el diagrama, la respuesta salta a la vista: SELECT stock_por_talla tarda 3.020 de los 3.240 ms. Ninguna métrica y ningún log habrían señalado eso con esa claridad.

La propagación del contexto es lo que permite que los spans de servicios distintos formen una sola traza. El servicio que inicia la petición genera un trace_id y lo envía en una cabecera; cada servicio que la recibe la lee, crea sus spans como hijos y la propaga a su vez.

El balanceador de GCP añade X-Cloud-Trace-Context automáticamente a cada petición entrante, así que AlpinaShop ya tiene identificadores de traza circulando sin haber hecho nada. Lo que falta es que la aplicación los use.

OpenTelemetry es el estándar del sector para instrumentación —métricas, trazas y logs—, independiente del proveedor. Instrumentar con OpenTelemetry y exportar a Cloud Trace significa que, si mañana AlpinaShop cambia de destino, se cambia el exportador y no la instrumentación.

Con esas tres últimas líneas ya tienes trazas útiles sin modificar ninguna función de negocio. Para el detalle propio, spans manuales:

Y la pieza que lo cambia todo: incluir el trace_id en los logs. Es lo que permitirá el recorrido del apartado 15:

Esas claves especiales logging.googleapis.com/trace y .../spanId no son campos cualesquiera: Cloud Logging las reconoce y rellena los campos trace y spanId de la entrada. Y con eso, la consola muestra un enlace directo de cada log a su traza, y de cada traza a sus logs.

Con la instrumentación puesta, así se lee una traza lenta del catálogo de AlpinaShop:

El diagnóstico es inmediato, y las tres cosas que hay que mirar en cualquier cascada son siempre las mismas:

1. ¿Qué span ocupa el mayor porcentaje? Aquí, stock_por_talla con el 93 %. Optimizar cualquier otra cosa es perder el tiempo.
2. ¿Hay huecos sin cubrir? Un intervalo dentro del span padre que ningún hijo explica suele ser tiempo de espera: bloqueos, contención de pool de conexiones o código no instrumentado.
3. ¿Hay spans repetidos? Cincuenta spans SELECT idénticos consecutivos son la firma inconfundible del problema N+1: una consulta por cada elemento de una lista, en lugar de una consulta para todos.

Con el atributo SQL que añade la instrumentación de SQLAlchemy, la traza incluye la consulta:

Y a partir de ahí, la investigación es de base de datos: EXPLAIN ANALYZE sobre esa consulta, revisar índices, mirar los logs de consultas lentas de Cloud SQL. La traza no arregla el problema; lo localiza en treinta segundos en lugar de en tres horas, y eso es exactamente lo que se le pide.

Un patrón que merece mención aparte: si esa misma consulta tarda 40 ms en un entorno de pruebas y 3.020 ms en producción, el problema probablemente no es la consulta sino la contención —el pool de conexiones agotado, con la petición esperando a que se libere una—. Ahí la métrica de conexiones de Cloud SQL de 06-04 y la traza se refuerzan mutuamente: la traza dice dónde se espera, la métrica dice por qué.

Trazar el 100 % de las peticiones tiene dos costes: el de ingesta de spans, que se factura, y el de rendimiento en la aplicación, que aunque pequeño no es nulo. Por eso se muestrea.

La combinación ParentBased(TraceIdRatioBased(0.1)) del apartado 11 es la correcta por defecto, y merece explicación: TraceIdRatioBased(0.1) muestrea el 10 % de las trazas nuevas, y ParentBased garantiza que si una traza se muestreó al principio, todos los servicios que la reciben también la muestrean. Sin ParentBased, cada servicio decidiría por su cuenta y obtendrías trazas incompletas con agujeros, que son peores que no tener trazas.

El muestreo basado en la cola es lo que todo el mundo querría —guardar el 100 % de las trazas lentas o con error, y el 1 % de las normales— porque las trazas interesantes son precisamente las anómalas. Requiere un colector de OpenTelemetry que retenga los spans hasta el final de la petición para decidir. Para AlpinaShop hoy es complejidad excesiva; conviene saber que existe para cuando el sistema crezca.

Recomendación por entorno:

Que la proporción sea una variable de entorno (TRACE_SAMPLE_RATE) es deliberado: permite subirla al 100 % durante una investigación sin redesplegar código, y bajarla después.

Una traza dice que una función tarda 800 ms. No dice qué hace durante esos 800 ms. Para eso está el perfilado.

Cloud Profiler recoge continuamente muestras de CPU y memoria de la aplicación en producción, con una sobrecarga muy baja —del orden de un pequeño porcentaje—, y muestra un gráfico de llamas con dónde se consume el tiempo y la memoria.

Los tres casos donde Profiler resuelve lo que ningún otro pilar puede:

El tercero merece una advertencia: la intuición sobre dónde está el cuello de botella suele ser errónea. Es habitual pasar dos días optimizando una función que consume el 3 % del tiempo total mientras el 60 % se lo lleva una serialización JSON que nadie miró. Profiler evita ese desperdicio con datos en lugar de conjeturas.

Y la comparación por versión es donde brilla: con service_version fijado al SHA de la imagen, se puede comparar el perfil de dos versiones y ver exactamente qué introdujo una regresión de rendimiento.

Este apartado es la razón de ser de todo el módulo. Volvemos al momento con el que empezó la lección.

23:14 — La alerta. Llega al móvil de Marta. Trae el campo documentation con los cuatro primeros pasos, así que no empieza desde cero.

23:15 — El panel. Confirma: 4,3 % de errores, p95 de 3,2 s frente a los 400 ms habituales, y la CPU del MIG baja. Ese último dato es informativo por sí solo: si hubiera un pico de tráfico, la CPU estaría alta. No lo está, así que el problema no es de capacidad.

23:17 — Los logs. Primera consulta, la del apartado 5:

Aparecen unas 800 entradas. Marta mira una:

23:19 — El patrón. Refina la consulta agrupando por causa y descubre que el 94 % de los errores tienen causa="timeout_consulta" y todos son de rutas de catálogo. No es un fallo general: es una operación concreta.

23:21 — La traza. Y aquí está el salto que justifica toda la instrumentación del apartado 11: en la consola, el campo trace de esa entrada de log es un enlace. Un clic y aparece la traza completa de esa petición exacta, la del cliente concreto que sufrió el error.

23:23 — La cascada. La traza es la del apartado 12: SELECT stock_por_talla consume 3.020 de 3.240 ms. Con la consulta SQL visible en los atributos del span.

23:25 — La causa. Marta ejecuta la consulta 3 sobre los logs de auditoría y sobre el historial de Cloud Build: a las 22:50 se aplicó una migración de base de datos que, entre otras cosas, eliminó y recreó una tabla auxiliar sin volver a crear el índice sobre (sku, almacen). Sin ese índice, la consulta pasa de un acceso indexado a un recorrido completo.

23:31 — La mitigación. Se recrea el índice, y en paralelo se prepara la vuelta atrás de la versión con el pipeline de 06-01. La latencia vuelve a la normalidad en tres minutos.

Diecisiete minutos desde la alerta hasta la causa raíz identificada. Sin este recorrido, la misma investigación habría sido: enterarse por un cliente a la mañana siguiente, mirar la web, no reproducir el problema porque el tráfico nocturno es distinto, revisar logs sin estructura buscando texto, sospechar de tres cosas equivocadas y, con suerte, dar con ello al final del día.

La lección que hay que llevarse: ninguna pieza sirve sola. Una alerta sin logs solo produce ansiedad. Logs sin estructura son un vertedero. Trazas sin logs correlacionados obligan a buscar a ciegas cuál mirar entre millones. El valor está en los enlaces entre las piezas, y el enlace concreto que hace posible todo el recorrido es una línea de código: incluir el trace_id en cada entrada de log.

El modelo es sencillo: se paga por GB ingerido, con un volumen gratuito mensual. La retención dentro del periodo por defecto no se factura aparte; ampliarla, sí. Y verifica siempre los precios vigentes en la documentación oficial.

Las tres decisiones que controlan la factura, por orden de impacto:

Decisión 1: qué se ingiere. Es la más importante con diferencia, porque afecta a todo lo demás. Los filtros de exclusión del apartado 8 sobre comprobaciones de estado y estáticos suelen recortar entre el 40 % y el 70 % del volumen de un sitio web típico, sin perder nada de valor diagnóstico. Y en la aplicación: DEBUG desactivado en producción y ningún log dentro de bucles.

Decisión 2: cuánto tiempo se guarda y dónde. Treinta días en el bucket de logs para diagnóstico, y lo que deba conservarse más tiempo, exportado. Un sumidero a Cloud Storage con ciclo de vida a Coldline y Archive hace que siete años de logs de pagos cuesten órdenes de magnitud menos que ampliar la retención del bucket.

Decisión 3: cuánto se muestrea. Aplica al log del balanceador (--logging-sample-rate), a los VPC Flow Logs (--logging-flow-sampling) y a las trazas (TRACE_SAMPLE_RATE). Con volumen alto, el 10 % suele bastar para detectar patrones, porque la estadística no necesita el censo completo.

Y el error que hay que evitar por encima de todos: excluir logs de error para ahorrar. Son un porcentaje mínimo del volumen y el 100 % del valor durante un incidente. El ahorro está en el ruido repetitivo, nunca en lo excepcional.

Una perspectiva final para calibrar: para AlpinaShop, la observabilidad completa —logs, trazas, métricas, alertas— está en el orden de una fracción pequeña del coste de la infraestructura que observa. Comparado con los diecisiete minutos del apartado 15 frente a un día entero de investigación a ciegas, y con los pedidos que se salvan al detectar un incidente en cinco minutos en lugar de en doce horas, es de las inversiones más rentables de la plataforma.

Usar print en lugar de logging estructurado. El texto acaba en Cloud Logging, sí, pero sin severidad, sin campos consultables y sin trace. Es la diferencia entre poder investigar y no poder.

Meter los datos en el mensaje en lugar de en campos. f"pedido {id} falló" obliga a analizar texto. "Pedido fallido" más {"id_pedido": id} permite filtrar y agregar.

Escribir datos personales en los logs. Correos, nombres, tarjetas, direcciones. Los logs se retienen, se exportan y los lee mucha gente. Usa hashes estables.

Todo con severidad INFO. Impide filtrar por gravedad y hace inútiles las alertas basadas en severity>=ERROR. Y un reintento que funciona es WARNING, no ERROR.

Olvidar el writerIdentity al crear un sumidero. El sumidero se crea sin error y no entrega nada. Es el primer sitio donde mirar cuando un destino está vacío.

Excluir logs sin pensarlo dos veces. Lo excluido no se guarda en ningún sitio y no se recupera. Ante la duda, muestrea con percent en lugar de excluir del todo. Y nunca excluyas errores ni logs de auditoría.

Guardar años de logs en un bucket de logs. Es la forma más cara. Para retención larga, sumidero a Cloud Storage con ciclo de vida.

Etiquetas de alta cardinalidad en métricas basadas en logs. El mismo error de 06-04: EXTRACT(jsonPayload.id_pedido) crea una serie temporal por pedido. Extrae dimensiones con decenas de valores, no miles.

Trazar sin ParentBased en el muestreador. Cada servicio decide por su cuenta y obtienes trazas incompletas con agujeros, que confunden más de lo que ayudan.

No incluir el trace_id en los logs. Es una línea de código y es la pieza que convierte tres herramientas independientes en un sistema de diagnóstico. Sin ella, saltar del log a la traza es imposible.

Optimizar por intuición en lugar de por perfil. Dos días mejorando una función que consume el 3 % del tiempo. Mide primero con Profiler.

Consejo final: la instrumentación se prueba antes del incidente. Provoca un error a propósito en alpinashop-dev, busca su log, salta a su traza y comprueba que el recorrido completo funciona. Descubrir a las once de la noche que el campo trace está vacío es descubrirlo en el peor momento posible.

Este es el código real de una función del catálogo de AlpinaShop:

Reescríbelo con logging estructurado corrigiendo todos los problemas que detectes, justifica cada cambio, y escribe la consulta del explorador de logs que responda a "¿cuántas devoluciones se rechazaron por estado incorrecto esta semana, y de qué importe medio?".

AlpinaShop genera aproximadamente: 80 GB/mes de logs del balanceador, 15 GB/mes de logs de la aplicación, 30 GB/mes de VPC Flow Logs, 2 GB/mes de logs de auditoría de administración y 5 GB/mes de logs de Cloud SQL. Requisitos: los logs de transacciones de pago deben conservarse 7 años por normativa; el equipo necesita 30 días para diagnóstico; Lucía quiere analizar el log de acceso con SQL durante los últimos 12 meses; y hay que reducir el coste todo lo posible sin perder capacidad de diagnóstico. Diseña la configuración completa de buckets, sumideros y exclusiones, con una estimación cualitativa del ahorro.

Un cliente reporta que la página de un producto tarda 8 segundos. Al buscar la traza, Marta encuentra: span raíz GET /catalogo/crampon-02 de 8.100 ms; dentro, consultar_producto de 120 ms y render_plantilla de 90 ms; y nada más. Los 7.890 ms restantes no están cubiertos por ningún span hijo. Los logs de esa petición solo muestran una entrada INFO al principio. Explica qué significa ese hueco, enumera al menos cuatro hipótesis con lo que las distinguiría, y detalla qué instrumentación añadirías para que este caso sea diagnosticable la próxima vez.

Solución 1

Problemas del código original, siete en total:

Versión reescrita:

Justificación de los cambios más importantes:

• El hash del correo resuelve la fuga sin perder capacidad de investigación: atención al cliente aplica la misma función y encuentra las entradas.
• WARNING para el rechazo por estado. Es una decisión deliberada: el sistema hizo lo correcto, no hay avería. Si fuera ERROR, la alerta de 06-04 saltaría por devoluciones perfectamente normales, alimentando la fatiga del apartado 11 de aquella lección.
• El campo resultado con valores acotados (completada, rechazada, error) permite construir un embudo completo con una sola métrica basada en logs.
• Excepciones específicas antes que la genérica. Cada una registra su causa, lo que permite distinguir un problema de la pasarela de un error de programación, que requieren respuestas muy distintas.
• raise en los errores reales. El código original devolvía False tanto si el pedido no era devolvible como si la pasarela estaba caída, y eso hace imposible distinguirlos desde fuera.
• campos_traza() en todas las entradas. Lo que permite el salto del apartado 15.

Consulta pedida:

Para el importe medio, el explorador cuenta pero no promedia bien. Dos opciones. La rápida, una métrica de distribución basada en logs sobre jsonPayload.importe_pedido_eur con ese filtro, que da el p50 y la media en Cloud Monitoring. La completa, un sumidero a BigQuery y SQL:

Y una observación que va más allá del ejercicio: ese desglose por estado_pedido es información de producto, no de infraestructura. Si resulta que la mayoría de los rechazos son de pedidos en estado en_transito, el hallazgo no es técnico: es que hay clientes intentando devolver algo que aún no han recibido, y probablemente la interfaz no se lo está explicando bien. Un buen logging estructurado acaba respondiendo preguntas de negocio que nadie había pensado hacer.

Solución 2

Volumen total: 132 GB/mes. El log del balanceador es el 61 % y los Flow Logs el 23 %: entre ambos, el 84 %. Ahí está todo el margen.

Paso 1 — Exclusiones (la palanca principal):

Volumen ingerido resultante: unos 70 GB/mes, cerca de la mitad. Y sin perder capacidad de diagnóstico: las comprobaciones de estado ya están cubiertas por las métricas de 06-04, los estáticos conservan una muestra del 5 % suficiente para ver tendencias, y el 25 % de Flow Logs sigue detectando patrones de conectividad.

Paso 2 — Buckets con retención diferenciada:

La decisión clave, y es contraintuitiva: el bucket logs-pagos no se configura con 7 años de retención. Guardar siete años en un bucket de logs es la opción más cara con diferencia. La normativa exige conservar, no exige que estén consultables en el explorador de logs. Por eso:

Paso 3 — Sumideros:

Con el ciclo de vida del bucket de archivo: Nearline a 30 días, Coldline a 90, Archive a 365, borrado a 2.555 días (7 años). Y en BigQuery, caducidad de partición a 365 días para el requisito de Lucía.

Estimación cualitativa del ahorro:

El ahorro grueso viene de dos sitios: la mitad del volumen ingerido y, sobre todo, sacar la retención larga del servicio caro al barato, donde la diferencia de precio por GB-mes entre un bucket de logs y Archive es de dos órdenes de magnitud.

Y tres advertencias que completan el diseño. Primera: nunca excluir errores ni auditoría; son un porcentaje mínimo del volumen y el 100 % del valor. Segunda: verificar que el sumidero de pagos captura todo lo que la normativa exige antes de reducir la retención del bucket, porque si el filtro está mal, el requisito legal se incumple en silencio. Tercera: poner una alerta sobre el volumen ingerido con lo de 06-04, para enterarse si alguien introduce un log en un bucle antes de que llegue la factura.

Solución 3

Qué significa el hueco. 7.890 ms de los 8.100 no están cubiertos por ningún span. Y eso tiene un significado muy concreto: está ocurriendo algo que la instrumentación no ve. Solo hay dos familias de explicación —código no instrumentado, o tiempo de espera que no es una operación— y distinguirlas es todo el ejercicio.

Es importante notar algo: los dos spans que sí existen son rápidos. Si el problema estuviera en la consulta o en el renderizado, se vería. El tiempo se va en el espacio entre spans, y eso es lo que hay que investigar.

Cuatro hipótesis, con lo que las distingue:

Cuál es la más probable y por qué. La hipótesis 1, y por un razonamiento que conviene explicitar: la instrumentación automática de OpenTelemetry cubre Flask, requests y SQLAlchemy. Si el código usa cualquier otro cliente —urllib3 directamente, un SDK de un proveedor de pagos, un cliente de Redis, la biblioteca de Firestore— esas llamadas son completamente invisibles. Y ocho segundos con un patrón tan limpio huele a timeout de una llamada externa, muy probablemente uno configurado en 8 segundos exactos.

La hipótesis 2 es la segunda candidata y tiene una firma reconocible: se manifiesta bajo carga y desaparece cuando el tráfico baja. Si el problema solo ocurre en horas punta, es esa.

Instrumentación a añadir, en orden de prioridad:

1. Instrumentar todos los clientes salientes. La medida que resuelve el caso:

2. Un span explícito alrededor de cada operación de negocio. La regla general: si una operación puede tardar, envuélvela en un span. Es barato y elimina huecos por construcción:

El span obtener_conexion_bd es especialmente valioso porque separa el tiempo de espera del tiempo de trabajo, que es justo lo que confunde la hipótesis 2 con la 1.

3. Un log al entrar y al salir de cada operación larga, con duracion_ms. Aunque falte el span, dos entradas de log con marca de tiempo acotan dónde se fue el tiempo.

4. Timeouts explícitos y agresivos en todo cliente externo, y registro cuando saltan:

Esta cuarta medida es la más importante a largo plazo, y va más allá del diagnóstico. Sin timeout explícito, la mayoría de los clientes HTTP esperan indefinidamente o el tiempo por defecto del sistema operativo, que puede ser muy largo. Un servicio del que dependes y que se degrada arrastra al tuyo, y ocho segundos de espera es exactamente eso. Con timeout corto y degradación elegante, una API de valoraciones caída produce una ficha sin valoraciones en 3 segundos en lugar de una página que no carga en 8.

Y la lección general del ejercicio: un hueco en una traza no es un fallo de la traza, es información. Te está diciendo con precisión que hay una parte del sistema que no estás observando. La reacción correcta no es desconfiar de la herramienta, sino preguntarse qué hace el código en ese intervalo que nadie instrumentó. En este caso, casi seguro, esperar a alguien que no contesta.

AlpinaShop tiene los tres pilares de la observabilidad completos, y —más importante— tiene los enlaces entre ellos.

Sabes qué es una entrada de log estructurada y por qué la diferencia entre textPayload y jsonPayload es la diferencia entre poder investigar y no poder. Conoces todos sus campos, y sabes cuál es el decisivo: trace, el que enlaza el log con su traza.

Sabes de dónde salen los logs automáticamente y cuáles hay que activar explícitamente: los del balanceador —de los más valiosos que existen, con su latencia, su país y su resultado de CDN— y los VPC Flow Logs. Y sabes emitirlos bien desde Flask, con las cinco reglas: los datos van en campos y no en el mensaje, la severidad debe ser correcta, nunca datos personales, contexto suficiente para actuar y sin ruido. Con el criterio de severidad que más se falla: un reintento que funciona es WARNING; uno agotado, ERROR.

Dominas el explorador de logs y su lenguaje —con el : que es "contiene" y no "igual"—, los tres consejos de rendimiento, y cinco patrones de consulta que resuelven incidentes reales: los errores desde un despliegue, la petición de un cliente concreto localizada por su hash, quién borró un recurso según los logs de auditoría, las peticiones lentas del balanceador y los errores de la función de imágenes.

Conoces los buckets de logs con _Required y _Default, la retención con sus tres horizontes —diagnóstico, análisis y cumplimiento, cada uno en su sitio— y las vistas que permiten dar acceso a un subconjunto sin exponer los logs de auditoría. Sabes crear sumideros a BigQuery para analizar con SQL, a Cloud Storage para archivar barato con ciclo de vida y a Pub/Sub para reaccionar con una función de 06-03, con el writerIdentity que todo el mundo olvida. Y sabes usar los filtros de exclusión con el percent que muestrea en lugar de descartar, con la advertencia de que lo excluido no se recupera nunca y de que los errores y la auditoría no se excluyen jamás.

Tienes las métricas basadas en logs —contadores y distribuciones— que instrumentan sin tocar el código y alimentan las alertas de 06-04, con la etiqueta version que responde a "¿esto empezó con el despliegue de ayer?" y la misma regla de cardinalidad de siempre.

Sabes qué es el rastreo distribuido: traza y span, la propagación del contexto con traceparent de W3C y X-Cloud-Trace-Context que el balanceador ya está añadiendo. Sabes instrumentar Flask con OpenTelemetry —estándar, no propietario—, con la instrumentación automática de Flask, requests y SQLAlchemy, spans manuales para el detalle, y la pieza clave: incluir el trace_id en cada log. Sabes leer una cascada mirando las tres cosas que importan —qué span domina, si hay huecos y si hay spans repetidos que delaten un N+1—, y sabes muestrear con ParentBased(TraceIdRatioBased(...)) para no acabar con trazas incompletas. Conoces Cloud Profiler y sus tres casos, con la advertencia de que la intuición sobre dónde está el cuello de botella suele fallar.

Y tienes el recorrido completo del apartado 15: de la alerta a la métrica, de la métrica al log, del log a la traza y de la traza a la línea de código, en diecisiete minutos. Con la lección que resume todo el módulo: ninguna pieza sirve sola; el valor está en los enlaces, y el enlace que lo hace posible cabe en una línea de código.

Por último, conoces el coste y las tres decisiones que lo controlan —qué se ingiere, cuánto se guarda y dónde, cuánto se muestrea— con el error que nunca hay que cometer: ahorrar excluyendo errores, que son el mínimo del volumen y el máximo del valor.

Mira ahora dónde está AlpinaShop. El código está en GitHub y se revisa. El pipeline construye, prueba y despliega solo. Las funciones reaccionan a eventos. Hay paneles, alertas, comprobaciones desde cuatro continentes, logs estructurados, trazas y perfiles. Cuando algo falla, se sabe en cinco minutos y se diagnostica en veinte.

Y sin embargo, toda la infraestructura que sostiene eso —la VPC, el balanceador, el clúster, las alertas que acabas de crear, los sumideros que acabas de configurar— sigue existiendo porque alguien ejecutó los comandos correctos. En 06-05 viste el problema con claridad, entendiste qué es la infraestructura como código, conociste Deployment Manager y aprendiste el procedimiento de migración. Lo que falta es la herramienta.

En 06-07, la última lección del módulo, llega Terraform: el estado y por qué nunca va a Git, el flujo plan y apply, el código real de AlpinaShop en HCL, los módulos, la importación de todo lo creado a mano y el plan automático en cada pull request. Y con ello, la infraestructura de AlpinaShop deja por fin de vivir en el historial de un terminal.