Date: Mon, 2 Jan 2017 14:00:29 -0800 From: Mark Johnston <markj@FreeBSD.org> To: Domagoj Stolfa <domagoj.stolfa@gmail.com> Cc: freebsd-dtrace@freebsd.org Subject: Re: RFC: Changes in DTrace to allow for distributed operation Message-ID: <20170102220029.GC46812@wkstn-mjohnston.west.isilon.com> In-Reply-To: <20161230173747.GB46006@freebsd-laptop> References: <20161230173747.GB46006@freebsd-laptop>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Dec 30, 2016 at 06:37:47PM +0100, Domagoj Stolfa wrote: > Hello, > > I have been working on extending DTrace to allow for a natural way of tracing in > a distributed environment. This would consist of being able to trace events on > different virtual machines, remote servers with access, cluster nodes and so on. > I will summarize the changes I have made and have thought of making, outly all > the design tradeoffs, flaws and merits of each design tradeoff I have thought of > making in hopes of getting feedback from others interested in distributed > tracing. I think some concrete examples of what you'd like to be able to accomplish with this would help a lot. Is the goal here to be able to trace multiple independent systems at once and somehow aggregate their trace records? That's what "distributed tracing" suggests to me, but from reading your email it seems as though you're primarily interested in some form of remote tracing whereby one could execute something like # dtrace -n 'fbt$guest::kern_ioctl:entry' on a hypervisor and get records (in real time?) from a guest. Assuming I'm not completely off-base, this is a cool idea, but I think your objective needs to be more clearly defined before it's possible to evaluate the merits of different designs, especially when you're proposing adding new concepts to the core DTrace code.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170102220029.GC46812>