Re: OpenTelemetry tracing of Dbus calls
Umut Tezduyar Lindskog <umut-v3uyoVUDKFtWk0Htik3J/[email protected]> Wed, 11 Jan 2023 12:11:18 +0100
| Newsgroups | gmane.comp.freedesktop.dbus |
|---|---|
| Message-ID | <CAFKnvs7jUy2zDp9ybyiU7emSJHSY7Tfb36DW1q5cDarQbZ0=1Q@mail.gmail.com> |
On Wed, Jan 11, 2023 at 12:03 PM Thomas Kluyver <[email protected]> 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 >