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, Николай Ижиков <nizhi...@apache.org>: > Ticket to export MetricRegistry to the public API created - > https://issues.apache.org/jira/browse/IGNITE-12552 > > > 16 янв. 2020 г., в 16:58, Николай Ижиков <nizhikov....@gmail.com> > написал(а): > > > > Do you propose to keep these interfaces forever? > > > >> 16 янв. 2020 г., в 16:52, Alexey Goncharuk <alexey.goncha...@gmail.com> > написал(а): > >> > >> 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, Николай Ижиков <nizhi...@apache.org>: > >> > >>> 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 < > alexey.goncha...@gmail.com> > >>> написал(а): > >>>> > >>>> 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 > >>> > >>> > > > >
