KAFKA-2341 Add standard deviation as metric#80
KAFKA-2341 Add standard deviation as metric#80sebadiaz wants to merge 8 commits intoapache:trunkfrom
Conversation
|
kafka-trunk-git-pr #3 SUCCESS |
|
Hi @sebadiaz , could you rebase? |
|
@guozhangwang rebase done |
|
@sebadiaz Seems your rebasing does not take all the changes from apache trunk (there are 1330+ file changes from your patch). |
|
test this |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
| public long eventCount; | ||
| public long lastWindowMs; | ||
| public double value; | ||
| public double secondValue; |
There was a problem hiding this comment.
Instead of doing this, it may be better to have a subclass for the case where there are two values. Also, reset would have to reset secondValue too.
…PartitionException upon topic creation and deletion. (apache#80) TICKET = LI_DESCRIPTION = When does UnknownTopicOrPartitionException typically occur? * Upon a topic creation, a follower broker of a new partition starts replica fetcher before the prospective leader broker of the new partition receives the leadership information from the controller. Apache Kafka has a an open issue about this (see KAFKA-6221) * Upon a topic deletion, a follower broker of a to-be-deleted partition starts replica fetcher after the leader broker of the to-be-deleted partition processes the deletion information from the controller. * As expected, clusters with frequent topic creation and deletion report UnknownTopicOrPartitionException with relatively higher frequency. What is the impact? * Exception tracking systems identify the error logs with UnknownTopicOrPartitionException as an exception. This results in a lot of noise for a transient issue that is expected to recover by itself and a natural process in Kafka due to its asynchronous state propagation. Why not move it to a lower than warn-level log? * Despite typically being a transient issue, UnknownTopicOrPartitionException may also indicate real issues if it doesn't fix itself after a short period of time. To ensure detection of such scenarios, this PR sets the log level to warn. EXIT_CRITERIA = TICKET [KAFKA-6221]
|
I'm going to close this due to inactivity. Note that this change will require a KIP since it affects the public metrics API: https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals. Please reopen if you have time to submit a proposal for this change. |
…PartitionException upon topic creation and deletion. (apache#80) TICKET = LI_DESCRIPTION = When does UnknownTopicOrPartitionException typically occur? * Upon a topic creation, a follower broker of a new partition starts replica fetcher before the prospective leader broker of the new partition receives the leadership information from the controller. Apache Kafka has a an open issue about this (see KAFKA-6221) * Upon a topic deletion, a follower broker of a to-be-deleted partition starts replica fetcher after the leader broker of the to-be-deleted partition processes the deletion information from the controller. * As expected, clusters with frequent topic creation and deletion report UnknownTopicOrPartitionException with relatively higher frequency. What is the impact? * Exception tracking systems identify the error logs with UnknownTopicOrPartitionException as an exception. This results in a lot of noise for a transient issue that is expected to recover by itself and a natural process in Kafka due to its asynchronous state propagation. Why not move it to a lower than warn-level log? * Despite typically being a transient issue, UnknownTopicOrPartitionException may also indicate real issues if it doesn't fix itself after a short period of time. To ensure detection of such scenarios, this PR sets the log level to warn. EXIT_CRITERIA = TICKET [KAFKA-6221]
…he#80) Quickstart examples didn't produce any console output, since it was missing a logger implementation in the classpath. Also some minor cleanups. Tested by creating a test project and running the code. Co-authored-by: Lucas Brutschy <lucasbru@users.noreply.github.com>
This commit make it so that `ControlPlane` knows when a topic created or deleted or when a partition is created (including initial loading of these metadata). Some necessary refactoring made.
Fix the preparing stuck when failback
KAFKA-2341 Add standard deviation as metric