[jira] [Commented] (IGNITE-17354) Metrics framework

["Andrey N. Gura (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IGNITE-17354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17575192#comment-17575192 ] 

Andrey N. Gura commented on IGNITE-17354:
-----------------------------------------

[~Denis Chudov]I've took a look at the PR and left some comments. Could you please fix them?

> 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
>
> *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)