[prev in list] [next in list] [prev in thread] [next in thread]
List: freedesktop-dbus
Subject: Re: OpenTelemetry tracing of Dbus calls
From: "Thomas Kluyver" <thomas () kluyver ! me ! uk>
Date: 2023-01-11 11:03:29
Message-ID: 5b8281dd-150c-40e1-8da9-72911b8b2078 () app ! fastmail ! com
[Download RAW message or body]
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.
> 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.
> 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.
Best wishes,
Thomas
[Attachment #3 (text/html)]
<!DOCTYPE html><html><head><title></title><style \
type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><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="qt" style=""><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><br></div><blockquote type="cite" id="qt" \
style=""><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><br></div><blockquote \
type="cite" id="qt" style=""><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><br></div><div>Best \
wishes,<br></div><div>Thomas<br></div></body></html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic