It would be good to have it. Its not that its not there because its difficult or anything. I think its more that the read latency metric was needed for speculative retry so it was added but the write side wasn't needed for that feature so wasn't added at same time. It would be very useful in determining the table that the coordinator writes are slow to.
Chris > On Feb 11, 2018, at 10:33 PM, kurt greaves <k...@instaclustr.com> wrote: > > I've tried to search around for a reason for this in the past and haven't > found one. I don't think it's a bad idea. Would be a helpful metric to > diagnose internode networking issues - although I'll note that the read > metric will also achieve this assuming you have enough reads to get some > useful information out of it. > > On 9 February 2018 at 17:43, Sumanth Pasupuleti < > sumanth.pasupuleti...@gmail.com> wrote: > >> There is an existing CoordinatorReadLatency table metric. I am looking to >> add CoordinatorWriteLatency table metric - however, before I attempt a shot >> at it, would like to know if anyone has context around why we currently do >> not have such metric (while we have the read metric) - if someone has >> already attempted and realized its a bad idea for some reason. >> >> Thanks, >> Sumanth >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
