Hello, Pavel.
> there should be an obvious public API to retrieve metrics
What do you mean by «retrieve»?
I don’t create pure Java API for metric intentionally.
We have MetricExporterSPI for this purpose.
It very simple from my point of view.
What use cases for `Ignite.monitoring()` API exists?
```
public interface MetricExporterSpi extends IgniteSpi {
public void setMetricRegistry(ReadOnlyMetricRegistry registry);
public void setExportFilter(Predicate<MetricRegistry> filter);
}
```
```
public interface ReadOnlyMetricRegistry extends Iterable<MetricRegistry> {
public void addMetricRegistryCreationListener(Consumer<MetricRegistry>
lsnr);
public void addMetricRegistryRemoveListener(Consumer<MetricRegistry> lsnr);
}
```
```
public class MetricRegistry implements Iterable<Metric> {
public String name();
@Nullable public <M extends Metric> M findMetric(String name);
}
```
> 16 янв. 2020 г., в 20:32, Pavel Tupitsyn <[email protected]> написал(а):
>
> Agree with Alexey, there should be an obvious public API to retrieve metrics
>
> On Thu, Jan 16, 2020 at 8:23 PM Alexey Goncharuk <[email protected]>
> wrote:
>
>> That's an option, I agree. Yet for me, from the usability point of view, it
>> would be quite strange - to get an instance of the monitoring interface, I
>> would need to do
>> JmxMetricExporterSpi metrics =
>> (JmxMetricExporterSpi)ignite.configuration().getMetricExporterSpi()[0];
>> which is too verbose and fragile if someone changes configuration (say,
>> inserts another SPI to the first position).
>>
>> чт, 16 янв. 2020 г. в 20:14, Николай Ижиков <[email protected]>:
>>
>>> May be we should enable JMX exporter, by default?
>>> This would provide the same value for the user as `IgniteMonitoring` you
>>> propose.
>>>
>>>> 16 янв. 2020 г., в 20:06, Alexey Goncharuk <[email protected]
>>>
>>> написал(а):
>>>>
>>>> I think it would make sense to make something like a new
>> IgniteMonitoring
>>>> facade on Ignite interface and add an ability to obtain a metric value
>>>> through this facade, not through an exporter. This would be a
>>>> straightforward replacement for all old metrics interfaces.
>>>>
>>>> чт, 16 янв. 2020 г. в 17:13, Николай Ижиков <[email protected]>:
>>>>
>>>>> Ticket to export MetricRegistry to the public API created -
>>>>> https://issues.apache.org/jira/browse/IGNITE-12552
>>>>>
>>>>>> 16 янв. 2020 г., в 16:58, Николай Ижиков <[email protected]>
>>>>> написал(а):
>>>>>>
>>>>>> Do you propose to keep these interfaces forever?
>>>>>>
>>>>>>> 16 янв. 2020 г., в 16:52, Alexey Goncharuk <
>>> [email protected]>
>>>>> написал(а):
>>>>>>>
>>>>>>> Let's say I am upgrading from 2.7 to 2.8. Given that I figured out
>> to
>>>>>>> obtain an instance of the JMX exporter SPI, how should I map the old
>>>>>>> 'interface + method name' to the new metric name? I think
>> deprecation
>>> of
>>>>>>> the public API may be a bit harsh in this case.
>>>>>>>
>>>>>>> чт, 16 янв. 2020 г. в 16:44, Николай Ижиков <[email protected]>:
>>>>>>>
>>>>>>>> Hello, Alexey.
>>>>>>>>
>>>>>>>>> * DataRegionMetric public interface is deprecated, however, the
>>>>>>>> suggested replacement class GridMetricsManager is internal and
>> cannot
>>>>> be
>>>>>>>> acquired by a user. This makes impossible for the user to fix their
>>>>> code to
>>>>>>>> not use deprecated API
>>>>>>>>
>>>>>>>> May be it’s not clear text here.
>>>>>>>> My point here, that user should obtain metrics values via
>> configured
>>>>>>>> metric exporters and don’t use *Metric interfaces.
>>>>>>>>
>>>>>>>>> * In ReadOnlyMetricsRegistry there is a Consumer<MetricRegistry>,
>>> but
>>>>>>>> MetricRegistry is again an internal class.
>>>>>>>>
>>>>>>>> This is a real issue.
>>>>>>>> We should expose MetricRegistry interface to the public API and
>> keep
>>>>>>>> internal implementation.
>>>>>>>>
>>>>>>>> I will create ticket and fix it, shortly.
>>>>>>>>
>>>>>>>>
>>>>>>>>> 16 янв. 2020 г., в 16:39, Alexey Goncharuk <
>>>>> [email protected]>
>>>>>>>> написал(а):
>>>>>>>>>
>>>>>>>>> Igniters, Nikolay,
>>>>>>>>>
>>>>>>>>> I was adding a new metric in the scope of the ticket [1] and was
>>>>>>>> surprised by a few things:
>>>>>>>>> * DataRegionMetric public interface is deprecated, however, the
>>>>>>>> suggested replacement class GridMetricsManager is internal and
>> cannot
>>>>> be
>>>>>>>> acquired by a user. This makes impossible for the user to fix their
>>>>> code to
>>>>>>>> not use deprecated API
>>>>>>>>> * In ReadOnlyMetricsRegistry there is a Consumer<MetricRegistry>,
>>> but
>>>>>>>> MetricRegistry is again an internal class. This will cause the user
>>>>> code
>>>>>>>> compilation to break when MetricRegistry is changed
>>>>>>>>>
>>>>>>>>> These things violate the public-private API separation and need to
>>> be
>>>>>>>> fixed prior 2.8 is released. Let's discuss what changes need to be
>>>>> made to
>>>>>>>> the API or perhaps move incomplete IEP-35 interfaces to the private
>>>>> package
>>>>>>>> and remove deprecations until the API is ready.
>>>>>>>>>
>>>>>>>>> --AG
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
