Hey Dong,
Re a) - not really, it's only the corner case when you actually have
consumers but no one is producing (I had that in my environments, when
producer services were shut down weeks before consumers). However, it
is absolutely possible to argue that a simple gauge answering a
question `when
Hey Adam,
Regarding a), if the goal is to monitor the load in the system, then the
existing FetchRequest rate (including those sent by the broker) would
probably be sufficient. Anyway, this new metric for monitoring system load
seems useful with little overhead in code or operation. Just trying to
Hey Dong,
I have observed two usecases:
a) monitoring (if infrastructure does not have any control over
clients) - if I only provide Kafka brokers, but I am not aware of
clients, I cannot say if anyone would even consume the data - this can
be somehow compared to listing existing consumers/connect
Hey Adam,
Got it. Thanks for the explanation. Could you also explain the use-case for
knowing whether a topic with no new messages has active consumers? Just
want to make sure that the use-case is reasonable and can not be
accomplished with the existing available approach.
Thanks,
Dong
On Fri,
Hi Dong,
Unfortunately this does not work when there are no messages, but
consumers are still running.
BytesOutPerSec increases only when the messages are being delivered to
the consumer.
But you could have a situation when consumer is already at the end of
log & noone is going to produce any more
Hey Adam,
Thanks for the KIP. We currently already have the per-topic byte-out-rate
(not including replication traffic) with MBean
path kafka.server:name=BytesOutPerSec,type=BrokerTopicMetrics,topic=*.
Though this is not the FetchRequest rate, it seems to address the
motivation of the KIP by telli
Hello,
There haven't been many comments regarding this KIP (not surprising as
the code change is ~10 lines long). Would it be okay to start the
vote?
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=80452537
Best regards,
Adam Kotwasinski
On Wed, May 2, 2018 at 6:49 AM, Adam Kot
bq. would force subclassing MetricRegistry
Probably not to be done in this KIP due to the yammer API visibility issue
you mentioned.
On Wed, May 2, 2018 at 11:08 AM, Adam Kotwasinski <
adam.kotwasin...@gmail.com> wrote:
> Looks like my understanding of decaying metrics was wrong, could not get
>
Looks like my understanding of decaying metrics was wrong, could not get
the viable example.
The difference in values when marking one metric 10k times, and then
marking the other 10k after 1 minute were to the order of 10^-12, what is
not interesting.
So, I had updated the pull request accordingl
Can you explain Rejected Alternatives #2 in more detail ?
Maybe give some concrete example to show the summation of the two new
metrics is not equal to the existing metric.
On Wed, May 2, 2018 at 6:49 AM, Adam Kotwasinski wrote:
> Hello,
>
> I have created a KIP to add some additional metrics r
Hello,
I have created a KIP to add some additional metrics re number of fetch
requests made to brokers -
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=80452537
Feedback and suggestions are welcome.
Best regards,
Adam Kotwasinski
11 matches
Mail list logo
