> On Jan. 30, 2013, 1:55 a.m., Vinod Kone wrote: > > > > Ben Mahler wrote: > They will both be writing to the same timeseries in that case. > > I'll trust callers not to make that mistake, since they could make the > same mistake across two semantically different non-metered statistics, and > there's no way to stop them there either! On the positive side, it's > completely non-fatal. > > Vinod Kone wrote: > I disagree. We could/should never trust callers to not make mistakes. We > should (as much as possible) program to disallow mistakes like that. Also, > non-fatal doesn't mean its correct? > > How about, you maintain a hashset of stat names (including meter names) > and check against that?
I agree with your disagreement ;) I think in this case, we're providing a primitive to write statistics, callers making mistakes is equivalent to multiple people writing to the same file, which is bad, but the kernel cannot prevent this, nor would it want to! Maybe this helps, to see why your suggestion will not work: Across stats: set(context, name, value); // now the hashset contains <context, name> set(context, name, value); // hey! <context, name> is in our set! Is this ok? Depends on the caller's intent! Across meters: meter(context, name, meter_name); // now the hashset contains <context, meter_name> after a value comes in meter(context, name, meter_name); // hey! <context, meter_name> is in our set! Is this ok? Depends on the caller's intent! Across stats/meters: set(context, meter_name, value); // now hashset contains <context, meter_name> meter(context, name, meter_name); // hey! <context, meter_name> exists! Is this ok? In this case, no, but how do we know? This last case is the only enforceable check, but a hashset is not sufficient. We need to track the "source" (i.e. raw stat? metered stat?) to do this check. I think this starts to store a lot of meta-data about the stats, which gets clunky and inefficient. I'd like to think of Statistics as a simple, map-like primitive. Did this make sense, or did I misunderstand? - Ben ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9092/#review15814 ----------------------------------------------------------- On Jan. 31, 2013, 6:16 p.m., Ben Mahler wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/9092/ > ----------------------------------------------------------- > > (Updated Jan. 31, 2013, 6:16 p.m.) > > > Review request for mesos, Benjamin Hindman and Vinod Kone. > > > Description > ------- > > This add metering into the statistics model. The metering was inspired by > jie's monitoring reviews. > > We'll need to compute metered data on top incoming raw data. The challenge is > that some meters will require previous data: > For example: > 1. cpu_time = 10 @ time 10; > 2. cpu_time = 20 @ time 20; --> cpu_usage = 1.0 (100%) this is 20-10 / 20-10 > 3. cpu_time = 25 @ time 30; --> cpu_usage = 0.5 (50%) this is 25-20 / 30-20 > > > This addresses bug MESOS-324. > https://issues.apache.org/jira/browse/MESOS-324 > > > Diffs > ----- > > third_party/libprocess/include/process/statistics.hpp > 9e3041a6e2a8ef022eacacad00bc4d974a8e33c9 > third_party/libprocess/src/statistics.cpp > 2fe8af83c6c63a0fa8cb2e9636f9289f0e3d7f2f > > Diff: https://reviews.apache.org/r/9092/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Ben Mahler > >
