Ivan, Some notes about your comments:
> 1. Specifying subset of metrics which are exported to an external system. I believe there are no any subset if metrics except of metrics related with one particular source. Also I think that there is no need to filter out metrics set on export stage. If some metrics is enabled it must be exported. Nevertheless, there are filters that can solve this problem. > 2. Subset of metrics which is collected (enable/disable sensor). The same that mentioned above. All metrics enabled/disabled per metrics source (e.g. cache). Current configuration facilities are enough. > 3. A particular metric (sensor) parameters It seems that it is redundant functionality. All or nothing metrics per source looks reasonable. > 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? Good question! It looks very odd for me too. The reason why we need such configurations is using absolute values for buckets instead of percentile. But percentiles are more expensive and less accurate in calculation (see Dropwizard Metrics implementation for example [1]). Otherhand, we have OpenCensus example with distribution aggregations [2]. 1 - https://github.com/dropwizard/metrics/blob/4.1-development/metrics-core/src/main/java/com/codahale/metrics/Histogram.java 2 - https://opencensus.io/stats/view/#1 On Mon, Jul 1, 2019 at 3:39 PM Павлухин Иван <vololo...@gmail.com> wrote: > > 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
