Re: OpenTelemetry tracing of Dbus calls

Thanks for your email Thomas.

We have around 40-50 dbus services which are the backends to http APIs. A
backend might talk to other backends. We can easily trace the HTTP APIs but
it would also be nice to add the dbus layer tracing to the overall picture.

I think it is important to understand the dbus community's interest in
OpenTelemetry. If the community is not interested then we can think about a
downstream solution. But ideally we like to contribute.

One other way that I can think of is a dedicated FD which carries the
context data. This, of course, also needs changes in the client libraries.

Umut

On Tue, Jan 10, 2023 at 12:35 PM Thomas Kluyver <[email protected]>
wrote:

> On Mon, 9 Jan 2023, at 10:28, Umut Tezduyar Lindskog wrote:
>
> Can the tracing/context data be sent over the dbus message header, granted
> this needs to be supported by the dbus client libraries?
>
>
> D-Bus has a 'header fields' array, but it doesn't allow non-standard
> headers, so to add a new field you'd need to propose a change to the spec.
> There are only 9 fields defined so far, in contrast to the dozens of
> standardised header fields for HTTP, and those 9 are all kind of integral
> to using D-Bus - there's no general metadata like the HTTP Date or Server
> headers. So I might guess this would be a tough sell, though it's not up to
> me.
>
> Have you come across specific scenarios where something you're tracing is
> using D-Bus messages and you want to follow them? Perhaps starting from a
> concrete example would make prompt more discussion than the abstract
> approach.
>
> Best wishes,
> Thomas
>