[
https://issues.apache.org/jira/browse/PHOENIX-3655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16479490#comment-16479490
]
Karan Mehta commented on PHOENIX-3655:
--------------------------------------
I digged in further through the code. HBase has {{BaseSourceImpl}} class which
contains the HBase metric registry as well as Hadoop metric registry, both of
which eventually get registered to JMX, through different code paths.
If we extend this class (as all other metrics do as of now), the default call
to the constructor will internally create a Hadoop registry as well as HBase
registry, however it will mark the HBase registry as an existing source. This
is a spinet of code from the constructor.
{code:java}
1. this.metricsRegistry = (new
DynamicMetricsRegistry(metricsName)).setContext(metricsContext);
2. BaseSourceImpl.DefaultMetricsSystemInitializer.INSTANCE.init(metricsName);
3. DefaultMetricsSystem.instance().register(metricsJmxContext,
metricsDescription, this);
4. this.registry =
MetricRegistries.global().create(this.getMetricRegistryInfo());
5. this.metricsAdapter = new HBaseMetrics2HadoopMetricsAdapter();
6. this.init();{code}
Line 3 registers all metrics with Hadoop metrics by default. Line 4 creates the
corresponding HBase registry but the call to {{this.getMetricRegistryInfo()}}
specifies the existingSource as true. That is the reason why
{{GlobalMetricRegistriesAdapter.doRun()}} would skip it. The method does
multiple things, first it registers this registry to JMX (which is not required
since its already done before) and it also creates a
{{HBaseMetrics2HadoopMetricsAdapter}} for it. We are probably missing out a
thing here. *We cannot potentially have metrics from both the type of
registries since the backend won't do anything even if those were registered.
We should probably put a check before registering any metric there.*
*Another potential issue at HBase layer is explained below.*
{{GlobalMetricRegistriesAdapter}} is a thread that is scheduled to run at every
10 seconds and collect/register HBase registries to JMX. The executor service
for executing this task is initialized as a part of
{{BaseSourceImpl.DefaultMetricsSystemInitializer#init()}} which is called at
line 2 in the code shown above. Now this forces us to use atleast one Hadoop
based metrics registry even though we dont want to. I came across this issue
since PQS doesn't have any metrics and when I did a POC for publishing metrics
by solely using HBase registry, it was never published.
I believe that rather than writing a shim layer to convert the metrics, Its
better and probably easier to rewrite the metrics itself (GlobalClientMetrics).
I am investigating as to what type of Metric will correspond better to the
metrics exposed by Phoenix. Phoenix metrics keep track of number of samples as
well.
A good example here can be {{GLOBAL_OPEN_PHOENIX_CONNECTIONS}}, which can be
mapped directly to Counter, however I am not sure how metrics such as
{{GLOBAL_MUTATION_BYTES}} will help us track the operations. Is it fine to just
publish the raw value? This will always go over time and doesn't give any
insight if I understand correctly.
[~apurtell] [~tdsilva] [~elserj] Any thoughts?
> Metrics for PQS
> ---------------
>
> Key: PHOENIX-3655
> URL: https://issues.apache.org/jira/browse/PHOENIX-3655
> Project: Phoenix
> Issue Type: New Feature
> Affects Versions: 4.8.0
> Environment: Linux 3.13.0-107-generic kernel, v4.9.0-HBase-0.98
> Reporter: Rahul Shrivastava
> Assignee: Karan Mehta
> Priority: Major
> Fix For: 4.15.0
>
> Attachments: MetricsforPhoenixQueryServerPQS.pdf
>
> Original Estimate: 240h
> Remaining Estimate: 240h
>
> Phoenix Query Server runs a separate process compared to its thin client.
> Metrics collection is currently done by PhoenixRuntime.java i.e. at Phoenix
> driver level. We need the following
> 1. For every jdbc statement/prepared statement/ run by PQS , we need
> capability to collect metrics at PQS level and push the data to external sink
> i.e. file, JMX , other external custom sources.
> 2. Besides this global metrics could be periodically collected and pushed to
> the sink.
> 2. PQS can be configured to turn on metrics collection and type of collect (
> runtime or global) via hbase-site.xml
> 3. Sink could be configured via an interface in hbase-site.xml.
> All metrics definition https://phoenix.apache.org/metrics.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
