[
https://issues.apache.org/jira/browse/KUDU-3148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17136620#comment-17136620
]
ASF subversion and git services commented on KUDU-3148:
-------------------------------------------------------
Commit 0dc3e9e0a7306ce9b618158b8a20af9b10f4a482 in kudu's branch
refs/heads/master from Grant Henke
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=0dc3e9e ]
KUDU-3148: [test] Add Java client metrics
This patch adds the basic tools for instrumenting the Java
Kudu client with metrics. The primary purpose for this patch
is greater visibility and validation in tests. However, it leverages
micrometer for the metrics to allow for expanded usage and use
cases in the future (e.g JMX publishing, periodic diagnostic
logging, etc).
In this patch I add some counter metrics for RPC requests,
retries, and responses. I leverage these metrics in
TestScanToken to validate the current behavior of ScanToken
generation and use. A follow on patch will use these metrics
more to validate improvements to the ScanToken.
I did not use or enhance the existing Statistics.java
implementation because it didn’t appear to be flexible and
powerful enough for general purpose metrics without a lot of
work (effectively writing something like micrometer). Outside
of the additional work, Statistics.java is public API which makes
it more difficult to change.
Change-Id: I5c63835dd717c2c1e1dca06ed5dea3c2cadcd018
Reviewed-on: http://gerrit.cloudera.org:8080/16067
Reviewed-by: Andrew Wong <[email protected]>
Tested-by: Kudu Jenkins
> Add Java client metrics
> -----------------------
>
> Key: KUDU-3148
> URL: https://issues.apache.org/jira/browse/KUDU-3148
> Project: Kudu
> Issue Type: Improvement
> Components: client
> Affects Versions: 1.12.0
> Reporter: Grant Henke
> Assignee: Grant Henke
> Priority: Major
> Labels: supportability
>
> This Jira is to track adding complete metrics to the Java client. There are
> many cases where applications using the client have issues that are difficult
> to debug. The primary reason is that it's hard to reason about what the
> application is doing with the Kudu client without inspecting the code, and
> even then it can be easy to miss an issue in the code as well.
> For example we have seen many cases where an application creates a Kudu
> client, sends a few messages, and then closes the client in a loop. Creating
> many clients over an over not only impacts performance/stability of the
> application but can also put unwelcome load on the servers. If we had request
> metrics with a client id tag periodically logged, then it would be easy to
> grep the application logs for unique client ids and spot the issue and the
> offending application.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
