You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Colin McCabe (Jira)" <ji...@apache.org> on 2022/08/23 21:26:00 UTC

[jira] [Commented] (KAFKA-14178) NoOpRecord incorrectly causes high controller queue time metric

    [ https://issues.apache.org/jira/browse/KAFKA-14178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17583854#comment-17583854 ] 

Colin McCabe commented on KAFKA-14178:
--------------------------------------

it seems like in general, deferred events should not contribute to this metric. NoOpEvent is one of them but there are some others.

> NoOpRecord incorrectly causes high controller queue time metric
> ---------------------------------------------------------------
>
>                 Key: KAFKA-14178
>                 URL: https://issues.apache.org/jira/browse/KAFKA-14178
>             Project: Kafka
>          Issue Type: Bug
>          Components: controller, kraft, metrics
>            Reporter: David Arthur
>            Priority: Minor
>             Fix For: 3.3.0
>
>
> When a deferred event is added to the queue in ControllerQuorum, we include the total time it sat in the queue as part of the "EventQueueTimeMs" metric in QuorumControllerMetrics.
> With the introduction of NoOpRecords, the p99 value for this metric is equal to the frequency that we schedule the no-op records. E.g., if no-op records are scheduled every 5 seconds, we will see p99 EventQueueTimeMs of 5 seconds.
> This makes it difficult (impossible) to see if there is some delay in the event processing on the controller.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)