Sigue la solicitud de presupuesto hasta su destino

Introducción

PARCEL es una tienda ficticia de regalos. Los visitantes exploran Arc lamp o Clay vase y comparan entrega y recogida. La recogida ya devuelve una estimación, pero la entrega falla. Tu tarea es seguir una solicitud nueva con fallo desde la entrada hasta el servicio que respondió y restaurar precios de entrega correctos sin romper la recogida.

Basta con conocer el uso básico de la terminal. Editarás dos archivos breves de Nginx, leerás logs reales y probarás respuestas reales. No necesitas programar aplicaciones, SDK, cuentas externas, compras ni datos personales. Todos los servicios comparten una instancia de entrenamiento preparada; es correlación de solicitudes, no una plataforma completa de trazas distribuidas.

Usa Website para explorar y pedir estimaciones. Ejecuta todos los comandos en Workstation, que empieza en /home/labex/project/parcel. Cada unidad tiene su propio entorno. La entrada del puerto 8081 reenvía cada estimación a un backend. El servicio de entrega escucha en 8091 y el de recogida en 8092. Un puerto identifica un servicio de red; en Workstation, 127.0.0.1 significa esta instancia del laboratorio.

Una referencia común para una solicitud nueva

En este paso conocerás el recorrido normal del cliente, observarás el fallo y relacionarás una solicitud nueva entre dos logs reales. Empieza en Website.

Conoce la tienda

Abre Arc lamp en Two good things. Su página muestra $48 y una ilustración local. Selecciona Estimate collection, mantén Arc lamp y Near y pulsa Get estimate. Debe mostrar $2.00 y HTTP 200: es la función normal que debes conservar. Vuelve al inicio con PARCEL↗, abre Delivery y pulsa Get estimate. Aparecen Estimate unavailable y HTTP 404.

HTTP es el protocolo de solicitud/respuesta del navegador. 200 indica éxito; 404, que el servicio receptor no encontró la ruta solicitada. Un error de conexión es diferente: no llegó una respuesta utilizable del servidor. La referencia dice not available, por lo que todavía cuesta relacionar la respuesta del cliente con los logs.

Entiende las pruebas

El log de entrada ya registra el identificador generado por Nginx para cada solicitud. El backend puede registrar un identificador reenviado. Una vez conectados, una solicitud fallida produce registros como estos; los puntos representan tu propio identificador:

entry:    {"id":"...","path":"/api/delivery","status":404,"upstream":"127.0.0.1:8091","upstream_status":"404"}
delivery: {"service":"delivery","id":"...","path":"/v1/shipping","status":404}

La ruta de entrada es la solicitada por el navegador. La ruta del backend es la que la entrada reenvió realmente. upstream nombra la dirección contactada y upstream_status su estado real. Un identificador común conecta las observaciones; comparar solo horas sería menos fiable con muchas solicitudes. No se registran cuerpos ni secretos.

Conecta el identificador

Cambia a Workstation. pwd imprime el directorio actual y cat muestra un archivo:

pwd

Espera /home/labex/project/parcel. Si saliste de ahí, ejecuta cd /home/labex/project/parcel; cd cambia el directorio actual. Las rutas sin / inicial, como correlation.conf, son relativas a ese directorio.

cat correlation.conf

Solo contiene un comentario. Nginx es el servidor de entrada preparado. Su configuración usa directivas terminadas en punto y coma. El servidor principal incluye este archivo pequeño; no modificas la estructura principal.

Una cabecera es un valor con nombre que viaja en una solicitud o respuesta HTTP. proxy_set_header establece la enviada al backend; add_header añade una a la respuesta del cliente. $request_id es el valor que Nginx genera para esta solicitud. always incluye la cabecera también en los fallos. X-Request-ID es la convención compartida aquí. La entrada crea su identificador en vez de confiar en uno del visitante.

cat > correlation.conf reemplaza el archivo mediante un here-document. Pega todo el bloque, incluido el último CONF en su propia línea. Las comillas de 'CONF' conservan $request_id literalmente para que lo interprete Nginx, no el shell:

cat > correlation.conf <<'CONF'
proxy_set_header X-Request-ID $request_id;
add_header X-Request-ID $request_id always;
CONF

Lee el archivo guardado y aplícalo con el auxiliar suministrado. bash ejecuta ese script de shell. Primero comprueba la sintaxis y solo recarga Nginx si es válida; no repara rutas ni evalúa precios.

cat correlation.conf

bash reload.sh

Espera una prueba correcta y Configuration accepted. Send a new request to test it. Si aparece un error de línea, compara nombres, puntos y coma y signos de dólar literales con el bloque, reescribe y repite. Si la sintaxis falla, la configuración anterior sigue sirviendo. Recargar no cambia una respuesta antigua: envía otra solicitud.

Sigue tu propio fallo nuevo

En Delivery de Website, pulsa Get estimate otra vez. Sigue fallando, pero Request reference tiene ahora 32 caracteres hexadecimales. Copia ese valor nuevo exacto, no los puntos anteriores ni una referencia de captura.

Vuelve a Workstation. Una variable de shell guarda un valor para comandos posteriores. Sustituye PASTE_YOUR_NEW_REQUEST_REFERENCE_HERE por la referencia nueva exacta copiada de Website. Conserva las comillas simples y no pongas espacios junto a =. Las comillas mantienen el valor literal; no ejecutes el marcador sin sustituirlo:

REQUEST_ID='PASTE_YOUR_NEW_REQUEST_REFERENCE_HERE'

grep imprime líneas coincidentes. -F trata el valor como texto literal y las comillas dobles mantienen unido el valor de la variable. Estas rutas absolutas funcionan desde cualquier directorio:

grep -F "$REQUEST_ID" /var/log/parcel/entry.jsonl

grep -F "$REQUEST_ID" /var/log/parcel/delivery.jsonl

Los dos registros deben tener exactamente el mismo identificador, la ruta backend /v1/shipping y estado 404. Has probado que la entrega llegó a un backend que responde; no es un servicio detenido ni una conexión ausente. Una salida vacía suele indicar una referencia antigua o mal copiada: solicita de nuevo en Website, copia el valor y vuelve a asignar REQUEST_ID. Si solo activaras la cabecera de respuesta, el backend seguiría con -; hacen falta ambas directivas.

La comprobación envía solicitudes nuevas de solo lectura para probar la correlación. No exige una variable concreta, historial de comandos ni archivos de logs copiados.

Restaura la ruta y conserva ambas estimaciones

En este paso usarás los dos registros y el contrato de servicio para reparar la entrega. Empieza en Workstation.

Separa dirección y ruta

Lee la configuración con cat:

cat routes.conf

Un bloque location = coincide con una ruta pública exacta; las llaves agrupan sus directivas. proxy_pass indica adónde enviar la solicitud. En http://127.0.0.1:8091/v1/shipping, dirección y puerto seleccionan el servicio, mientras /v1/shipping selecciona una operación. Cualquiera de las dos partes puede estar mal. En estas ubicaciones exactas, la ruta backend configurada reemplaza la pública coincidente; las opciones de consulta siguen viajando.

Este es el contrato de los servicios:

Ambos responden a /health, pero estar sano no demuestra un enrutamiento correcto. Los logs mostraron la entrega llegando a 8091 en /v1/shipping. El servicio sí es responsable, pero no ofrece esa ruta: el contrato pide /v1/delivery. La dirección y ruta de recogida ya son correctas.

Aplica la reparación pequeña

Reemplaza únicamente el archivo editable, preservando la recogida:

cat > routes.conf <<'CONF'
location = /api/delivery {
    proxy_pass http://127.0.0.1:8091/v1/delivery;
}
location = /api/collection {
    proxy_pass http://127.0.0.1:8092/v1/collection;
}
CONF

bash reload.sh

Si falla la sintaxis, compara llaves y puntos y coma, reescribe y repite. No edites backend, sitio, logs ni configuración principal. Devolver 200 sin una estimación real correcta ocultaría el defecto.

Prueba precios reales y correlación

En Website, abre Delivery y solicita Arc lamp / Near de nuevo. Debe mostrar $6.00, HTTP 200 y una referencia nueva. Solicita Clay vase / Far: espera $13.00. En Collection, Arc lamp / Near debe seguir dando $2.00, y Clay vase / Far, $4.00. Cada clic envía otra solicitud, así que las referencias deben cambiar. Los productos abiertos desde PARCEL↗ deben mantener imágenes y precios.

Vuelve a Workstation. curl envía solicitudes HTTP. -sS oculta progreso pero muestra errores de conexión; -i incluye cabeceras. Las comillas simples conservan & dentro de la URL en vez de dejar que el shell lo interprete. Las opciones tras ? seleccionan objeto y distancia:

curl -sS -i 'http://127.0.0.1:8081/api/delivery?item=vase&zone=far'

Espera HTTP/1.1 200 OK, una cabecera X-Request-ID y JSON con "service": "delivery", "amount": 13, "currency": "USD". JSON es un formato de texto de valores con nombre. El request_id del cuerpo debe coincidir con la cabecera. Su capitalización puede variar sin cambiar el significado.

Toma la referencia de esta respuesta y vuelve a asignar REQUEST_ID y repite ambos grep -F del paso 1. Los logs muestran ahora 200 y el de delivery registra /v1/delivery. Los 404 antiguos son historia útil: no los borres ni reescribas.

Comprueba la función conservada por separado:

curl -sS -i 'http://127.0.0.1:8081/api/collection?item=lamp&zone=near'

Espera 200, "service": "collection" y "amount": 2. Un 404 sigue siendo una respuesta HTTP; curl sin la opción de fallar por estado HTTP puede terminar normalmente. Un error de conexión apunta a un proceso no disponible o dirección errónea: revisa la última configuración válida en vez de confundirlo con la prueba de ruta anterior.

La comprobación final solicita todas las combinaciones de objeto/distancia de ambas operaciones, relaciona identificadores nuevos con logs reales y prueba el sitio completo. Solo se añaden registros normales; evaluar no recarga, reescribe archivos ni crea pedidos.

Resumen

Conectaste los logs de entrada y backend de una solicitud nueva mediante una referencia generada, distinguiste una ruta inexistente de un fallo de conexión y reparaste la ruta real. Probaste resultados variados y conservaste la recogida. El desafío independiente cambia el servicio receptor usando los mismos métodos de dirección/ruta y correlación.