[
https://issues.apache.org/jira/browse/HBASE-12911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk updated HBASE-12911:
---------------------------------
Attachment: standalone.jpg
ltt.jpg
connection attributes.jpg
0001-HBASE-12911-Client-side-metrics.patch
Patch for master. Here I'm creating a separate bean for each remote host.
Metrics are registered dynamically, which means they probably accumulate over
time, I have a todo for that. The plumbing is in place to collect basic
statistics about the connection itself (meta cache hits/misses, batch pool --
see "connection attributes.jpg"), and individual RPC calls (call method,
destination host, call time, request/response sizes -- "ltt.jpg" or
"standalone.jpg"). I'm using this CallStats pojo to hang interesting metrics
on, let me know if you love or hate that.
No new tests yet, but existing IPC tests all pass locally. Also noticed in my
RS/Master log that the metrics system is being initialized and torn down a
number of times during startup. I'm not sure if that's my fault or not, will
investigate.
> Client-side metrics
> -------------------
>
> Key: HBASE-12911
> URL: https://issues.apache.org/jira/browse/HBASE-12911
> Project: HBase
> Issue Type: Brainstorming
> Components: Client, Performance, Usability
> Reporter: Nick Dimiduk
> Assignee: Nick Dimiduk
> Attachments: 0001-HBASE-12911-Client-side-metrics.patch,
> 0001-HBASE-12911-Client-side-metrics.patch, client metrics RS-Master.jpg,
> client metrics client.jpg, connection attributes.jpg, ltt.jpg, standalone.jpg
>
>
> There's very little visibility into the hbase client. Folks who care to add
> some kind of metrics collection end up wrapping Table method invocations with
> {{System.currentTimeMillis()}}. For a crude example of this, have a look at
> what I did in {{PerformanceEvaluation}} for exposing requests latencies up to
> {{IntegrationTestRegionReplicaPerf}}. The client is quite complex, there's a
> lot going on under the hood that is impossible to see right now without a
> profiler. Being a crucial part of the performance of this distributed system,
> we should have deeper visibility into the client's function.
> I'm not sure that wiring into the hadoop metrics system is the right choice
> because the client is often embedded as a library in a user's application. We
> should have integration with our metrics tools so that, i.e., a client
> embedded in a coprocessor can report metrics through the usual RS channels,
> or a client used in a MR job can do the same.
> I would propose an interface-based system with pluggable implementations. Out
> of the box we'd include a hadoop-metrics implementation and one other,
> possibly [dropwizard/metrics|https://github.com/dropwizard/metrics].
> Thoughts?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
