OpenTelemetry tracing of Dbus calls

Umut Tezduyar Lindskog umut at tezduyar.com
Wed Jan 11 11:11:18 UTC 2023


On Wed, Jan 11, 2023 at 12:03 PM Thomas Kluyver <thomas at kluyver.me.uk>
wrote:

> Hi Umut,
>
> On Wed, 11 Jan 2023, at 10:09, Umut Tezduyar Lindskog wrote:
>
> 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.
>
>
> And are these services things that your organisation defines, or code
> written elsewhere? Or a mixture? How practical would it be to add tracing
> information to method call arguments, without any change to D-Bus itself?
> I'm not saying that's what you should do, just getting the shape of the
> problem.
>

This is something I have considered but it would be nice to avoid API
changes.


>
> 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.
>
>
> From my perspective it's conceptually interesting, but I've never tried to
> use OpenTelemetry or anything similar to that; I only know the vague idea.
> I'm hoping other people will chime in, though.
>
> I think you might be facing a kind of cultural barrier. The
> cloud/microservices world that I imagine you're coming from probably has
> far more sophisticated tracing and monitoring tools than the desktop Linux
> world that created D-Bus. Even with D-Bus, I don't think we have anything
> like as much need to follow things from one process to another.
>

Absolutely true. Different worlds.


>
> 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.
>
>
> Is there a specific reason you suggest a file descriptor? It would need
> spec changes and client library changes either way, there's extra
> complexity involved in sending & receiving FDs, and it's not always
> possible - e.g. D-Bus can be used on Windows, even though its main use
> cases are on Linux. So I'd assume a solution that adds simple data in the
> messages would be preferred to one using an FD.
>

Honestly I think I have written it as what options we have as a downstream
patch. You are right that this would also need a spec change.

Thanks


>
> Best wishes,
> Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dbus/attachments/20230111/6eb3e141/attachment.htm>


More information about the dbus mailing list