Add semantic conventions for thread.name and thread.id span attributes

[mateuszrzeszutek]

What are you trying to achieve?

Currently there's no semantic convention for adding executing thread info as span attributes. My proposition is to add two new general span attributes that may store the executing thread's id and name:

Attribute name	Notes and examples
thread.id	Current thread id, if exposed by the platform. E.g. 42
thread.name	Current thread name. E.g. main

Additional context.

This change is mostly motivated by the Java world, but I believe that it's a language agnostic concept that may also be present in other languages, e.g.:

• Python has both threading.current_thread().ident and threading.current_thread().name
• Ruby can provide info about name Thread.current.name
• In C# you can use Thread.CurrentThread.ManagedThreadId and Thread.CurrentThread.Name

Also, see related issue: open-telemetry/opentelemetry-java-instrumentation#942

[anuraaga]

Thanks for filing! Thread name seems like it could be quite useful, for example debugging latency issues caused by blocking event loop threads. Thread ID seems like it'd be very random though, for example, if the app restarts, the same ID could be doing something totally different I believe. Do you have a concrete example of using thread ID in a backend?

[iNikem]

Thread id can be useful in those cases where several threads have the same name due to badly configured thread pool.

[Oberon00]

A SpanProcessor that adds the thread info in OnStart could also be added.

[Oberon00]

Note that there can be multiple IDs for the same thread. The "mangaged" thread ID, the OS thread ID (Linux LWP#), sometimes an additional thread ID (like what pthread_self() returns). Probably the managed thread ID is the most interesting, as it is also the most deterministic (often starts at 1 and increments by 1 for every thread the runtime starts), while the OS thread ID can be semi-random or increment across all processes.