Motivation

It is useful for user to work with own metrics, not only with provided by Ignite. Current public metrics API doesn't expose any method to add or delete additional metrics.

The most important reason to provide custom is probably the convenience of collecting of desired metrics using one platform, the same client, through the same API. This feature can simplify user application.

Famous databases with custom metrics: Oracle DB , Postgres , Oracle Coherence , MS SQL Server , IBM DB2

Examples of custom metric usages:

• Some metrics may not be provided yet and user registers own.
• Metrics for load balancing.
• Custom conflict resolver successes/fails.
• Various metrics of business processes or related to user application.
• Administration metrics.
• Security-related metrics.

Implementation proposal

1. Custom Metrics based on the New Metric System.
2. Allow to register essential ready-to-use metrics like LongMetric which can be exported by a providing metric exporter.
3. User can add own metrics into different registries.
4. Custom metrics are separated from the internals by registry name prefix "custom." (lower cased). 
5. Management of custom metrics might require a permission.

Risks and Assumptions

• Custom metrics affect performance and take additional resources.
• There could be race conditions on metric registrations. Metrics with incompatible types can be concurrently registered with the same names.
• We do not expose API of all internal metrics. At least with the first tickets.
• Custom metrics aren't stored and require re-registration after node restart. At least with the first tickets.

API

APIs description

To give an user the ability to register additional metrics, we could either:

• Refactor a bit our current metrics. Create interfaces for writable metric registry, metric manager. Create interfaces for metrics like int, double, long, longAdder, boolean, object and the gauge metrics (IntGauge, LongGauge, etc.).
• Provide tiny-enough facade with consumers and suppliers for int, long, double value metrics.

These two approaches are shown below.

The APIs are supposed to be experimental.

Obtaining Custom Metrics

package org.apache.ignite;

public interface Ignite {

    IgniteMetrics metrics();

}

Proposed APIs: Interfaces for existing metrics

IgniteMetric

package org.apache.ignite.metric;

public interface IgniteMetrics extends Iterable<ReadOnlyMetricRegistry> {

    MetricRegistry customRegistry(String registryName);

    @Nullable ReadOnlyMetricRegistry findRegistry(String registryName);

     void removeCustomRegistry(String registryName);
}

IgniteMetricRegistry

package org.apache.ignite.metric;

public interface MetricRegistry extends ReadOnlyMetricRegistry {
    IntMetric register(String name, IntSupplier supplier, @Nullable String desc);
    LongMetric register(String name, LongSupplier supplier, @Nullable String desc);
    DoubleMetric register(String name, DoubleSupplier supplier, @Nullable String desc);
    <T> ObjectMetric<T> register(String name, Supplier<T> supplier, Class<T> type, @Nullable String desc);
    BooleanMetric register(String name, BooleanSupplier supplier, @Nullable String desc);

    IntValueMetric intMetric(String name, @Nullable String desc);
    LongValueMetric longMetric(String name, @Nullable String desc);
    LongSumMetric longAdderMetric(String name, @Nullable String desc);
    DoubleValueMetric doubleMetric(String name, @Nullable String desc);
    <T> ObjectValueMetric<T> objectMetric(String name, Class<T> type, @Nullable String desc);
    void remove(String name);
    void reset();
}

Updatable metric interfaces list

To the package "org.apache.ignite.metric" we add:

• BooleanValueMetric
• IntValueMetric
• LongValueMetric
• LongSumMetric (a long adder)
• DoubleValueMetric
• ObjectValueMetric<T> (an object metric)

Names like "LongMetric" or "ObjectMetric" we already have in the package "org.apache.ignite.spi.metric".

Examples of updatable metrics

package org.apache.ignite.metric;

public interface ObjectValueMetric<T> extends ObjectMetric<T> {
    void value(T value);
}

public interface DoubleValueMetric extends DoubleMetric {
    void add(double value);
    void value(double value);
}

public interface LongSumMetric extends LongMetric {
    void add(long value);
    void increment();
    void decrement();
}

public interface LongValueMetric extends LongSumMetric {
    void value(long value);
}

API alternative: single minimal facade

Instead of the interfeces set above, we could bring only a minimal metric management interface.

package org.apache.ignite;

public interface IgniteMetrics extends Iterable<ReadOnlyMetricRegistry> {

    LongConsumer longMetric(String registryName, String metricName, @Nullable String description);
    DoubleConsumer doubleMetric(String registryName, String metricName, @Nullable String description);
    IntConsumer booleanMetric(String registryName, String metricName, @Nullable String description);
    void longMetric(String registryName, String metricName, LongSupplier supplier, @Nullable String description);
    void doubleMetric(String registryName, String metricName, DoubleSupplier supplier, @Nullable String description);
    void intMetric(String registryName, String metricName, BooleanSupplier supplier, @Nullable String description);
    void removeCustomMetric(String registryName, String metricName);
    void removeCustomRegistry(String registryName);
    @Nullable ReadOnlyMetricRegistry findRegistry(String registryName);
}

Code examples

Further Steps

We already have implementations of more complex and useful metrics. We could also store custom metrics. Thus, the development stages might be:

1. An API to expose internals read-only internal metrics was already suggested. Might be joined with the custom metrics. By the methods like "findRegistry" we can return also read-only internal metrics.
2. Extending the initial API with more complex metrics like Histogram or HitRate.
3. Introduce a permission for custom metric management.
4. Storing registered custom metrics.
5. Allowing to change settings of configurable custom metrics like histograms.

References

1. IEP-35 Monitoring & Profiling
2. New Metric System
3. Ticket of a public metric API
4. IEP-116 : Ignite 3 metric

Discussion Links

Tickets