The statsd collection in sirun only keeps the last value that it received during the execution of an iteration:
|
metrics.insert(metric[0].into(), metric[1].parse::<f64>()?.into()); |
In the case that a process is sending a statsd metric (e.g., response time for a request) several times during a single sirun execution, we would need all these metrics to be stored in the output from sirun and/or summary statistics for that metric.
There are two approaches to this that I discussed with @bengl:
- Extend the current result hash map to include both
MetricValue and Vec<MetricValue> as values.
- Move to an output format closer to statsd itself where all metrics (either generated internally by sirun or externally by another process) are tagged for the specific execution.
My vote would be for the second format because as it the more generic of the two as an intermediate format and so opens up the possibility for sirun to generate multiple values for a single metric as well.
In either approach, there would need to be work done to alter the summarization step.
The statsd collection in sirun only keeps the last value that it received during the execution of an iteration:
sirun/src/statsd.rs
Line 44 in 59bf057
In the case that a process is sending a statsd metric (e.g., response time for a request) several times during a single sirun execution, we would need all these metrics to be stored in the output from sirun and/or summary statistics for that metric.
There are two approaches to this that I discussed with @bengl:
MetricValueandVec<MetricValue>as values.My vote would be for the second format because as it the more generic of the two as an intermediate format and so opens up the possibility for sirun to generate multiple values for a single metric as well.
In either approach, there would need to be work done to alter the summarization step.