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