opentelemetry-specification

opentelemetry-specification copied to clipboard

Changes

Adds a new metric, process.threads.count, to the process metrics available.

Related issues https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/12482

Changelog updated, thanks!

Here is a bit I'll present tomorrow at the spec meeting: I believe process.threads is a finite metric, and will not be used as a namespace. An other namespace, under thread.*, should be created if we ever standardize data under a thread. This is because listening to thread activity would typically be done via a different type of monitor than a monitor for processes. For threads, we would use instrumentation in-process, such as jmx, to listen to thread activity.

@jmacd are you proposing process.runtime.thread.count?

I feel that this semantic convention belongs in the process.runtime.* section. In Go, for example, there is no "thread" concept and we already have a runtime-metrics count of goroutines.

I think the fact that Golang and Node.js don't have thread is a good reason why this shouldn't be part of process.runtime.*. I feel threads is an operating system concept. Although there are indeed operating systems that don't have threads, it seems pretty common to park it under OS and process.

@jmacd are you proposing process.runtime.thread.count?

process.runtime.thread.count might have a different semantic.

I'll take .NET as an example, process.thread.count could mean "how many threads does this process have (from the operating system's point of view)", while process.runtime.thread.count could mean "how many managed threads (and a better name might be process.runtime.dotnet.managed_threads because it's explicit and it doesn't make much sense to maintain the same name between .NET and Java - to avoid accidental join/merge) does the .NET runtime inside this process have" (and there could be a more complex situation where multiple instances of runtime coexist, although I've never seen that in reality except for some SQL stored procedure hosting).

I agree with @reyang - as said on Slack:

the process.runtime namespace does not allow to set a threads entry in it, since it is supposed to process.runtime.{environment} as per spec: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/semantic_conventions/runtime-environment-metrics.md Second, the number of threads is the number of threads exposed at the OS level, not the level of threads or goroutines as experienced inside the program. That's the difference say between looking at Java threads and the number of threads in top -H -p <pid>.

@jmacd and anyone - any insights or follow up?

Let's discuss it on today's call (with whoever can make it) - hopefully we can merge this (either with minor renaming or not) today ;)

I feel that this semantic convention belongs in the process.runtime.* section. In Go, for example, there is no "thread" concept and we already have a runtime-metrics count of goroutines.

Inside the go VM indeed cannot read threads, from outside you can actually read the number of OS threads for the go process.

What is the next step here?

@jmacd Do you have a strong instance against going with process.threads? This was briefly discussed in the past Spec call, and the Golang case was deemed as a very-specific case compared to the rest of the languages, when it comes to this item, so we could deem it as a special case (Python also has coroutines, but it also has threads - that is the closest IIRC).