Merge lp://staging/~ev/daisy/time-to-retrace into lp://staging/daisy
| Status: | Merged |
|---|---|
| Approved by: | Brian Murray |
| Approved revision: | 321 |
| Merged at revision: | 320 |
| Proposed branch: | lp://staging/~ev/daisy/time-to-retrace |
| Merge into: | lp://staging/daisy |
| Diff against target: |
132 lines (+47/-1) 4 files modified
daisy/retracer.py (+20/-0) daisy/schema.py (+4/-0) daisy/submit_core.py (+5/-1) test/test_retracer.py (+18/-0) |
| To merge this branch: | bzr merge lp://staging/~ev/daisy/time-to-retrace |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Brian Murray (community) | Approve | ||
|
Review via email:
|
|||
Description of the change
This branch starts tracking the time it takes to retrace a crash from the point it hits the Rabbit queue to the point that we're writing data back to Cassandra.
We currently measure the size of the Rabbit queue over time:
https:/
As well as the time it takes to actually retrace a core file:
https:/
And what the ratio of success to failure is when retracing those core files:
https:/
With this change in place, we can measure the amount of time elapsed from receiving a core file to it being completely processed, anchored to the day that the core file was received.
So if we received a core file four days ago (20130420) and it took us two days to process it off the queue, then the row in TimeToRetrace for the key 20130420 will have a column named by the OOPS ID and a column value of 172800 (two days in seconds).
"timestamp" is a standard property in an AMQP Message:
https:/
This looks good to me but I wonder if it is worth keeping track of the microseconds.