Hi Nikolay, Thank you for clarifications.
> What is "disabled" sensor? Why do we need it? (as long as sensort is just a > AtomicLong) I meant a possibility of disabling a particular metric value calculation (skipping AtomicLong.incrementAndGet call). My current understanding that we do NOT need it. It seems that we are on a same page. And how do you find named parameters approach mentioned before? cache.my-cahe.GetLatency={ intervals: [50, 100, 250, 500] } пн, 1 июл. 2019 г. в 16:08, Nikolay Izhikov <nizhi...@apache.org>: > > 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 <nizhi...@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 <nizhi...@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 > > > > > > > > > > > -- Best regards, Ivan Pavlukhin