Andrew Purtell commented on PHOENIX-3655:

I would argue for converting the metrics to hbase metrics. Let the hbase 
metrics impl classes deal with legacy.

If the new API still has rough edges that cause legacy to leak in we should fix 

bq. 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? 

Yeah, as a Gauge, for simple export of a raw value.

Where we care about the distribution of values, use a Histogram. 

Use Meter for something we are tracking as the rate of something (like ops/sec)

Use Timer if we are tracking the time it takes to do something (like op latency)

> 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

Reply via email to