[prev in list] [next in list] [prev in thread] [next in thread]
List: freedesktop-dbus
Subject: Re: OpenTelemetry tracing of Dbus calls
From: Umut Tezduyar Lindskog <umut () tezduyar ! com>
Date: 2023-01-11 11:11:18
Message-ID: CAFKnvs7jUy2zDp9ybyiU7emSJHSY7Tfb36DW1q5cDarQbZ0=1Q () mail ! gmail ! com
[Download RAW message or body]
On Wed, Jan 11, 2023 at 12:03 PM Thomas Kluyver <thomas@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
>
[Attachment #3 (text/html)]
<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Wed, Jan 11, 2023 at 12:03 PM Thomas Kluyver <<a \
href="mailto:thomas@kluyver.me.uk">thomas@kluyver.me.uk</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div \
class="msg-780499927617653761"><u></u><div><div>Hi \
Umut,<br></div><div><br></div><div>On Wed, 11 Jan 2023, at 10:09, Umut Tezduyar \
Lindskog wrote:<br></div><blockquote type="cite" id="m_-780499927617653761qt"><div \
dir="ltr"><div>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. \
<br></div></div></blockquote><div><br></div><div>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.<br></div></div></div></blockquote><div><br></div><div>This is \
something I have considered but it would be nice to avoid API changes. </div><div> \
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div \
class="msg-780499927617653761"><div><div></div><div><br></div><blockquote type="cite" \
id="m_-780499927617653761qt"><div dir="ltr"><div>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. <br></div></div></blockquote><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div></div></div></blockquote><div><br></div><div>Absolutely true. \
Different worlds. </div><div> </div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div \
class="msg-780499927617653761"><div><div></div><div><br></div><blockquote type="cite" \
id="m_-780499927617653761qt"><div dir="ltr"><div>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. <br></div></div></blockquote><div><br></div><div>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.<br></div></div></div></blockquote><div><br></div><div>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. </div><div><br></div><div>Thanks </div><div> \
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div \
class="msg-780499927617653761"><div><div></div><div><br></div><div>Best \
wishes,<br></div><div>Thomas<br></div></div></div></blockquote></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic