<!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>