IGNITE-21156 : [IEP-114] Custom metrics introduction - IgniteMetricRegistry

[Vladsz83]

Thank you for submitting the pull request to the Apache Ignite.

In order to streamline the review of the contribution
we ask you to ensure the following steps have been taken:

The Contribution Checklist

• There is a single JIRA ticket related to the pull request.
• The web-link to the pull request is attached to the JIRA ticket.
• The JIRA ticket has the Patch Available state.
• The pull request body describes changes that have been made.
  The description explains WHAT and WHY was made instead of HOW.
• The pull request title is treated as the final commit message.
  The following pattern must be used: IGNITE-XXXX Change summary where XXXX - number of JIRA issue.
• A reviewer has been mentioned through the JIRA comments
  (see the Maintainers list)
• The pull request has been checked by the Teamcity Bot and
  the green visa attached to the JIRA ticket (see TC.Bot: Check PR)

Notes

• How to Contribute
• Coding abbreviation rules
• Coding Guidelines
• Apache Ignite Teamcity Bot

If you need any help, please email [email protected] or ask anу advice on http://asf.slack.com #ignite channel.

[nizhikov]

Maybe we should use "user provided metrics" or "user metrics" instead of "custom"?

[nizhikov]

I doubt about naming here - IgniteMetricRegistry is something that belongs to Ignite.
But, here it used for registry that will be managed and fullfillled by the user.

maybe we can use just MetricRegistry here.
And rename internal implementation to MetricRegistryImpl?

[nizhikov]

@Vladsz83 Let's decide on this suggestion before proceed with the merge.

[Vladsz83]

We've discussed remaning internal MetricRegistry -> MetricRegistryImpl here : https://github.com/apache/ignite/pull/11216/files . Also, we tried to temporary keep two internal and external interfaces MetricRegistry to avoid related tons of code cnahges : https://github.com/apache/ignite/pull/11221/files . The decision was that twe need more exposed, available for internal usage metric interfaces, internal code remenings and code cleanup before using 'MetricRegistry'. Since we declare the interface as @IgniteExperimental, we could rename it later.

[Vladsz83]

Also, we plan to expose internal read-only metrics as noted before using the same API, findRegistry(String name). They belong to Ignite.

[nizhikov]

Also, we plan to expose internal read-only metrics as noted before using the same API

Then method must return ReadOnlyMetricRegistry.

to avoid related tons of code cnahges

I don't think "tons of changes" is the right reason to use bad naming.
Let's make API more clear by using clear naming.

[Vladsz83]

Then method must return ReadOnlyMetricRegistry.

Yes, but not IgniteReadOnlyMetricRegistry. Ok, I'll try to rename and make use MetricRegistry (not MetricRegistryImpl) as much as possible

[Vladsz83]

Ok, I prepared another PR with the renaming internal class MetricRegistry -> class MetricRegistryImpl and new interface IgniteMetricRegistry -> interface MetricRegistry : https://github.com/apache/ignite/pull/11293/files .
Used MetricRegistry instead of MetricRegistryImpl where is possible. We planned to add methods like longMetric to the new registry interface in a next PR. Then, we could refactor to more internal usage of interface MetricRegistry.

I recalled one problem that we discussed: CdcConsumer. It is @IgniteExperimental but also a public API. And this feature look crucial. It uses internal org.apache.ignite.internal.processors.metric.MetricRegistry. Renaming to MetricRegistryImpl will break at least the extensions. And any external code which uses CdcConsumer and probably related org.apache.ignite.internal.processors.metric.MetricRegistry (CdcConsumer#start(MetricRegistry mreg)). IMHO, keeping @IgniteExperimental IgniteMetricRegistry for a while and possible later renaming to @IgniteExperimental MetricRegistry is a less evil. WDYT?

[nizhikov]

@Vladsz83 Thanks for the updates. Overall looks good. Let's agree on naming - I left some suggestions in PR.

[Vladsz83]

Maybe we should use "user provided metrics" or "user metrics" instead of "custom"?

@nizhikov where exactly? Other famous databases operate with 'custom metrics'.

[nizhikov]

where exactly?

In comments, method naming, etc.

Other famous databases operate with 'custom metrics'.

Can you, please, provide an example?

[Vladsz83]

where exactly?

In comments, method naming, etc.

Other famous databases operate with 'custom metrics'.

Can you, please, provide an example?

You can take the examples from the IEP within 'Motivation' section: https://cwiki.apache.org/confluence/display/IGNITE/IEP-114+Custom+metrics#IEP114Custommetrics-Motivation

[nizhikov]

I see - so "custom metric" is commonly used naming. OK, let's keep it.