Hi Ismael,
> > What about a broker that is not the controller? Would you need a separate > > idle-not-controller state? > > > Do we need a separate state or can users just use the ActiveControllerCount > metric to check if the broker is the controller? > Sure - the ACC metric should be sufficient. > > Given that most of the state changes are short > > we would just see blips in the best case and nothing in the worst case > > (depending on how often metrics get sampled). It would only help if you > > want to visually detect any transitions that are taking an inordinate > > duration. > > > > Right. Do you think this is not worth it? > Not sure - I felt the RateAndTime sensors are sufficient and would give more intuitive results. E.g., users would emit the state metric as a gauge but the underlying metric reporter would need to sample the metric frequently enough to capture state changes. i.e., for most metrics backends you would likely see a flat line even through a series of (fast) state changes. > > Ok - my thought was since we are already using kafka-metrics for quotas and > > selector metrics we could just do the same for this (and any *new* > metrics > > on the broker). > > > > I don't have a strong opinion either way as I think both options have pros > and cons. It seems like we don't have the concept of a Gauge in Kafka > Metrics at the moment, so it seems like it would be easier to do it via > Yammer metrics while we discuss what's the best way to unify all the > metrics again. > Sounds good.
