Problema
La gràfica Runtime usage no representa correctament el temps executat pels jobs.
Actualment jobs només conserva un únic parell started_at / finished_at. Quan un job es torna a executar, claim_next() incrementa attempts però sobreescriu started_at. Per tant, no tenim un interval de temps persistent per cada run/intent i el runtime dels intents anteriors es perd.
A més, runtime_usage() calcula finished_at - started_at i imputa tot l'interval al dia (i mes) de finished_at. Això pot desplaçar temps al dia següent quan una execució travessa mitjanit.
Exemple
Un job té aquests runs:
- run 1: 23:20–23:50
- run 2: 23:55–00:35
Amb el model actual només queda representat l'últim interval. A més, els 40 minuts del segon run s'imputen íntegrament al dia en què acaba.
Proposta
Fer que cada run/intent tingui el seu propi interval persistent i usar aquests intervals com a font de veritat de les mètriques.
Model de dades
Afegir una taula job_runs (o nom equivalent) amb, com a mínim:
idjob_idattemptstarted_atfinished_atstatus o resultat del runworker_id / locked_by, si és útil per auditoriasession_id, per mantenir la correlació per intent
En reclamar un job, crear el run. En finalitzar, bloquejar, cancel·lar o reencuar l'execució, tancar el run corresponent. Els camps actuals de jobs es poden mantenir temporalment com a resum/compatibilitat, però no haurien de ser la font de veritat del consum.
Cal definir també la retenció dels runs: són dades útils d'auditoria i mètriques, però s'ha d'evitar creixement indefinit sense política explícita.
Imputació diària
Com que un run té una durada màxima aproximada d'una hora, no cal repartir-lo minut a minut entre dies. Imputar cada run al dia local que contingui la part més gran del seu interval:
- calcular el solapament abans i després de mitjanit en la timezone sol·licitada pel dashboard;
- assignar tot el runtime al dia amb més solapament;
- definir un desempat determinista (proposta: dia d'inici);
- derivar l'agrupació mensual a partir del dia imputat.
Això evita atribuir sistemàticament tot el temps al dia de finalització i manté la implementació simple. Si en el futur s'admeten runs llargs, es pot evolucionar a repartir l'interval entre buckets.
Criteris d'acceptació
Nota de compatibilitat
Les dades històriques actuals no permeten reconstruir tots els runs: només tenim attempts i l'últim started_at/finished_at. El backfill hauria de crear, com a màxim, un run històric marcat com a estimat/conegut, sense inventar intervals dels intents anteriors.
Problema
La gràfica Runtime usage no representa correctament el temps executat pels jobs.
Actualment
jobsnomés conserva un únic parellstarted_at/finished_at. Quan un job es torna a executar,claim_next()incrementaattemptsperò sobreescriustarted_at. Per tant, no tenim un interval de temps persistent per cada run/intent i el runtime dels intents anteriors es perd.A més,
runtime_usage()calculafinished_at - started_ati imputa tot l'interval al dia (i mes) definished_at. Això pot desplaçar temps al dia següent quan una execució travessa mitjanit.Exemple
Un job té aquests runs:
Amb el model actual només queda representat l'últim interval. A més, els 40 minuts del segon run s'imputen íntegrament al dia en què acaba.
Proposta
Fer que cada run/intent tingui el seu propi interval persistent i usar aquests intervals com a font de veritat de les mètriques.
Model de dades
Afegir una taula
job_runs(o nom equivalent) amb, com a mínim:idjob_idattemptstarted_atfinished_atstatuso resultat del runworker_id/locked_by, si és útil per auditoriasession_id, per mantenir la correlació per intentEn reclamar un job, crear el run. En finalitzar, bloquejar, cancel·lar o reencuar l'execució, tancar el run corresponent. Els camps actuals de
jobses poden mantenir temporalment com a resum/compatibilitat, però no haurien de ser la font de veritat del consum.Cal definir també la retenció dels runs: són dades útils d'auditoria i mètriques, però s'ha d'evitar creixement indefinit sense política explícita.
Imputació diària
Com que un run té una durada màxima aproximada d'una hora, no cal repartir-lo minut a minut entre dies. Imputar cada run al dia local que contingui la part més gran del seu interval:
Això evita atribuir sistemàticament tot el temps al dia de finalització i manté la implementació simple. Si en el futur s'admeten runs llargs, es pot evolucionar a repartir l'interval entre buckets.
Criteris d'acceptació
started_atpropi.runningtanca el run ambfinished_ati resultat, inclosos retry/requeue, bloqueig i cancel·lació.Runtime usagesuma runs finalitzats, no el parell global del job.work/reviewes conserven.Nota de compatibilitat
Les dades històriques actuals no permeten reconstruir tots els runs: només tenim
attemptsi l'últimstarted_at/finished_at. El backfill hauria de crear, com a màxim, un run històric marcat com a estimat/conegut, sense inventar intervals dels intents anteriors.