I think that some runners may support both and a user may want the differentiation. Lets say a user had a function which failed occasionally due to some external event. A user could calculate the efficiency of their function by measuring the recorded processing time as a single metric and then computing: committed time / attempted time
On Thu, Jan 19, 2017 at 1:41 AM, Aviem Zur <[email protected]> wrote: > Hi all, > > While working on the implementation of metrics API in Spark runner the > question of committed vs. attempted results has come up, sparking (no pun > intended) an interesting conversation. > (See API: MetricResult > <https://github.com/apache/beam/blob/master/sdks/java/ > core/src/main/java/org/apache/beam/sdk/metrics/MetricResult.java> > and > discussion: PR #1750 <https://github.com/apache/beam/pull/1750>) > > The separation of `attempted` and `committed` metric results seems a bit > unclear. > > Seeing that current implementations of aggregators in the different runners > do not guarantee correctness, one could assume that the metrics API > implementations will also follow the same guarantees. > > If this is correct, then you could assume that only `attempted()` metrics > results can be fulfilled. > Would it then be better to just have a single method such as `get()` in the > API, and have the guarantees of each runner explained in the capability > matrix / documentation? >
