Josh Elser commented on PHOENIX-3655:

[~karanmehta93], that's great! I don't think I have much more to add at this 
point other than what's already in back-chat above.

If memory serves, some high-level goals would be:
 * Avoid getting tied to a particular metrics impl
 * Expose metrics we already have (in thick client) as a first pass
 * Expose metrics Avatica already gives
 * Ability to get metrics into a system for aggregation/query (being able to 
push into hadoop-metrics2 is the easiest one given our ecosystem)

> 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.14.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