Hello, On Tuesday, January 3, 2017 at 11:19:12 PM UTC-7, Tarmigan wrote: > > Hi Chris, > > I think that the parsing of the runtime trace information like you are > describing is very interesting. I have been thinking about a similar > continuous tracing and automatic anomaly detection for my application, > but have not yet tried to implement anything, so your experience is > helpful. My application has limited connectivity and I am only > interested in anomalous high latencies that occur < 0.01% of the time, > so the existing manual and live-streaming tracing options are not a > good fit for my needs. >
Hi there, I agree with you here that it could be helpful! I particularly think that being able to see file / line / function names of Go routines as the start / stop (or very close to when they do) might be able to help build mental imagery to support trouble shooting. You could technically do this now with a sampling of your data and building graphs / tools that treat the sampling as a real time- but it removes the ability for you to give the program inputs. This approach in some cases may tighten the feedback loop when trying to have a high level understanding before you deep dive into the granular debugging with go tool, pprof, fmt.Println(`WHYISTHISHAPPENING`, myvalue) etc :) > Did you see the "StackImpact" post to gonuts from a few months ago? > Their github repo includes an internal package to parse and filter the > trace format. You could also see how they handle the traceEvStack > issue (I have not looked myself). > I just looked, I did see a internal package but it appears to be a copy of the same parser from the go tool. They may have a different one somewhere I didn't see though? > Online parsing, filtering, and analyzing the trace output seems like a > common desire and enhancement to the standard pprof/trace > functionality (which is great itself). At least 3 of us want to use > the runtime trace output without having to manually run a trace and > define start and stop points for the trace. Cool, well I published the work I did do in another thread, it's not complete or of the same quality you will find in standard library but it does have a bunch of documentation inline and a couple commands that filter/grep events that may give ya some ideas to play with. Thanks for the reply. -- 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.
