How can I measure io.Connect Desktop startup time?
For ongoing data collection, particularly when trying to distinguish healthy versus unhealthy platform behavior, OTEL metrics are the preferred path. This data is exposed by io.Connect Desktop as OTEL metrics.
To use this approach, use the platform_startup metric from io.Insights . In system.json, ensure that OTEL and metrics are enabled and defaultMetricsEnabled is set to true. The standard resource attributes service.name (e.g., “io.Connect Desktop”) and service.instance.id should be included.
What backend infrastructure is needed for OTEL metrics?
The prerequisites are:
-
An instance of the OTEL collector
-
A metrics backend for example Prometheus, Datadog or other you are may be using at your company already
-
Optionally, a visualization/querying front end such as Grafana - useful for advanced queries, dashboards, and reports.
Configure in system.json:
"otel": {
"enabled": true,
"metrics": {
"enabled": true,
"url": "http://localhost:4318/metrics"
}
}
Smoke Test
After configuring, run io.Connect Desktop and verify that the platform startup metric appears in your metrics backend. If data appears, the setup is correct and the next step is to replicate it in your enterprise infrastructure (Kubernetes, etc.).
How do I get live memory and CPU usage at runtime?
Live memory/CPU usage at runtime can be obtained in two ways, depending on what you need.
If you need to read the values programmatically inside an io.Connect app, use the T42.Telemetry Interop method. In order to use it you must have telemetry enabled in system.json. Check out the documentation here: Telemetry Data
If you need to export runtime CPU/memory metrics to an observability stack, use io.Insights (OTEL) instead. It can publish the default OpenTelemetry metrics system_cpu, system_memory, app_cpu, and app_memory
What is the performance impact of enabling telemetry?
The telemetry module is lightweight and runs in the background. From experience, the performance impact is negligible as long as the polling frequency is not excessive (polling every few seconds is generally safe). High-frequency polling (multiple times per second) may slightly increase CPU load.