[
https://issues.apache.org/jira/browse/IGNITE-29222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Egor Baranov updated IGNITE-29222:
----------------------------------
Description:
*Summary:* Add ClientsAddedToTopology monitoring metric to track client node
topology join events
h2.Problem Statement
Currently, Apache Ignite does not provide a built-in monitoring metric that
tracks the cumulative number of client nodes added to the cluster topology.
Operators who need to monitor client connection activity (e.g., for capacity
planning, detecting unexpected churn, or correlating application-level issues
with topology changes) must rely on log parsing of the
{code}GridDiscoveryManager{code} output, which is unreliable at scale and not
amenable to automated alerting.
h2.Proposed Solution
Introduce a new thread-safe counter metric, {code}ClientsAddedToTopology{code},
registered in the existing discovery metrics registry
({code}io.discovery{code}). The metric is incremented on each of the following
topology events:
# A new client node joins the topology ({code}EVT_NODE_JOINED{code} where the
joining node is a client).
# A disconnected client node reconnects to the topology
({code}EVT_CLIENT_NODE_RECONNECTED{code}).
The counter is implemented using {code}LongAdderMetric{code} (backed by
{code}java.util.concurrent.atomic.LongAdder{code}), ensuring lock-free,
thread-independent increments even under high-frequency client
connection/disconnection workloads.
h2.Metric Details
{table}
|*Property*|*Value*
|Registry|{code}io.discovery{code}
|Metric Name|{code}ClientsAddedToTopology{code}
|Type|Long (counter, monotonically increasing)
|Description|Count of client nodes added to topology
|JMX Access|Via {code}JmxMetricExporterSpi{code} (default)
{table}
h2.Acceptance Criteria
# The metric is exposed via the standard Ignite metrics API
({code}Ignite.context().metric().registry("io.discovery"){code}).
# The metric is accessible via JMX (MBean) without additional configuration.
# The counter is thread-safe and does not introduce measurable contention under
concurrent client join/reconnect events.
# Unit tests verify:
## The metric starts at 0 on a fresh node.
## The metric increments by 1 per client node join.
## The metric name and description are correctly registered.
# The test class is registered in the {code}IgniteKernalSelfTestSuite{code}.
# The implementation follows the existing project style and conventions for
metric registration.
h2.Affected Components
# {code}GridDiscoveryManager{code} (core) — metric initialization and increment
logic
# {code}IgniteKernalSelfTestSuite{code} (test) — new test class registration
# {code}GridDiscoveryManagerClientMetricTest{code} (test) — new test class
h2.Performance Impact
None. The counter uses {code}LongAdder{code} which provides O(1) amortized
increments with no global lock. The metric is created during node startup and
adds one additional entry to the existing {code}io.discovery{code} metric
registry.
was:
Problem Statement
Currently, Apache Ignite does not provide a built-in monitoring metric that
tracks the cumulative number of client nodes added to the cluster
topology. Operators who need to monitor client connection activity (e.g.,
for capacity planning, detecting unexpected churn, or correlating
application-level issues with topology changes) must rely on log parsing of
the GridDiscoveryManager output, which is unreliable at scale and not
amenable to automated alerting.
Proposed Solution
Introduce a new thread-safe counter metric, ClientsAddedToTopology,
registered in the existing discovery metrics registry (io.discovery). The
metric is incremented on each of the following topology events:
1. A new client node joins the topology (EVT_NODE_JOINED where the joining
node is a client).
2. A disconnected client node reconnects to the topology
(EVT_CLIENT_NODE_RECONNECTED).
The counter is implemented using LongAdderMetric (backed by
java.util.concurrent.atomic.LongAdder), ensuring lock-free, thread-independent
increments even under high-frequency client connection/disconnection
workloads.
Metric Details
┌─────────────────┬────────────────────────────────────────────────────────┐
│ Property │ Value │
├─────────────────┼────────────────────────────────────────────────────────┤
│ Registry │ io.discovery │
│ Metric Name │ ClientsAddedToTopology │
│ Type │ Long (counter, monotonically increasing) │
│ Description │ Count of client nodes added to topology │
│ JMX Object Name │ Type=Discovery, IGNITE_HOME=..., IgniteInstance=<name> │
└─────────────────┴────────────────────────────────────────────────────────┘
Acceptance Criteria
- [x] The metric is exposed via the standard Ignite metrics API
(Ignite.context().metric().registry("io.discovery")).
- [x] The metric is accessible via JMX (MBean) without additional
configuration.
- [x] The counter is thread-safe and does not introduce measurable
contention under concurrent client join/reconnect events.
- [x] Unit tests verify:
- The metric starts at 0 on a fresh node.
- The metric increments by 1 per client node join.
- The metric increments by 1 per client node reconnect.
- The metric name and description are correctly registered.
- [x] The test class is registered in the IgniteKernalSelfTestSuite.
- [x] The implementation follows the existing project style and
conventions for metric registration.
Affected Components
- GridDiscoveryManager (core) — metric initialization and increment logic
- IgniteKernalSelfTestSuite (test) — new test class registration
- GridDiscoveryManagerClientMetricTest (test) — new test class
Performance Impact
None. The counter uses LongAdder which provides O(1) amortized increments
with no global lock. The metric is lazily created during node startup and
adds one additional entry to the existing io.discovery metric registry.
> Add ClientsAddedToTopology monitoring metric to track client node topology
> join events
> --------------------------------------------------------------------------------------
>
> Key: IGNITE-29222
> URL: https://issues.apache.org/jira/browse/IGNITE-29222
> Project: Ignite
> Issue Type: New Feature
> Affects Versions: 2.19
> Reporter: Egor Baranov
> Assignee: Egor Baranov
> Priority: Major
>
> *Summary:* Add ClientsAddedToTopology monitoring metric to track client node
> topology join events
> h2.Problem Statement
> Currently, Apache Ignite does not provide a built-in monitoring metric that
> tracks the cumulative number of client nodes added to the cluster topology.
> Operators who need to monitor client connection activity (e.g., for capacity
> planning, detecting unexpected churn, or correlating application-level issues
> with topology changes) must rely on log parsing of the
> {code}GridDiscoveryManager{code} output, which is unreliable at scale and not
> amenable to automated alerting.
> h2.Proposed Solution
> Introduce a new thread-safe counter metric,
> {code}ClientsAddedToTopology{code}, registered in the existing discovery
> metrics registry ({code}io.discovery{code}). The metric is incremented on
> each of the following topology events:
> # A new client node joins the topology ({code}EVT_NODE_JOINED{code} where the
> joining node is a client).
> # A disconnected client node reconnects to the topology
> ({code}EVT_CLIENT_NODE_RECONNECTED{code}).
> The counter is implemented using {code}LongAdderMetric{code} (backed by
> {code}java.util.concurrent.atomic.LongAdder{code}), ensuring lock-free,
> thread-independent increments even under high-frequency client
> connection/disconnection workloads.
> h2.Metric Details
> {table}
> |*Property*|*Value*
> |Registry|{code}io.discovery{code}
> |Metric Name|{code}ClientsAddedToTopology{code}
> |Type|Long (counter, monotonically increasing)
> |Description|Count of client nodes added to topology
> |JMX Access|Via {code}JmxMetricExporterSpi{code} (default)
> {table}
> h2.Acceptance Criteria
> # The metric is exposed via the standard Ignite metrics API
> ({code}Ignite.context().metric().registry("io.discovery"){code}).
> # The metric is accessible via JMX (MBean) without additional configuration.
> # The counter is thread-safe and does not introduce measurable contention
> under concurrent client join/reconnect events.
> # Unit tests verify:
> ## The metric starts at 0 on a fresh node.
> ## The metric increments by 1 per client node join.
> ## The metric name and description are correctly registered.
> # The test class is registered in the {code}IgniteKernalSelfTestSuite{code}.
> # The implementation follows the existing project style and conventions for
> metric registration.
> h2.Affected Components
> # {code}GridDiscoveryManager{code} (core) — metric initialization and
> increment logic
> # {code}IgniteKernalSelfTestSuite{code} (test) — new test class registration
> # {code}GridDiscoveryManagerClientMetricTest{code} (test) — new test class
> h2.Performance Impact
> None. The counter uses {code}LongAdder{code} which provides O(1) amortized
> increments with no global lock. The metric is created during node startup and
> adds one additional entry to the existing {code}io.discovery{code} metric
> registry.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
