| 2019-10-10 09:32:32 |
Cédric Jeanneret |
description |
Hello there!
While squashing timeouts issues within the CI, I thought it would be really, really good to have some fine-grained data about time.
An easy way to do so is to add a statsd daemon that will feed grafana with tagged "pings", allowing to display timelines with extended data.
For instance, we might, before and after each CI step, send a "ping" to the statsd stating "start provisioning", "finished provisioning", "starting container-prepare", .... "starting tempest" and so on.
We might even get deeper, and implement those "ping" directly within tripleoclient, tripleo-heat-templates, or oooq in order to get fine grained data about what task starts when. Such "ping" might be active only within the CI using some env var, option or whatever. This would also allow operators to activate such feature if they have a statsd service somewhere.
I know some of the metrics returned by ansible are already used, but statsd being "made for it", implementing such a service would really be nice, since we will be able to pin-point what takes longer than usual, compare timelines and so on.
Support might even be easier if we get those new, precise metrics.
What do you think?
Cheers,
C. |
Hello there!
While squashing timeouts issues within the CI, I thought it would be really, really good to have some fine-grained data about time.
An easy way to do so is to add a statsd[1] daemon that will feed grafana with tagged "pings", allowing to display timelines with extended data.
For instance, we might, before and after each CI step, send a "ping" to the statsd stating "start provisioning", "finished provisioning", "starting container-prepare", .... "starting tempest" and so on.
We might even get deeper, and implement those "ping" directly within tripleoclient, tripleo-heat-templates, or oooq in order to get fine grained data about what task starts when. Such "ping" might be active only within the CI using some env var, option or whatever. This would also allow operators to activate such feature if they have a statsd service somewhere.
I know some of the metrics returned by ansible are already used, but statsd being "made for it", implementing such a service would really be nice, since we will be able to pin-point what takes longer than usual, compare timelines and so on.
Support might even be easier if we get those new, precise metrics.
What do you think?
Cheers,
C.
[1] https://github.com/statsd/statsd
Some more info: https://www.datadoghq.com/blog/statsd/ |
|
