🐘 Caso 03 - PHP 8 con observabilidad comparada#

Implementacion operativa real del caso 03 para contrastar logs pobres contra telemetria util en un mismo flujo funcional.

⬅️ Caso 03 · ⚖️ Comparativa de los 7 stacks · 🐘 Perfil de PHP · 🧬 Todos los perfiles

🎯 Que resuelve#

Modela un checkout con pasos internos y dependencias externas:

validacion del carrito;
reserva de inventario;
autorizacion de pago;
envio de notificacion.

El mismo flujo se expone en dos modos:

checkout-legacy -> logs pobres, sin correlacion y con poco contexto.
checkout-observable -> logs estructurados, correlation IDs, metricas y trazas utiles.

💻 Interfaz Visual Nativa#

Al abrir la ruta raíz en tu navegador (Accept: text/html), este caso inyecta automáticamente un Dashboard visual interactivo renderizado en Vanilla JS/CSS. Esto permite observar las métricas y efectos simulados en tiempo real sin perder la capacidad de responder a consultas JSON de CLI o Postman.

💼 Por que importa#

La mejora no es estetica. Este caso muestra por que la observabilidad reduce MTTR: transforma un incidente vago en una falla diagnosticable con evidencia accionable.

🔬 Análisis Técnico de la Implementación (PHP)#

La telemetría efectiva no es un accesorio, es una implementación estructural de herencia y trazabilidad. Este caso demuestra cómo se codifica nativamente esta capacidad utilizando PHP 8.3 puro.

Logs Opacos (legacy): Utiliza un flujo procedural de concatenación de strings mediante appendLegacyLog('processing customer=' . $customerId). Este enfoque destruye la cardinalidad al no usar tipos de datos estructurados, imposibilitando el parsing algorítmico. Además, falla al no propagar un estado compartido, lo que ignora el "blast radius" de errores intercalados en el FPM Worker.
Logs Estructurados y Trazabilidad (observable): Implanta una arquitectura de Correlation IDs generados mediante bin2hex(random_bytes(4)), asegurando entropía criptográfica para el $traceId y $requestId. El motor de ejecución utiliza una clase de excepción personalizada WorkflowFailure que captura el estado interno (step, dependency, events) en el momento exacto del fallo. Para el volcado de datos, se utiliza json_encode() sobre arreglos asociativos, garantizando que el log sea una estructura de datos O(1) consultable por motores de búsqueda, permitiendo reconstruir la traza completa uniendo eventos bajo el mismo $traceId independientemente del paralelismo de red.

🧱 Servicio#

app -> API PHP 8.3 con logs legacy y observable, metricas y trazas locales.

🚀 Arranque#

bash

docker compose -f compose.yml up -d --build

Como consumir (dos opciones)#

Hub PHP (recomendado, 8100 en compose.root.yml): este caso queda servido en http://localhost:8100/03/... junto a los otros 11 casos.

Modo aislado (813 en este compose.yml): levanta solo este caso, util cuando la medicion necesita procesar limpio (sin otros casos compartiendo runtime).

🔎 Endpoints#

bash

curl http://localhost:8100/03/
curl http://localhost:8100/03/health
curl "http://localhost:8100/03/checkout-legacy?scenario=payment_timeout&customer_id=42&cart_items=3"
curl "http://localhost:8100/03/checkout-observable?scenario=payment_timeout&customer_id=42&cart_items=3"
curl http://localhost:8100/03/logs/legacy?tail=20
curl http://localhost:8100/03/logs/observable?tail=20
curl http://localhost:8100/03/traces?limit=10
curl http://localhost:8100/03/diagnostics/summary
curl http://localhost:8100/03/metrics
curl http://localhost:8100/03/metrics-prometheus
curl http://localhost:8100/03/reset-observability

🧭 Que observar#

si puedes identificar el paso exacto que fallo;
si puedes correlacionar eventos de una misma request;
si tienes latencias por etapa y dependencia;
si el diagnostico permite pasar de "fallo algo" a "fallo payment.authorize por timeout".

⚖️ Nota de honestidad#

No sustituye un stack completo de tracing distribuido. Si deja una base reproducible para demostrar por que logs pobres alargan el MTTR y que cambia cuando la telemetria es util.