Conversation
arkmish
force-pushed
the
armishra/client-side-metrics
branch
from
August 29, 2026 11:39
58ea722 to
1d05536
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Adds client-side metrics to the ZooKeeper Java client, built on the existing pluggable
MetricsProviderframework (which was always intended for client use, per ZOOKEEPER-3103). Until now only the server emitted metrics viaServerMetrics; the Java client emitted none.ClientMetricssingleton (mirroringServerMetrics) plus instrumentation inClientCnxn. It records per-operation request latency and count, unsuccessful-request counts labelled byKeeperException.Code, ping round-trip time, connect latency, and connection established/loss/reconnect and session-expired counters.queuePacket/finishPacket) and theSendThreadlifecycle. The feature is opt-in: the default provider isNullMetricsProvider(zero overhead), enabled via newzookeeper.clientMetricsProvider.className/zookeeper.clientMetricsProvider.*client properties onZKClientConfig. The provider is a per-JVM singleton shared by allZooKeeperinstances so a real provider is not booted twice (e.g. Prometheus port binding).Tests
The following tests are written for this issue:
ClientMetricsTest(unit — singleton, per-op latency/count, error-by-code, lifecycle counters/summaries)ZKClientConfigMetricsTest(unit — provider class-name default/override andmetricsProvider.*passthrough)ClientMetricsIntegrationTest(integration — real client↔server; asserts create/getData counts, NONODE error count, and connection-established are emitted)The following is the result of the "mvn test" command on the appropriate module (
zookeeper-server):Existing
ZKClientConfigTest(6) still passes. (Note: JMX-harness integration tests are broken in this local environment under Java 25/RMI, unrelated to this change; the metrics integration test is self-contained and avoids that harness.)Changes that Break Backward Compatibility (Optional)
None. The feature is purely additive and opt-in: with no configuration the client uses
NullMetricsProvider, so existing behavior and overhead are unchanged.Documentation (Optional)
Adds a "Client Metrics" section to
zookeeper-docs/.../zookeeperMonitor.mddocumenting how to enable the provider, the per-JVM semantics, and the emitted metrics.🤖 Generated with GitHub Copilot CLI