[
https://issues.apache.org/jira/browse/PHOENIX-6174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xinyi Yan updated PHOENIX-6174:
-------------------------------
Fix Version/s: 4.17.0
4.16.1
> Phoenix Metrics Initial Unification
> -----------------------------------
>
> Key: PHOENIX-6174
> URL: https://issues.apache.org/jira/browse/PHOENIX-6174
> Project: Phoenix
> Issue Type: Improvement
> Affects Versions: 5.1.0, 4.x
> Reporter: Daniel Wong
> Priority: Major
> Fix For: 4.16.1, 4.17.0
>
>
> I see this as an incremental improvement toward a larger more powerful
> metrics framework in phoenix-server, phoenix-client, and phoenix-connectors.
> Today we describe our available metrics as
> https://phoenix.apache.org/metrics.html
> Long term a tag based multi-dimensional data model (similar to
> prometheus/open tsdb) may be superior but for now this targets simple
> generalization of the existing metrics in phoenix. Today much of the metrics
> are built on hbase/hadoop offering.
>
> Some initial discussion/brainstorming:
> Metric Types:
> Phoenix uses/provides sufficient verbosity of metrics, but does not define
> the metric types cleanly. Typical counter, gauge, histogram
>
> Monitoring Models:
> Events (Event Metrics), metrics with no summarization or aggregation.
> Example of this will be request metrics. On this request you used 5
> scanners.
> Metrics (Summary/Aggregated Metrics),
> Example of this might be total queries
> Reporting:
> Today JMX is one of the main approaches used in phoenix for metrics. For
> events most of them are retrievable from PhoenixRuntime. Long term these
> should be pluggable.
>
> Storage:
> End user based on reporting is envisioned.
> May consider storing in HBase/Phoenix as an option? The query log could
> store events with that query log entry.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
