Idiomatic way to implement a desktop app heartbeat

[riverar]

Previously asked at https://github.com/open-telemetry/community/discussions/1598

Is there a documented pattern or generally accepted method of implementing a heartbeat in a desktop application? That is, a periodic message send to a collector for the purpose of determining an active session count? Or perhaps a general pattern of reporting back Boolean states?

I was going down the path of using a Counter with a 0|1 value and just letting that contact a Collector periodically, but wanted to double-check.

My notes thus far:

• Metrics reader can be configured non-cumulative for fire once https://github.com/open-telemetry/opentelemetry-dotnet/issues/2524

• On-going work related to establishing conventions for service uptime https://github.com/open-telemetry/oteps/pull/185

Prior art:

• Microsoft App Insights Live Metrics https://azure.microsoft.com/en-us/blog/live-metrics-stream/

[jsuereth]

We're looking at kicking off a working group around self-observability of our SDKs/APIs. I think a general health check / heartbeat recommendations should go along with that.

WDYT @carlosalberto @yurishkuro ? cc @reyang

[yurishkuro]

Not seeing a strong motivation for SDK heartbeat. If SDK produces a metric indicating how much data it exports, that is equivalent to a heartbeat.

On the other hand, this issue seems to be about the application's heartbeat, not the SDKs. Either way, the motivation is not clear to me. I am assuming this is all independent of a health check endpoint an application may provide.

[jsuereth]

My question was whether, as part of SDK self-o11y health, we provide general health metric support.

[joaopgrassi]

This was closed by mistake by the stale bot. Re-opening

[decko]

There is some place where the discussion about this feature is happening right now?