ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikolay Izhikov <nizhi...@apache.org>
Subject Re: Fwd: [DISCUSSION][IEP-35] Metrics configuration
Date Mon, 01 Jul 2019 13:11:06 GMT
Hello, Ivan.

Thanks for the feedback!

> 1. Specifying subset of metrics which are exported to an external system.

Covered by exporter filter [1]

> 2. Subset of metrics which is collected (enable/disable sensor).

What is "disabled" sensor?
Why do we need it? (as long as sensort is just a AtomicLong)

> 3. A particular metric (sensor) parameters.

This is the point of the discussed ticket [2]


[1] https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/metric/PushMetricsExporterAdapter.java#L41
[2] https://issues.apache.org/jira/browse/IGNITE-11927


В Пн, 01/07/2019 в 15:39 +0300, Павлухин Иван пишет:
> Nikolay, Igniters,
> 
> In my mind there are several configuration aspects:
> 1. Specifying subset of metrics which are exported to an external system.
> 2. Subset of metrics which is collected (enable/disable sensor).
> 3. A particular metric (sensor) parameters.
> 
> Are we going to address all points in the same config (file)? In my
> experience with metrics (actually not so rich) I have not seen metric
> configs similar to logging configs. Are there examples of such
> practice in industry?
> 
> Also, looking at a line like "cache.my-cahe.GetLatency=50,100,250,500"
> I cannot tell much from scratch. My first thought is that having named
> parameters can be more readable, e.g. (roughly):
> cache.my-cahe.GetLatency={
>   intervals: [50, 100, 250, 500]
> }
> 
> пт, 28 июн. 2019 г. в 13:02, Nikolay Izhikov <nizhikov@apache.org>:
> > 
> > Hello, Alexey.
> > 
> > Thanks for the feedback!
> > 
> > > My only concert is that we should have the metrics framework configuration
> > > as the first-citizen of the framework itself
> > 
> > Yes. I planned to add `void configure(String param)` method to the metric API.
> > 
> > > but change the metrics parameters in
> > > runtime from JMX or command-line, etc.
> > 
> > I've add requirement of JMX method to the ticket:
> > 
> > https://issues.apache.org/jira/browse/IGNITE-11927
> > 
> > > Another concern is to have an
> > > ability to disable/enable metrics per metrics group/prefix.
> > 
> > Yes, we discusss it.
> > But, let's make it clear:
> > 
> > *What is disabling metric?*
> > 
> > Looks like exporter filter solve this task.
> > 
> > В Чт, 27/06/2019 в 16:24 +0300, Alexey Goncharuk пишет:
> > > Nikolay,
> > > 
> > > My only concert is that we should have the metrics framework configuration
> > > as the first-citizen of the framework itself. This way, we can configure
> > > the metrics not only from file, but change the metrics parameters in
> > > runtime from JMX or command-line, etc. Another concern is to have an
> > > ability to disable/enable metrics per metrics group/prefix.
> > > 
> > > The logger-like configuration meets these suggestions given that the
> > > configuration is generalized into the metrics framework.
> > > 
> > > What do you think?
> > > 
> > > чт, 27 июн. 2019 г. в 12:30, Nikolay Izhikov <nizhikov@apache.org>:
> > > 
> > > > Hello, Igniters.
> > > > 
> > > > As you may know, I've contributed Phase1 [1] for IEP-35 [2].
> > > > Now we have metrics subsystem and can create and export any metrics from
> > > > Ignite.
> > > > 
> > > > I think user(administrator of Ignite) should be able to configure some
> > > > metrics params in a common way [3]
> > > > 
> > > > I propose to use the same way from logging frameworks.
> > > > We should define some file format Ignite can understand.
> > > > An administrator fills configuration file to configure one or several
> > > > metrics.
> > > > Ignite will analyze the file and use provided params during metrics
> > > > creation.
> > > > 
> > > > For now, we have 2 types of metrics that should be configured:
> > > > 
> > > >         *       HistrogramMetric [4]
> > > >                 This metric is a count of measurement that falls into
> > > > predefined intervals.
> > > >                 An example is "Request processing time distribution".
> > > >                 We want to calculate a count of requests processed quicker
> > > > then 50ms, 50-100, 100-250, 250-500 and slower.
> > > > 
> > > >         *       HitRateMetric [5]
> > > >                 This metric is a count of events in the last time interval.
> > > >                 An example is the "Count of requests processed in the
last
> > > > 5 seconds".
> > > > 
> > > > Example of file content:
> > > > 
> > > > ````
> > > > cache.my-cahe.GetLatency=50,100,250,500 #Params for the histogram metric
> > > > with the name `cache.my-cahe.get`
> > > > cache.my-cache.RebalancingKeysRate=60000 #Param for existing HitRateMetric
> > > > that hold "Estimated rebalancing speed in keys".
> > > > ````
> > > > 
> > > > Please, share your vision.
> > > > 
> > > > [1]
> > > > https://github.com/apache/ignite/commit/fdaa310430aefff07994eb35510d3416886b5bbe
> > > > [2]
> > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=112820392
> > > > [3] https://issues.apache.org/jira/browse/IGNITE-11927
> > > > [4]
> > > > https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/metric/impl/HistogramMetric.java
> > > > [5]
> > > > https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/metric/impl/HitRateMetric.java
> > > > 
> 
> 
> 

Mime
View raw message