ID | IEP-114 |
Author | |
Sponsor | |
Created | |
Status | DRAFT |
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.
Oracle DB , Postgres , Oracle Coherence , MS SQL Server , IBM DB2
In future, we might want to provide an internal API to obtain metrics like this. It could be quite different and we should split them.
package org.apache.ignite;
public interface Ignite {
public IgniteCustomMetrics metrics();
}
To keep custom metrics detached from the internals, we should either automaticall add a prefix to custom name or throw an exception if provided registry name doesn't start with that prefix.
package org.apache.ignite;
/**
* Manages custom metrics. Metrics have full name and are grouped into registries. Registry name is part of the full metric name until last '.'.
* Metric name is the last part of the full name. Names of custom metrics registers are always prefixed with "custom.".
* For example, if provided full name is "a.b.c.mname", it is automatically converted to "custom.a.b.c.mname".
* If full name is "custom.a.b.c.mname", it is used as is. Where "custom.a.b.c" is the registry name and "mname" is the metric name.
*/
public interface IgniteCustomMetrics {
/**
* Registers metric. Adds new metric registry if absent.
*
* @return Previous metric if it already exists. Otherwise, {@code metric}.
*/
<T extends Metric> T metric(String fullName, T metric);
/** Removes metric. */
void removeMetric(String fullName);
/** @return Certain metric registry. */
ReadOnlyMetricRegistry registry(String registryName);
/** Removes registry named '{@code registryName}' and all its metrics. */
void removeRegistry(String registryName);
// Essential metrics. Int, Long and Double should be enough.
/**
* Registers a {@link LongMetric}. Adds new metric registry if absent.
*
* @return Previous long value setter if it already exists. A new one otherwise.
*/
LongConsumer longMetric(String fullName, @Nullable String description);
/**
* Registers a {@link DoubleMetric}. Adds new metric registry if absent.
*
* @return Previous double value setter if it already exists. A new one otherwise.
*/
DoubleConsumer doubleMetric(String fullName, @Nullable String description);
/**
* Registers a {@link IntMetric}. Adds new metric registry if absent.
*
* @return Previous int value setter if it already exists. A new one otherwise.
*/
IntConsumer booleanMetric(String fullName, @Nullable String description);
// Might be useful the gauges.
/**
* Registers a {@link LongMetric} metric with long value supplier {@code valueSupplier}. Adds new metric registry if absent.
*
* @return {@code True} if metric was added. {@code False} if meric already exists.
*/
boolean longMetric(String fullName, LongSupplier valueSupplier, @Nullable String description);
/**
* Registers a {@link DoubleMetric} metric with double value supplier {@code valueSupplier}. Adds new metric registry if absent.
*
* @return {@code True} if metric was added. {@code False} if meric already exists.
*/
boolean doubleMetric(String fullName, DoubleSupplier valueSupplier, @Nullable String description);
/**
* Registers a {@link IntMetric} metric with int value supplier {@code valueSupplier}.Adds new metric registry if absent.
*
* @return {@code True} if metric was added. {@code False} if meric already exists.
*/
boolean intMetric(String fullName, BooleanSupplier valueSupplier, @Nullable String description);
}
We already have implementations of more complex and useful metrics. We could also store custom metrics. Thus, the development stages might be: