You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by Mikhail Petrov <pm...@gmail.com> on 2026/07/09 12:54:53 UTC
[Ignite 2] [DISCUSSION] Retiring the Ignite Tracing
Igniters,
I would like to initiate a discussion on the deprecation and removal of
Ignite 2 Tracing.
*Motivation*
Ignite Tracing was introduced to provide distributed tracing
capabilities for Apache Ignite. However, over time several issues have
become apparent:
1. Ignite Tracing is based on OpenCensus, which has been deprecated and
is no longer maintained. [1]
2. The implementation has never reached production readiness. It is
difficult to configure and, in some scenarios, introduces significant
performance overhead.
3. The tracing implementation handles asynchronous Ignite operations
poorly, making the resulting traces difficult to interpret.
4. It is tightly coupled with the Communication and Discovery
subsystems, increasing their complexity and making maintenance and
refactoring more difficult.
5. Ignite Tracing has not received active maintenance for more than
three years.
Before proceeding with removal, I would like to ask whether anyone is
aware of production deployments or real-world users who rely on Ignite
Tracing.
Such feedback would help us better assess the impact of its removal.
*Alternatives*
Apache Ignite already provides several actively maintained mechanisms
for monitoring:
1. Ignite Performance Statistics [2] [3]
2. Ignite Metric System [4]
3. Ignite System Views [5]
The aforementioned mechanisms are actively maintained and serve as the
primary means of monitoring Ignite.
Regards,
Mikhail.
[1] https://opentelemetry.io/blog/2023/sunsetting-opencensus
[2]
https://ignite.apache.org/docs/ignite2/latest/monitoring-metrics/performance-statistics
[3]
https://ignite.apache.org/docs/ignite2/latest/extensions-and-integrations/performance-statistics#print-statistics
[4]
https://ignite.apache.org/docs/ignite2/latest/monitoring-metrics/new-metrics-system
[5]
https://ignite.apache.org/docs/ignite2/latest/monitoring-metrics/system-views
Re: [Ignite 2] [DISCUSSION] Retiring the Ignite Tracing
Posted by Vladislav Pyatkov <vl...@gmail.com>.
Nikolay,
> Do you know any real world usages of Ignite tracing?
I know it was, but I cannot get a real use case right now because for a
long time I haven't supported a long-lived Ignite 2 service.
But I can bring a case to the table: I wanted to have the instrument when I
work on performance:
1. Tones of similar operation have a latency lag for some period of time.
2. You cannot debug it because the issue happens after 5-10 minutes of
loading.
3. Logging in is also useless because there are distributed operations.
In this case tracing can trace one of 100K operations in the load stream.
It shouldn't affect the load muck and show a correct trace.
> Moreover, Ignite is an OLTP primary system and you can't trace any
> specific operation, because in a regular cluster thousands or even
> millions of operations run each second.
If we talk about client scenarios, I see it like this:
1. The client starts a cluster with a trace that never traces any op.
2. If some measurements show that the load is stuck or latency
dramatically increases for some ops. The client configured a filter for
trace (by labe, by ration, by operation type, etc.).
3. After a day they analyze the captured traces.
I do not see a reason why it is not possible for OLTP system. The main
purpose is to minimize losses when the tracer is not tracing.
On Thu, Jul 9, 2026 at 5:23 PM Nikolay Izhikov <ni...@apache.org> wrote:
> Hello, Vladislav.
>
> Thanks for the second opinion.
>
> Do you know any real world usages of Ignite tracing?
>
> > Tracing is a functionality that lets users evaluate in real time why an
> operation takes longer.
>
> Don't think any user has such a question.
> Moreover, Ignite is an OLTP primary system and you can't trace any
> specific operation, because in a regular cluster thousands or even
> millions of operations run each second.
>
>
> чт, 9 июл. 2026 г. в 16:23, Vladislav Pyatkov <vl...@gmail.com>:
> >
> > Hi,
> >
> > Although all the points are true, the features (metrics, statistics)
> provided in Ignite are not a replacement for tracing. Tracing is a
> functionality that lets users evaluate in real time why an operation takes
> longer. The current implementation may not be the best, but I am convinced
> that the real reason is that it has not been maintained for a long time.
> > What I mean is not that we should keep the OpenCensus API, but that we
> need to plan how to implement new tracing, because there is no real
> substitute for it in Ignite.
> >
> > Vladislav Pyatkov
> >
> > On Thu, Jul 9, 2026, 3:55 PM Mikhail Petrov <pm...@gmail.com>
> wrote:
> >>
> >> Igniters,
> >>
> >> I would like to initiate a discussion on the deprecation and removal of
> Ignite 2 Tracing.
> >>
> >> Motivation
> >>
> >> Ignite Tracing was introduced to provide distributed tracing
> capabilities for Apache Ignite. However, over time several issues have
> become apparent:
> >>
> >> 1. Ignite Tracing is based on OpenCensus, which has been deprecated and
> is no longer maintained. [1]
> >> 2. The implementation has never reached production readiness. It is
> difficult to configure and, in some scenarios, introduces significant
> performance overhead.
> >> 3. The tracing implementation handles asynchronous Ignite operations
> poorly, making the resulting traces difficult to interpret.
> >> 4. It is tightly coupled with the Communication and Discovery
> subsystems, increasing their complexity and making maintenance and
> refactoring more difficult.
> >> 5. Ignite Tracing has not received active maintenance for more than
> three years.
> >>
> >> Before proceeding with removal, I would like to ask whether anyone is
> aware of production deployments or real-world users who rely on Ignite
> Tracing.
> >> Such feedback would help us better assess the impact of its removal.
> >>
> >>
> >> Alternatives
> >>
> >> Apache Ignite already provides several actively maintained mechanisms
> for monitoring:
> >>
> >> 1. Ignite Performance Statistics [2] [3]
> >> 2. Ignite Metric System [4]
> >> 3. Ignite System Views [5]
> >>
> >> The aforementioned mechanisms are actively maintained and serve as the
> primary means of monitoring Ignite.
> >>
> >> Regards,
> >> Mikhail.
> >>
> >> [1] https://opentelemetry.io/blog/2023/sunsetting-opencensus
> >> [2]
> https://ignite.apache.org/docs/ignite2/latest/monitoring-metrics/performance-statistics
> >> [3]
> https://ignite.apache.org/docs/ignite2/latest/extensions-and-integrations/performance-statistics#print-statistics
> >> [4]
> https://ignite.apache.org/docs/ignite2/latest/monitoring-metrics/new-metrics-system
> >> [5]
> https://ignite.apache.org/docs/ignite2/latest/monitoring-metrics/system-views
> >>
> >>
> >>
> >>
>
--
Vladislav Pyatkov
Re: [Ignite 2] [DISCUSSION] Retiring the Ignite Tracing
Posted by Humphrey Lopez <hm...@gmail.com>.
Nevermind, I managed to get the example working
https://ignite.apache.org/docs/ignite2/latest/monitoring-metrics/tracing#enabling-trace-sampling
with spring boot 4.1.0 for transaction.
It would be great if the documentation gets updated on how to setup
(register) the Tracing Bridge to OLTP (GlobalOpenTelemetry) to export
ignite tracing to a system like the grafana-lgtm stack (
https://grafana.com/docs/opentelemetry/docker-lgtm/)
I've created a lifecycle bean to instruct ignite tracing after the node
start:
@Component
class IgniteLifecycleBean : LifecycleBean {
@IgniteInstanceResource
private lateinit var ignite: Ignite
override fun onLifecycleEvent(evt: LifecycleEventType) {
if (evt == LifecycleEventType.AFTER_NODE_START) {
afterNodeStart()
}
}
private fun afterNodeStart() {
ignite.tracingConfiguration().set(TracingConfigurationCoordinates.Builder(Scope.TX).build(),
TracingConfigurationParameters.Builder().withSamplingRate(1.0).build())
}
}
I've configured the lifecycle bean in my config and register the
GlobalOpenTelemetry:
@Configuration
class IgniteConfig {
@Bean
fun ignite(openTelemetry: OpenTelemetry, lifecycleBeans:
List<IgniteLifecycleBean>): IgniteSpringBean {
registerGlobalOpenTelemetry(openTelemetry)
val ignite = IgniteSpringBean().apply {
configuration = IgniteConfiguration().apply {
igniteInstanceName = "my-ignite-instance"
igniteHome = Paths.get(".").toAbsolutePath().toString()
gridLogger = Slf4jLogger()
metricsLogFrequency = 0
tracingSpi = OpenCensusTracingSpi()
discoverySpi = TcpDiscoverySpi().apply {
localAddress = "127.0.0.1"
localPort = 47500
localPortRange = 20
ipFinder = TcpDiscoveryVmIpFinder().apply {
setAddresses(listOf("127.0.0.1:47500..47520"))
}
}
communicationSpi = TcpCommunicationSpi()
setLifecycleBeans(*lifecycleBeans.toTypedArray())
}
}
return ignite
}
private fun registerGlobalOpenTelemetry(openTelemetry: OpenTelemetry) {
if (!GlobalOpenTelemetry.isSet()) {
GlobalOpenTelemetry.set(openTelemetry)
}
}
}
I've used these dependency:
plugins {
kotlin("jvm") version "2.4.10"
kotlin("plugin.spring") version "2.4.10"
id("org.springframework.boot") version "4.1.0"
id("io.spring.dependency-management") version "1.1.7"
}
ext["opentelemetry.version"] = "1.64.0"
val igniteVersion = "2.18.0"
dependencies {
implementation("org.springframework.boot:spring-boot-starter-opentelemetry")
implementation("org.springframework.boot:spring-boot-starter-webmvc")
implementation("org.jetbrains.kotlin:kotlin-reflect")
implementation("tools.jackson.module:jackson-module-kotlin")
implementation("io.opentelemetry.instrumentation:opentelemetry-logback-appender-1.0:2.29.0-alpha")
implementation("io.opentelemetry:opentelemetry-exporter-otlp")
implementation("io.opentelemetry:opentelemetry-opencensus-shim:1.64.0-alpha")
implementation("io.micrometer:micrometer-tracing-bridge-otel")
implementation("org.apache.ignite:ignite-spring:$igniteVersion")
implementation("org.apache.ignite:ignite-slf4j:$igniteVersion")
implementation("org.apache.ignite:ignite-opencensus:$igniteVersion")
developmentOnly("org.springframework.boot:spring-boot-docker-compose")
testImplementation("org.springframework.boot:spring-boot-starter-opentelemetry-test")
testImplementation("org.springframework.boot:spring-boot-starter-webmvc-test")
testImplementation("org.jetbrains.kotlin:kotlin-test-junit5")
testRuntimeOnly("org.junit.platform:junit-platform-launcher")
}
And somewhere in my code it is invoking:
private val cacheConfiguration = CacheConfiguration<Int,
String>().apply {
name = "MyCache"
atomicityMode = CacheAtomicityMode.TRANSACTIONAL
}
fun transaction(): String {
val cache = ignite.getOrCreateCache(cacheConfiguration)
val transactions = ignite.transactions()
transactions.txStart().use {
cache.put(1, "test value")
logger.info(cache.get(1))
cache.put(1, "second value")
it.commit()
}
return "transaction successful"
}
Op di 21 jul 2026 om 22:43 schreef Humphrey Lopez <hm...@gmail.com>:
> I was going to ask how can I setup tracing in Ignite. We are using
> readThrough cache that calls another endpoint over HTTP. It would be nice
> to be able to follow a request. As Monitoring tool we have grafana LGTM
> that collects OLTP metrics and tracing and logging for the spring boot app.
> I would like to configure apache ignite tracing to also export to those
> endpoints for LGTM, but I don't know how to achieve that.
> We are using an embedded Ignite (in memory only) 2.18.0 with spring boot
> 4.1.0 (ignite-spring). Spring boot metrics are already sent and visual in
> grafana, but I would like to see the Ignite spans as well.
> Anyone know how to configure that? Ignite comes with OpenCenus but I need
> opentelemetry OLTP.
> There is a opencencus-shim
> https://github.com/open-telemetry/opentelemetry-java/tree/main/opencensus-shim
> But I have no idea what I need to configure in ignite or spring to get it
> working.
> Any help on that would be appreciated.
>
> Humphrey
>
>
>
> Op do 9 jul 2026 om 16:23 schreef Nikolay Izhikov <ni...@apache.org>:
>
>> Hello, Vladislav.
>>
>> Thanks for the second opinion.
>>
>> Do you know any real world usages of Ignite tracing?
>>
>> > Tracing is a functionality that lets users evaluate in real time why an
>> operation takes longer.
>>
>> Don't think any user has such a question.
>> Moreover, Ignite is an OLTP primary system and you can't trace any
>> specific operation, because in a regular cluster thousands or even
>> millions of operations run each second.
>>
>>
>> чт, 9 июл. 2026 г. в 16:23, Vladislav Pyatkov <vl...@gmail.com>:
>> >
>> > Hi,
>> >
>> > Although all the points are true, the features (metrics, statistics)
>> provided in Ignite are not a replacement for tracing. Tracing is a
>> functionality that lets users evaluate in real time why an operation takes
>> longer. The current implementation may not be the best, but I am convinced
>> that the real reason is that it has not been maintained for a long time.
>> > What I mean is not that we should keep the OpenCensus API, but that we
>> need to plan how to implement new tracing, because there is no real
>> substitute for it in Ignite.
>> >
>> > Vladislav Pyatkov
>> >
>> > On Thu, Jul 9, 2026, 3:55 PM Mikhail Petrov <pm...@gmail.com>
>> wrote:
>> >>
>> >> Igniters,
>> >>
>> >> I would like to initiate a discussion on the deprecation and removal
>> of Ignite 2 Tracing.
>> >>
>> >> Motivation
>> >>
>> >> Ignite Tracing was introduced to provide distributed tracing
>> capabilities for Apache Ignite. However, over time several issues have
>> become apparent:
>> >>
>> >> 1. Ignite Tracing is based on OpenCensus, which has been deprecated
>> and is no longer maintained. [1]
>> >> 2. The implementation has never reached production readiness. It is
>> difficult to configure and, in some scenarios, introduces significant
>> performance overhead.
>> >> 3. The tracing implementation handles asynchronous Ignite operations
>> poorly, making the resulting traces difficult to interpret.
>> >> 4. It is tightly coupled with the Communication and Discovery
>> subsystems, increasing their complexity and making maintenance and
>> refactoring more difficult.
>> >> 5. Ignite Tracing has not received active maintenance for more than
>> three years.
>> >>
>> >> Before proceeding with removal, I would like to ask whether anyone is
>> aware of production deployments or real-world users who rely on Ignite
>> Tracing.
>> >> Such feedback would help us better assess the impact of its removal.
>> >>
>> >>
>> >> Alternatives
>> >>
>> >> Apache Ignite already provides several actively maintained mechanisms
>> for monitoring:
>> >>
>> >> 1. Ignite Performance Statistics [2] [3]
>> >> 2. Ignite Metric System [4]
>> >> 3. Ignite System Views [5]
>> >>
>> >> The aforementioned mechanisms are actively maintained and serve as the
>> primary means of monitoring Ignite.
>> >>
>> >> Regards,
>> >> Mikhail.
>> >>
>> >> [1] https://opentelemetry.io/blog/2023/sunsetting-opencensus
>> >> [2]
>> https://ignite.apache.org/docs/ignite2/latest/monitoring-metrics/performance-statistics
>> >> [3]
>> https://ignite.apache.org/docs/ignite2/latest/extensions-and-integrations/performance-statistics#print-statistics
>> >> [4]
>> https://ignite.apache.org/docs/ignite2/latest/monitoring-metrics/new-metrics-system
>> >> [5]
>> https://ignite.apache.org/docs/ignite2/latest/monitoring-metrics/system-views
>> >>
>> >>
>> >>
>> >>
>>
>
Re: [Ignite 2] [DISCUSSION] Retiring the Ignite Tracing
Posted by Humphrey Lopez <hm...@gmail.com>.
I was going to ask how can I setup tracing in Ignite. We are using
readThrough cache that calls another endpoint over HTTP. It would be nice
to be able to follow a request. As Monitoring tool we have grafana LGTM
that collects OLTP metrics and tracing and logging for the spring boot app.
I would like to configure apache ignite tracing to also export to those
endpoints for LGTM, but I don't know how to achieve that.
We are using an embedded Ignite (in memory only) 2.18.0 with spring boot
4.1.0 (ignite-spring). Spring boot metrics are already sent and visual in
grafana, but I would like to see the Ignite spans as well.
Anyone know how to configure that? Ignite comes with OpenCenus but I need
opentelemetry OLTP.
There is a opencencus-shim
https://github.com/open-telemetry/opentelemetry-java/tree/main/opencensus-shim
But I have no idea what I need to configure in ignite or spring to get it
working.
Any help on that would be appreciated.
Humphrey
Op do 9 jul 2026 om 16:23 schreef Nikolay Izhikov <ni...@apache.org>:
> Hello, Vladislav.
>
> Thanks for the second opinion.
>
> Do you know any real world usages of Ignite tracing?
>
> > Tracing is a functionality that lets users evaluate in real time why an
> operation takes longer.
>
> Don't think any user has such a question.
> Moreover, Ignite is an OLTP primary system and you can't trace any
> specific operation, because in a regular cluster thousands or even
> millions of operations run each second.
>
>
> чт, 9 июл. 2026 г. в 16:23, Vladislav Pyatkov <vl...@gmail.com>:
> >
> > Hi,
> >
> > Although all the points are true, the features (metrics, statistics)
> provided in Ignite are not a replacement for tracing. Tracing is a
> functionality that lets users evaluate in real time why an operation takes
> longer. The current implementation may not be the best, but I am convinced
> that the real reason is that it has not been maintained for a long time.
> > What I mean is not that we should keep the OpenCensus API, but that we
> need to plan how to implement new tracing, because there is no real
> substitute for it in Ignite.
> >
> > Vladislav Pyatkov
> >
> > On Thu, Jul 9, 2026, 3:55 PM Mikhail Petrov <pm...@gmail.com>
> wrote:
> >>
> >> Igniters,
> >>
> >> I would like to initiate a discussion on the deprecation and removal of
> Ignite 2 Tracing.
> >>
> >> Motivation
> >>
> >> Ignite Tracing was introduced to provide distributed tracing
> capabilities for Apache Ignite. However, over time several issues have
> become apparent:
> >>
> >> 1. Ignite Tracing is based on OpenCensus, which has been deprecated and
> is no longer maintained. [1]
> >> 2. The implementation has never reached production readiness. It is
> difficult to configure and, in some scenarios, introduces significant
> performance overhead.
> >> 3. The tracing implementation handles asynchronous Ignite operations
> poorly, making the resulting traces difficult to interpret.
> >> 4. It is tightly coupled with the Communication and Discovery
> subsystems, increasing their complexity and making maintenance and
> refactoring more difficult.
> >> 5. Ignite Tracing has not received active maintenance for more than
> three years.
> >>
> >> Before proceeding with removal, I would like to ask whether anyone is
> aware of production deployments or real-world users who rely on Ignite
> Tracing.
> >> Such feedback would help us better assess the impact of its removal.
> >>
> >>
> >> Alternatives
> >>
> >> Apache Ignite already provides several actively maintained mechanisms
> for monitoring:
> >>
> >> 1. Ignite Performance Statistics [2] [3]
> >> 2. Ignite Metric System [4]
> >> 3. Ignite System Views [5]
> >>
> >> The aforementioned mechanisms are actively maintained and serve as the
> primary means of monitoring Ignite.
> >>
> >> Regards,
> >> Mikhail.
> >>
> >> [1] https://opentelemetry.io/blog/2023/sunsetting-opencensus
> >> [2]
> https://ignite.apache.org/docs/ignite2/latest/monitoring-metrics/performance-statistics
> >> [3]
> https://ignite.apache.org/docs/ignite2/latest/extensions-and-integrations/performance-statistics#print-statistics
> >> [4]
> https://ignite.apache.org/docs/ignite2/latest/monitoring-metrics/new-metrics-system
> >> [5]
> https://ignite.apache.org/docs/ignite2/latest/monitoring-metrics/system-views
> >>
> >>
> >>
> >>
>
Re: [Ignite 2] [DISCUSSION] Retiring the Ignite Tracing
Posted by Nikolay Izhikov <ni...@apache.org>.
Hello, Vladislav.
Thanks for the second opinion.
Do you know any real world usages of Ignite tracing?
> Tracing is a functionality that lets users evaluate in real time why an operation takes longer.
Don't think any user has such a question.
Moreover, Ignite is an OLTP primary system and you can't trace any
specific operation, because in a regular cluster thousands or even
millions of operations run each second.
чт, 9 июл. 2026 г. в 16:23, Vladislav Pyatkov <vl...@gmail.com>:
>
> Hi,
>
> Although all the points are true, the features (metrics, statistics) provided in Ignite are not a replacement for tracing. Tracing is a functionality that lets users evaluate in real time why an operation takes longer. The current implementation may not be the best, but I am convinced that the real reason is that it has not been maintained for a long time.
> What I mean is not that we should keep the OpenCensus API, but that we need to plan how to implement new tracing, because there is no real substitute for it in Ignite.
>
> Vladislav Pyatkov
>
> On Thu, Jul 9, 2026, 3:55 PM Mikhail Petrov <pm...@gmail.com> wrote:
>>
>> Igniters,
>>
>> I would like to initiate a discussion on the deprecation and removal of Ignite 2 Tracing.
>>
>> Motivation
>>
>> Ignite Tracing was introduced to provide distributed tracing capabilities for Apache Ignite. However, over time several issues have become apparent:
>>
>> 1. Ignite Tracing is based on OpenCensus, which has been deprecated and is no longer maintained. [1]
>> 2. The implementation has never reached production readiness. It is difficult to configure and, in some scenarios, introduces significant performance overhead.
>> 3. The tracing implementation handles asynchronous Ignite operations poorly, making the resulting traces difficult to interpret.
>> 4. It is tightly coupled with the Communication and Discovery subsystems, increasing their complexity and making maintenance and refactoring more difficult.
>> 5. Ignite Tracing has not received active maintenance for more than three years.
>>
>> Before proceeding with removal, I would like to ask whether anyone is aware of production deployments or real-world users who rely on Ignite Tracing.
>> Such feedback would help us better assess the impact of its removal.
>>
>>
>> Alternatives
>>
>> Apache Ignite already provides several actively maintained mechanisms for monitoring:
>>
>> 1. Ignite Performance Statistics [2] [3]
>> 2. Ignite Metric System [4]
>> 3. Ignite System Views [5]
>>
>> The aforementioned mechanisms are actively maintained and serve as the primary means of monitoring Ignite.
>>
>> Regards,
>> Mikhail.
>>
>> [1] https://opentelemetry.io/blog/2023/sunsetting-opencensus
>> [2] https://ignite.apache.org/docs/ignite2/latest/monitoring-metrics/performance-statistics
>> [3] https://ignite.apache.org/docs/ignite2/latest/extensions-and-integrations/performance-statistics#print-statistics
>> [4] https://ignite.apache.org/docs/ignite2/latest/monitoring-metrics/new-metrics-system
>> [5] https://ignite.apache.org/docs/ignite2/latest/monitoring-metrics/system-views
>>
>>
>>
>>
Re: [Ignite 2] [DISCUSSION] Retiring the Ignite Tracing
Posted by Vladislav Pyatkov <vl...@gmail.com>.
Hi,
Although all the points are true, the features (metrics, statistics)
provided in Ignite are not a replacement for tracing. Tracing is a
functionality that lets users evaluate in real time why an operation takes
longer. The current implementation may not be the best, but I am convinced
that the real reason is that it has not been maintained for a long time.
What I mean is not that we should keep the OpenCensus API, but that we need
to plan how to implement new tracing, because there is no real substitute
for it in Ignite.
Vladislav Pyatkov
On Thu, Jul 9, 2026, 3:55 PM Mikhail Petrov <pm...@gmail.com> wrote:
> Igniters,
>
> I would like to initiate a discussion on the deprecation and removal of
> Ignite 2 Tracing.
>
> *Motivation*
>
> Ignite Tracing was introduced to provide distributed tracing capabilities
> for Apache Ignite. However, over time several issues have become apparent:
>
> 1. Ignite Tracing is based on OpenCensus, which has been deprecated and is
> no longer maintained. [1]
> 2. The implementation has never reached production readiness. It is
> difficult to configure and, in some scenarios, introduces significant
> performance overhead.
> 3. The tracing implementation handles asynchronous Ignite operations
> poorly, making the resulting traces difficult to interpret.
> 4. It is tightly coupled with the Communication and Discovery subsystems,
> increasing their complexity and making maintenance and refactoring more
> difficult.
> 5. Ignite Tracing has not received active maintenance for more than three
> years.
>
> Before proceeding with removal, I would like to ask whether anyone is
> aware of production deployments or real-world users who rely on Ignite
> Tracing.
> Such feedback would help us better assess the impact of its removal.
>
>
> *Alternatives*
>
> Apache Ignite already provides several actively maintained mechanisms for
> monitoring:
>
> 1. Ignite Performance Statistics [2] [3]
> 2. Ignite Metric System [4]
> 3. Ignite System Views [5]
>
> The aforementioned mechanisms are actively maintained and serve as the
> primary means of monitoring Ignite.
>
> Regards,
> Mikhail.
>
> [1] https://opentelemetry.io/blog/2023/sunsetting-opencensus
> [2]
> https://ignite.apache.org/docs/ignite2/latest/monitoring-metrics/performance-statistics
> [3]
> https://ignite.apache.org/docs/ignite2/latest/extensions-and-integrations/performance-statistics#print-statistics
> [4]
> https://ignite.apache.org/docs/ignite2/latest/monitoring-metrics/new-metrics-system
> [5]
> https://ignite.apache.org/docs/ignite2/latest/monitoring-metrics/system-views
>
>
>
>
>