Informe de resultados — Experimento HA-01

Detalle por corrida, sensibilidades, dictamen por sub-hipótesis y amenazas a la validez. Resumen ejecutivo y formato guiado en el Informe del experimento HA-01.

Corridas ejecutadas	56, campaña cerrada el 11/09/2026; cuatro corridas adicionales el 16/09/2026
Umbrales	p95 ≤ 225 ms y p99 ≤ 475 ms medidos en el servicio (equivalen a 250/500 ms extremo a extremo una vez sumado el presupuesto de borde)
Criterio operativo	Porcentaje de cotizaciones por encima de 475 ms; el ASR permite como máximo el 1 %
Evidencia	experimentos/ha01/

---

1. Resumen

El brazo C (caché con actualización oportunista y valor de respaldo) cumple el ASR en los seis estados del proveedor con un p99 acotado entre 178 y 190 ms, independiente de la tasa de acierto de caché. Los brazos A y B fallan en al menos un estado. La hipótesis HD-01 se confirma.

El experimento aporta además una corrección que el diseño no anticipaba: el circuit breaker y el desacople protegen frente a fallos distintos, y confundirlos lleva a atribuir al desacople un mérito que en algunos estados es del interruptor, y viceversa.

Dos sub-hipótesis quedan refutadas en su forma publicada (HD-01.3 y HD-01.4) y dos requirieron un cambio de emplazamiento para poder decidir algo (HD-01.5 y HD-01.6).

---

2. Control experimental

Los cuatro brazos viven en el mismo binario y se seleccionan por la variable QUOTE_STRATEGY, de modo que la estrategia de resolución del perfil es la única variable que cambia entre ellos. El contrato de respuesta es idéntico por construcción. El motor de tarifa tiene costo fijo calibrado (~60 ms), constante entre brazos.

Cada corrida reinicia la API y vacía Redis, de modo que el interruptor arranca cerrado y la caché en estado conocido. El protocolo es de tres fases —120 s sana + 120 s degradada + 60 s de recuperación, precedidas de 60 s de rodaje no contabilizados— y cada fase se analiza por separado: agregar las tres produciría un percentil sin significado, porque son tres poblaciones distintas.

Cada corrida archiva nueve verificaciones de sanidad en sanidad.txt, incluida la comprobación de que hubo tráfico en cada fase. Las 56 corridas las pasan.

---

3. Resultados por brazo y estado del proveedor

Porcentaje de cotizaciones por encima de 475 ms en la fase degradada (tráfico alto, 200 sol/s, acierto 96 %):

Estado del proveedor	A (directo)	B (caché bloqueante)	C (oportunista)
sano	✅ 0,00 %	✅ 0,00 %	✅ 0,00 %
lento	❌ 34,10 %	❌ 1,28 %	✅ 0,00 %
degradado	❌ 4,55 %	✅ 0,18 %	✅ 0,00 %
sin respuesta	❌ 4,25 %	✅ 0,18 %	✅ 0,00 %
caído	⚠️ 0,00 % ¹	✅ 0,00 %	✅ 0,00 %
intermitente (30 % de fallos)	—	❌ 1,22–1,25 %	✅ 0,00 %

¹ Cumple la latencia por un camino que el propio diseño declara inaceptable. Ver §3.2.

La figura hace visible de un vistazo el resultado central: la barra verde (C) es plana en los cinco estados mientras la azul (A) se dispara a 545 ms de p95 con el proveedor lento y la naranja (B) rompe el p99 en ese mismo estado con 490 ms. En degradado y sin respuesta, donde el interruptor abre, B vuelve a 65 ms — es el rescate por el interruptor que se analiza en §3.1.

Con el proveedor sano, HD-01.1 se confirma: p95 de A 174,1 ms · B 64,9 ms · C 64,9 ms contra un umbral de 225 ms, replicado en la fase sana de todas las corridas (A entre 173,3 y 174,6 ms).

3.1 El interruptor y el desacople hacen cosas distintas

Es el hallazgo de mayor valor arquitectónico del experimento, y no estaba previsto.

• Proveedor caído → el interruptor abre en segundos y a partir de ahí todas las llamadas fallan rápido. B también cumple. El interruptor basta.
• Proveedor lento → el proveedor responde dentro del timeout duro de 700 ms, así que el interruptor nunca abre. B paga el camino frío en cada fallo de caché y llega al 1,28 %. Sólo el desacople cumple.
• Proveedor intermitente → con 30 % de fallos no se alcanzan ni diez fallos consecutivos ni el 50 % de la ventana: el interruptor no abre en ningún brazo. B incumple, C cumple. La diferencia es atribuible sólo al desacople, sin explicación alternativa.

El caso intermitente se verificó bajo dos modelos de fallo independientes:

Corrida	Brazo	Modelo de fallo	Sobre 475 ms	p99	¿Abrió?
b5_intermitente_rate	B	por cliente	❌ 1,101 %	709,2 ms	No
b5_intermitente_count	B	por cliente	❌ 1,163 %	714,0 ms	No
b5b_intermitente_rate	B	por petición	❌ 1,218 %	717,9 ms	No
b5b_intermitente_count	B	por petición	❌ 1,247 %	719,8 ms	No
b5_intermitente_*	C	por cliente	✅ 0,000 %	178,4 / 178,5 ms	No
b5b_intermitente_*	C	por petición	✅ 0,000 %	178,0 / 178,3 ms	No

Las corridas b5_* originales derivaban la decisión de fallo del customer_id, de modo que el 30 % de los clientes fallaba siempre y el 70 % nunca: no era un proveedor intermitente sino un subconjunto fijo de clientes rotos. Como el razonamiento depende del entrelazado de fallos y aciertos, la celda se repitió con la decisión derivada de un contador de petición. El resultado se mantiene y B empeora ligeramente, de modo que el hallazgo deja de depender del modelo de fallo.

3.2 La latencia no es el único eje: proporción resuelta con valor de respaldo

Porcentaje de cotizaciones tarifadas sin ninguna señal de Open Finance, en la misma fase degradada:

Estado del proveedor	A	B	C
sano	0,00 %	0,00 %	0,23 %
lento	0,00 %	0,00 %	3,73 %
degradado	98,94 %	3,43 %	4,01 %
sin respuesta	99,43 %	3,81 %	3,82 %
caído	98,89 %	3,95 %	3,67 %

El brazo A no tiene caché: cuando el interruptor abre, devuelve el perfil por defecto sin posibilidad de último valor conocido. Su ✅ con el proveedor caído significa que el 98,9 % de las cotizaciones se tarifica a ciegas. B y C, en esa misma celda, resuelven el ~96 % desde caché con datos reales.

El criterio de refutación del Anexo B —«se refuta la hipótesis si el brazo C alcanza el umbral sólo degradando la proporción de valor de respaldo a un nivel que actuaría considere inaceptable»— se aplicó a C pero no a A al declararlo conforme. Con el criterio del propio diseño, A con proveedor caído es el ejemplo canónico de cumplir la latencia por un camino inaceptable.

Conclusión. La proporción con respaldo debe ser medida de respuesta de primera clase en EC-LAT-09, junto al percentil.

Es el precio del brazo C, y lo que el diseño declaraba sin cuantificar. El panel izquierdo muestra que en la fase degradada A resuelve con respaldo el 59,5 % y C el 18,2 %; el derecho, que C tarifa con datos de 896 s de antigüedad en el p95 mientras A no tiene dato antiguo porque sencillamente no tiene dato.

Atención al leer estas cifras. La figura promedia los cinco estados del proveedor del bloque 1, así que no coincide con la tabla de arriba, que es por estado. El 59,5 % de A es la media de 0 % (sano), 0 % (lento) y ~99 % (degradado, sin respuesta, caído). La tabla por estado es la que debe citarse en una conclusión; la figura sirve para ver la forma del intercambio.

---

4. Sensibilidad a la tasa de acierto de caché (punto de sensibilidad 3)

Con el proveedor lento:

Acierto	B: > 475 ms	B: p99	C: > 475 ms	C: p99	C: con respaldo
99 %	✅ 0,29 %	65 ms	—	—	—
98 %	✅ 0,73 %	453 ms	—	—	—
96 %	❌ 1,28 %	492 ms	✅ 0,00 %	186 ms	3,7 %
90 %	❌ 3,06 %	528 ms	✅ 0,00 %	188 ms	9,2 %
50 %	❌ 16,75 %	556 ms	✅ 0,00 %	190 ms	49,2 %

En C la tasa de acierto no decide el percentil. El peor caso es siempre presupuesto + tarifa (~190 ms), con cualquier acierto. Quien depende del acierto es B, y su punto de quiebre está entre el 96 % y el 98 %, es decir alrededor del 97 %.

HD-01.4 queda por tanto refutada en su forma publicada. Redacción propuesta:

HD-01.4 — Con el proveedor lento, el p99 de B cumple sólo con acierto ≥ 97 %. El p99 de C cumple con cualquier acierto; lo que depende del acierto es la proporción resuelta con respaldo.

Advertencia sobre la segunda cláusula. Cuando el proveedor no responde dentro del presupuesto, la proporción con respaldo es ≈ 1 − acierto (3,7 % con 96 %, 9,2 % con 90 %, 49,2 % con 50 %). Exigir «respaldo ≤ 5 %» equivale a exigir «acierto ≥ 95 %»: es aritmética, no un resultado experimental. Lo que falta es el umbral de respaldo que actuaría considere aceptable; ese número fija directamente el acierto necesario.

---

5. Sensibilidad a la política del interruptor (punto de sensibilidad 4)

El diseño asignaba este punto al brazo C. En C es indecidible: las cuatro celdas cumplen con holgura porque ninguna petición espera más que el presupuesto, de modo que la política del interruptor es invisible al percentil. Se reubicó al brazo B, donde sí discrimina.

Con el proveedor sin respuesta:

Política	Tráfico	B: > 475 ms	B: p99	Abre en	C: > 475 ms
tasa	alto (200 sol/s)	✅ 0,24 %	65 ms	7 s	0,00 %
tasa	bajo (10 sol/s)	✅ 0,77 %	65 ms	11 s	0,00 %
conteo	alto	✅ 0,07 %	65 ms	5 s	0,00 %
conteo	bajo	❌ 1,19 %	716 ms	15 s	0,00 %

Es exactamente la interacción que HD-01.6 predecía: con tráfico alto el conteo es la mejor política; con tráfico bajo es la que rompe el ASR. La política por tasa nunca incumple y nunca gana.

Decisión de diseño: política por tasa sobre ventana deslizante. Es la opción robusta frente a la variación de tráfico, que es precisamente lo que un ASR de latencia no puede dejar al azar.

En el brazo C el interruptor no protege la latencia: protege el pool de conexiones y al proveedor. Ese es su papel en el diseño adoptado.

---

6. Efecto de la coalescencia (punto de sensibilidad 5)

Con los pools de claves normales hubo 0 coalescencias en las ocho corridas del bloque 3: el sorteo uniforme sobre 10⁵–10¹² claves no produce fallos concurrentes sobre la misma clave. Para poder medir el efecto hizo falta una celda que concentrara el tráfico en 20 claves con TTL de 2 s:

Brazo	Coalescidas	Invocaciones en vuelo (pool = 40)	p99
C	0	❌ 101	183 ms
C′ (single-flight)	577	✅ 20	184 ms

Sin coalescencia el pool se satura —101 invocaciones en vuelo sobre un pool de 40—; con coalescencia queda en 20, una por clave. La latencia apenas cambia (183 contra 184 ms).

La coalescencia se justifica por protección de recursos, no por latencia. HD-01.7 se confirma en su parte de saturación del pool y se matiza en su parte de percentil.

---

7. Sensibilidad a la tasa de llegada — EC-LAT-02

El diseño declaraba la tasa de llegada como variable independiente sin llegar a variarla. Se añadió el bloque 4, con escalones de 120 s:

Escalón	p95	p99
20 sol/s	65 ms	138–149 ms
50 sol/s	65 ms	138–149 ms
100 sol/s	65 ms	138–149 ms
200 sol/s	65 ms	138–149 ms

La latencia es plana de 20 a 200 sol/s, en B y en C. Multiplicar la carga por diez no mueve el percentil. EC-LAT-02 (horario pico) se cumple.

---

8. Recuperación — HD-01.8 ✅

Al restaurar el proveedor:

• El interruptor cierra entre 5 y 14 s (criterio: ≤ 60 s).
• La proporción con respaldo vuelve por debajo del 5 % entre 0 y 26 s.
• El pico de invocaciones al proveedor no supera la línea base: 8,4 contra 10,3/s, y 16,7 contra 16,6/s en la celda de estampida (criterio: ≤ 3×).

No se produce estampida de repoblado. HD-01.8 se acepta.

La dinámica segundo a segundo de cada corrida —estado del interruptor superpuesto a la latencia, invocaciones al proveedor y proporción con respaldo a lo largo de las tres fases— está en las once figuras de serie fig4_serie_*.png del repositorio, una por celda del bloque 3. No se reproducen aquí por volumen: results/analysis/figuras/.

---

9. Restricciones de presupuesto

9.1 EC-LAT-07 (≤ 120 ms por dependencia) ❌ incumplido con el proveedor degradado

Medido por fase sobre la latencia del adaptador, agregado por estado del proveedor:

Estado del proveedor	n	p95 del adaptador	% > 120 ms	Veredicto
sano	3	114,9 – 121,8 ms	3,2 – 5,1 %	⚠️ al filo
caído	3	19,7 – 85,1 ms	0,0 – 0,6 %	✅
lento	5	490,3 – 495,6 ms	99,1 – 100,0 %	❌
intermitente ²	8	entre 700 ms y 1 s	31,1 – 34,2 %	❌
sin respuesta ²	3	entre 700 ms y 1 s	81,8 – 93,2 %	❌
degradado ^1,2^	3	entre 700 ms y 1 s	85,0 – 96,9 %	❌

¹ Muestra pequeña en B y C. En la celda degradado el adaptador registra sólo 25 llamadas en B y 32 en C, frente a 650 en A: al abrir el interruptor a los ~7 s, el resto de las invocaciones se corta sin llegar a cronometrarse. El incumplimiento no depende de esa celda: se sostiene sobre lento, con 452 llamadas y el 99,78 % fuera de presupuesto.

² El p95 no es resoluble por encima de 700 ms. El histograma del adaptador tiene fronteras en 500, 700, 1000 y 2000 ms. En estos tres estados todas las observaciones caen en el bucket (700 – 1000 ms] y ningún bucket intermedio se incrementa, de modo que histogram_quantile interpola linealmente dentro de él y devuelve cifras de 948 a 984 ms que no son mediciones sino el punto medio ponderado del bucket. Lo que la evidencia sostiene es que las llamadas se cortan entre 700 ms y 1 s, consistente con el timeout duro de EC-LAT-08 disparando a 700 ms más el sobrecoste de cancelación.

El veredicto de EC-LAT-07 no depende de esa cifra: descansa en el porcentaje por encima de 120 ms, que es conteo directo de la frontera de bucket le="0.12" y por tanto exacto. Resolver el p95 en esa franja exigiría añadir fronteras entre 700 ms y 1 s al histograma, lo que no aportaría nada al dictamen.

Dos lecturas importan:

El único estado degradado en que la restricción se cumple es caído, y se cumple por el interruptor. Al abrir, corta las llamadas y el adaptador responde en decenas de milisegundos sin tocar al proveedor. Es la misma separación de mecanismos de §3.1.

Con el proveedor lento la restricción no se cumple en absoluto: el 99,78 % de las llamadas se sale del presupuesto. Y con el proveedor sano queda al filo (121,8 ms contra 120).

Esto refuerza la hipótesis en vez de debilitarla. Si la dependencia cupiera en 120 ms, cabría preguntar para qué hace falta la actualización oportunista. Lo que la evidencia muestra es lo contrario: la dependencia no cabe, y por eso el desacople es la condición para cumplir el ASR de cotización. El brazo C cumple justamente porque abandona al agotar el presupuesto — que es el mecanismo bajo prueba.

Nota metodológica. Una versión anterior declaraba EC-LAT-07 cumplido con 111–117 ms. Esa cifra salía de contadores acumulados de toda la corrida, que mezclan las tres fases: en una corrida con estado degradado lento, dos tercios de las llamadas provienen de fases sanas y arrastran el percentil hacia abajo. La regla de no agregar fases distintas ya se aplicaba a la latencia de cotización; el adaptador era la única métrica que se le escapaba, porque no pasaba por el pipeline de análisis. Hoy sí: p95_adapter_ms y pct_adapter_sobre_120ms son columnas del consolidado.

9.2 EC-LAT-08 (timeout duro de 700 ms) ✅

Verificado en el adaptador y en los p95 por camino (~700–795 ms en los estados donde el proveedor no responde).

9.3 Reparto interno del brazo C — el Anexo G rehecho con valores medidos

El Anexo G del diseño estimaba el reparto del presupuesto de 225 ms por camino. Contrastado con lo medido (p95 por origen en el brazo C, bloque 1):

Camino	Anexo G (predicho)	Medido	Diferencia
Caliente (acierto de caché)	110 ms	64,2 – 64,3 ms	−42 %
Frío (fallo, proveedor sano)	210 ms	164,8 – 168,9 ms	−21 %
Degradado, interruptor abierto	110 ms	64,3 ms	−42 %
Degradado, interruptor cerrado	no previsto	189,3 ms	—

Tres correcciones al Anexo G:

1. Las tres estimaciones eran pesimistas. Los tres caminos previstos cuestan menos de lo presupuestado, lo que amplía el margen real del brazo C.
2. Falta una fila. El Anexo G modelaba el camino degradado sólo con el interruptor abierto. El caso que de verdad decide —proveedor lento, donde el interruptor nunca abre y la petición espera el presupuesto íntegro antes de resolver con respaldo— cuesta 189,3 ms y no estaba contemplado. Es exactamente el caso que refuta HD-01.3: el camino degradado (189,3 ms) resulta más lento que el camino frío con proveedor sano (164,8 ms).
3. El camino frío no consume el 93 % del presupuesto, sino el 73 % (164,8 sobre 225 ms). Sigue siendo el camino dominante y la justificación del punto de sensibilidad 3 se mantiene, pero el margen es mayor de lo que el diseño suponía.

Advertencia del propio Anexo G que sigue vigente. Los 25 ms de presupuesto de borde son «una estimación, no una medición». Como el brazo C queda en 64–190 ms según el camino —holgadamente por debajo de los 225 ms— la advertencia no compromete el dictamen: no estamos en la franja de 225 a 250 ms donde habría que medir el gateway antes de comprometerse.

[!NOTE] El Anexo G no está publicado en la wiki: la página Diseño de experimento HA-01 lo referencia cuatro veces pero no lo contiene. La versión completa del diseño, con el anexo, existe como documento aparte. Conviene incorporarlo a la wiki con esta tabla ya corregida.

---

10. Dictamen por sub-hipótesis

ID	Enunciado	Dictamen
HD-01.1	Con el proveedor sano, los tres brazos cumplen p95 ≤ 225 ms	✅ se acepta
HD-01.2	Con el proveedor degradado, sólo C cumple	⚠️ se acepta en parte — B también cumple cuando el interruptor abre (caído, degradado, sin respuesta). Sólo C cumple en los seis estados
HD-01.3	El camino degradado es más rápido que el frío	❌ se refuta — sólo con el interruptor abierto. Con proveedor lento el degradado cuesta 189 ms contra 159 ms del frío
HD-01.4	C sostiene el umbral con acierto ≥ 96 %	❌ se refuta — en C el acierto no decide el percentil. Quien depende del acierto es B, con mínimo ~97 %
HD-01.5	Sacrificadas < 1 % con tráfico alto	✅ se acepta, medida en B
HD-01.6	Con tráfico bajo el conteo no mantiene < 1 % y la tasa sí	✅ se acepta, medida en B (1,19 % contra 0,77 %)
HD-01.7	Sin coalescencia, más de una invocación por fallo y saturación del pool	✅ se acepta en la parte de pool (101 contra 20 en vuelo); la latencia no cambia
HD-01.8	Al recuperarse, el interruptor cierra y el respaldo baja del 5 % en ≤ 60 s sin estampida	✅ se acepta

HD-01 (hipótesis principal): se confirma.

---

11. Amenazas a la validez (Anexo D)

Derivadas del montaje local

• El doble del proveedor es una hipótesis, no una medición. La distribución log-normal (p50 60 ms, p95 110 ms) se ajustó por diseño; el proveedor real puede tener otra forma de cola. Todas las conclusiones sobre márgenes de milisegundos dependen de esa elección.
• El motor de tarifa es casi toda espera. Con RATING_CPU_ITERS=1200 el costo real de CPU es de décimas de milisegundo: el motor no reproduce la competencia por CPU de un motor de reglas real. Un motor con costo de CPU significativo introduciría contención que este montaje no mide.
• Sin latencia de red entre componentes. Todo corre en contenedores sobre la misma máquina.
• Sobrecosto del inyector de fallas. Medido con un estimador pareado: +1,6 ms (IC 95 % [+0,8, +5,8]). Se descuenta de las comparaciones pero no es cero.

Derivadas del diseño del experimento

• Una repetición en vez de tres. El Anexo B exige tres corridas contrabalanceadas (cuadrado latino). Se ejecutó una, salvo en la celda que decide —B con proveedor lento, al 1,28 % contra el 1 % permitido—, que sí tiene tres: 1,28 %, 1,15 % y 1,24 % (σ ≈ 0,07 puntos). La justificación es la varianza medida entre corridas independientes: p95 de 64,8 a 64,9 ms en seis corridas. Con n=1 el contrabalanceo pierde sentido; el riesgo de efecto de orden queda mitigado porque cada corrida reinicia la API, vacía Redis y restablece el proveedor.
• El estado degradado del diseño es, en la práctica, una caída. Con 820 ± 120 ms todas las llamadas superan el timeout duro, de modo que se comporta casi igual que sin respuesta. El estado que de verdad separa los brazos es lento, y es el que materializa el estímulo de EC-LAT-09.
• El estado intermitente no estaba en el diseño. Se añadió durante la ejecución y es el que sostiene el argumento más fuerte.
• Evidencia del estado inyectado ausente en las 52 primeras corridas. toxiproxy.json se capturaba después de restaurar el estado sano, así que todas guardan "toxics":[]. No invalida los resultados —el estado efectivo se corrobora por las latencias observadas y por provider_metrics.txt— pero el artefacto designado para confirmarlo no lo confirma. Corregido para las corridas posteriores con toxiproxy_degradado.json.
• Un fallo intermitente de detección de carga apareció una vez y no se pudo reproducir. Mitigado con reintento automático y diagnóstico; el intento fallido se conserva como evidencia.

---

12. Defectos del montaje encontrados y corregidos durante la ejecución

Se documentan porque varios habrían invalidado la medición de haber pasado inadvertidos:

• El reloj de las fases iba atado a aritmética de sleep: una ventana entera llegó a caer fuera de la carga y la corrida se dio por válida. Se añadió la verificación de tráfico por fase.
• La tasa de acierto derivaba durante la corrida por repoblado de la caché.
• El origen del perfil se guardaba en la caché: la edad del dato se reportaba como 0 y el camino caliente se etiquetaba como frío.
• Las métricas de invocaciones contaban las llamadas que el interruptor corta sin llegar al proveedor: la recuperación aparecía como 200/s cuando al proveedor llegaban 15.
• PoolTimeout se contaba como falla del proveedor: saturación propia abriría el interruptor con el proveedor sano. Separado y excluido.
• El escalón de 200 sol/s del bloque 4 corrió con acierto 0,86 en vez de 0,96, porque la dispersión de edad del pool caliente más la duración de la corrida superaban el TTL. Repetido.
• La decisión de fallo del estado intermitente se derivaba del customer_id. Corregida y la celda repetida (§3.1).

---

13. Lo que queda abierto

1. El umbral de respaldo aceptable. El experimento mide la proporción; cuánto es admisible lo decide actuaría. Sin ese número el criterio de refutación del Anexo B es inaplicable y C gana por definición. Es la brecha más importante y no se cierra con más corridas.
2. Trazabilidad en Jira. Estrategia-de-pruebas.md asocia EC-LAT-09 a HA-07 y el diseño lo asocia a HA-01.
3. Publicar el Anexo G en la wiki. La página del diseño lo referencia cuatro veces sin contenerlo. La tabla ya corregida con valores medidos está en §9.3 de este informe.
4. Conteo de estados en el diseño. El modelo de fallas define cinco estados y hoy son seis con intermitente; conviene declararlo explícitamente en el Anexo A y señalar cuál materializa el estímulo de EC-LAT-09 — es lento, no degradado.

---

Anexo — Trazabilidad

Elemento	Referencia
Diseño del experimento	Diseño de experimento HA-01
Informe en formato guiado	Informe del experimento HA-01
Arquitectura vigente	Hoja de trabajo semana 5
Implementación y datos crudos	experimentos/ha01/
Consolidado por fase (224 filas)	resultados_por_fase.csv
Series temporales completas	results/prometheus/