Hello, thanks for the response, excuse the late reply here got a bit busy over the holidays.
On Wednesday, January 4, 2017 at 2:22:36 AM UTC-7, Dmitry Vyukov wrote: > > Streaming stacks and strings sounds fine to me. I don't see any > potential issues here. > Awesome, I think this alone would add some cool possibilities for tooling since you can get a lot of information from stack & event data alone. The other thing is timing- I am curious if there is anyway to emit the frequency occasionally- say the start of the batch, or some other method? I'm still not sure how timing works exactly I was having trouble getting the timing information from a 1.5 event normalized to a 1.7, the request may make no sense all together but if there was a way to be able to make a best-guess at timing information from purely look behind state that would be nice as well. > Streaming data in real time (not waiting for an internal buffer to be > full) is somewhat more problematic, but probably doable. > Now that I understand more about the trace internals, particularly how it batches and is tied to the buffer I understand how this could be difficult. Real time may be an overreach, perhaps we could send a new batch every 250ms for programs we can determine are not very busy with a simple heuristic of some sort. That would help for programs that are not doing much work while you debug them, since you could see the very few events that are happening very close to the time they occur giving some additional sensory to what's happening in your application. Stable public format is problematic. The format proven to be unstable > over the last releases. However maybe we could just expose parser for > each version without particular guarantees. > I've noticed it's had some changes, the biggest being 1.5 -> 1.7 but other than that I found it wasn't too bad to normalize past events to the latest format. Using the trace code and go tool as reference I was able to write a basic Encoder/Decoder https://github.com/cstockton/go-trace/tree/master/encoding I feel like it wasn't too difficult of an exercise, but I also didn't do the hardest part (all the post processing and "consistency" stuff in the "order.go" state machine.). The changes thus far have been made in a way that I think you can bring forward prior version events to begin correlation on a single structured event aside from the timing which I mentioned above (which I think is just my expertise lacking rather than a technical challenge?). > If you want anything from this to happen, the first step would be to > file an issue at http://golang.org/issue/new > I filed one last night https://github.com/golang/go/issues/18744, thanks again for the response -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
