That meeting was about finding common ground in tracing-related needs to determine what can be done to improve the situation for everyone. It was somewhat successful at highlighting those commonalities too.
The issue is not a lack of consistency of tracing needs, but that the tooling to trace async js automatically doesn't exist and would thus require someone stepping up to develop it in the open and lead the community to start using it. TJ Fontaine did a bit of experimentation with node-tracing, and Forrest Norvell made CLS. Trevor Norris had also created AsyncListener to track changes between async contexts. But all the approaches so far have been too naive or simplistic and ultimately flawed. The largest obstacle I've seen to overcoming this is unwillingness or inability to put in the time or resources necessary and to work together to find a proper solution. Companies selling performance monitoring, including the one I work at, are focused on adding value to their own products. Putting significant effort into projects that devalue those is unappealing. Until node APM products shift their core value to something beyond simply collecting and displaying data, those will remain features core to their product and thus often deemed not acceptable for significant open development. The pursuit of competitive advantage can be problematic when it comes to underdeveloped markets such as this. On Nov 11, 2014 4:31 PM, "// ravi" <[email protected]> wrote: > On Nov 11, 2014, at 5:59 PM, Ben Noordhuis <[email protected]> wrote: > > > Maybe I didn't explain it well but in metrics-only mode, no data is > sent to our collector. Basically, the agent collects metrics > in-process and your agent.use() callback is the data sink. We have > more advanced options for clustered applications but that's the basic > mode of operation. > > > This is great, thanks. Definitely something I would want to try out. > > > There was a "birds of a feather" session in Vancouver in August; my > co-worker Sam represented StrongLoop. > > To the best of my knowledge, not much came of it and I suspect that's > because there is not much overlap in the wants and needs of the > stakeholders. > > > > I find this surprising. Aren’t the problems (at least the common subset) > the same as in any medium to large scale project? Find out where the CPU > cycles are spent, figure out if memory is leaking, etc. Or am I off on the > wrong tangent w.r.t this thread? > > —ravi > > -- > Job board: http://jobs.nodejs.org/ > New group rules: > https://gist.github.com/othiym23/9886289#file-moderation-policy-md > Old group rules: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > --- > You received this message because you are subscribed to the Google Groups > "nodejs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/nodejs/467C8A86-27E5-4B5A-A3C4-2838E8EDDD0E%40g8o.net > <https://groups.google.com/d/msgid/nodejs/467C8A86-27E5-4B5A-A3C4-2838E8EDDD0E%40g8o.net?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Job board: http://jobs.nodejs.org/ New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/CABcFeBUh1cLPtdgfcR09mzkEyStE_DK_3vnxaZpNDA4xUq9CrA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
