[
https://issues.apache.org/jira/browse/IGNITE-17354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-17354:
------------------------------------
Description:
*Metrics types*
Metrics framework should provide the following metrics types:
- Gauge - is an instantaneous measurement of a value provided by some existing
component. Gauge should support primitive types: int, long, double
- Metric - is just a wrapper on a numeric value which could be increased or
decreased to some value. Metric should support primitive types: int, long,
double.
- Hit Rate - accumulates approximate hit rate statistics based on hits in the
last time interval.
- Distribution - distributes values by buckets where each bucket represent some
numeric interval (Histogram in AI 2). Internal type - primitive long (should be
enough).
*Concurrency characteristics*
For scalar numeric metrics it is enough to have atomic number (e.g.
AtomicInteger) and striped number (e.g. LongAdder). Such approaches affects
memory footprint and performance differently.
*Design*
Metrics should have the same life cycle as well as component that produces
these metrics. So metrics related to some particular component should be tied
together in MetricsSet. the only purpose of metrics set is provide access to
metrics values from exporters. Metrics instances itself placed in MetricsSource
- an entity which keeps instances of metrics and provides access to the metrics
through an interface that is specific for each metrics source. A component that
produces metrics must control metrics source life cycle (create it and register
in metrics registry, see below).
All metrics sources (it is not important, enabled or disabled metrics for
particular metrics source) must be registered in metrics registry on component
start and removed on component stop.
MetricsSource itself produces an instance of MetricsSet which should be
registered in metrics registry on event "metrics enabled" and unregistered on
event "metrics disabled".
Metrics registry provide an access to all metrics sets from exporters side.
It is possible that metrics registry is overloaded by functionality (manage by
metrics sources and metrics sets), so, probably, special component is need for
these purposes (e.g. metrics manager).
Each instance of metric has a name (local in some metric set) and description.
So the full metric name it is a concatenation of metrics source name and metric
name separated by dot.
For composite metrics like distribution we should treat each metrics inside
(e.g. each range) as separate metric. So the full name for each internal metric
will be metrics source + dot + metric instance name + dot + range as string
(e.g. 0_100).
Metrics set must be immutable in order to meet the requirements described in
the epic.
Data structure (likely map) that is responsible for keeping enabled metrics set
should be modified using copy-on-write semantics in order to avoid data races
between main functionality (metrics enabling\disabling) and exporters.
was:
POC for metrics framework is here:
[https://github.com/apache/ignite-3/tree/metrics]
It is needed to be finished. There should be implemented:
- metric registry
- metric manager
- metric sources
- classes for metric types (existing + hit rate + histogram/bucket)
> Metrics framework
> ------------------
>
> Key: IGNITE-17354
> URL: https://issues.apache.org/jira/browse/IGNITE-17354
> Project: Ignite
> Issue Type: New Feature
> Reporter: Denis Chudov
> Priority: Major
> Labels: ignite-3
>
> *Metrics types*
> Metrics framework should provide the following metrics types:
> - Gauge - is an instantaneous measurement of a value provided by some
> existing component. Gauge should support primitive types: int, long, double
> - Metric - is just a wrapper on a numeric value which could be increased or
> decreased to some value. Metric should support primitive types: int, long,
> double.
> - Hit Rate - accumulates approximate hit rate statistics based on hits in the
> last time interval.
> - Distribution - distributes values by buckets where each bucket represent
> some numeric interval (Histogram in AI 2). Internal type - primitive long
> (should be enough).
> *Concurrency characteristics*
> For scalar numeric metrics it is enough to have atomic number (e.g.
> AtomicInteger) and striped number (e.g. LongAdder). Such approaches affects
> memory footprint and performance differently.
> *Design*
> Metrics should have the same life cycle as well as component that produces
> these metrics. So metrics related to some particular component should be tied
> together in MetricsSet. the only purpose of metrics set is provide access to
> metrics values from exporters. Metrics instances itself placed in
> MetricsSource - an entity which keeps instances of metrics and provides
> access to the metrics through an interface that is specific for each metrics
> source. A component that produces metrics must control metrics source life
> cycle (create it and register in metrics registry, see below).
> All metrics sources (it is not important, enabled or disabled metrics for
> particular metrics source) must be registered in metrics registry on
> component start and removed on component stop.
> MetricsSource itself produces an instance of MetricsSet which should be
> registered in metrics registry on event "metrics enabled" and unregistered on
> event "metrics disabled".
> Metrics registry provide an access to all metrics sets from exporters side.
> It is possible that metrics registry is overloaded by functionality (manage
> by metrics sources and metrics sets), so, probably, special component is need
> for these purposes (e.g. metrics manager).
> Each instance of metric has a name (local in some metric set) and
> description. So the full metric name it is a concatenation of metrics source
> name and metric name separated by dot.
> For composite metrics like distribution we should treat each metrics inside
> (e.g. each range) as separate metric. So the full name for each internal
> metric will be metrics source + dot + metric instance name + dot + range as
> string (e.g. 0_100).
> Metrics set must be immutable in order to meet the requirements described in
> the epic.
> Data structure (likely map) that is responsible for keeping enabled metrics
> set should be modified using copy-on-write semantics in order to avoid data
> races between main functionality (metrics enabling\disabling) and exporters.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
