[
https://issues.apache.org/jira/browse/IGNITE-17354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-17354:
-----------------------------------------
Fix Version/s: 3.0.0-alpha6
> Metrics framework
> ------------------
>
> Key: IGNITE-17354
> URL: https://issues.apache.org/jira/browse/IGNITE-17354
> Project: Ignite
> Issue Type: New Feature
> Reporter: Denis Chudov
> Assignee: Denis Chudov
> Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
>
> *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)
