Hi,
first off: *Don't get me wrong I like the fact, that there are companys out
ther supporting nodejs with *
*extra services and "consulting". *I would however prefer to be the master
over my data and learn from it
myself without a frontend that takes away most of the insights they
(probably)
On Mon, Nov 10, 2014 at 9:03 PM, Andreas Marschke
wrote:
> Hi,
>
> first off: Don't get me wrong I like the fact, that there are companys out
> ther supporting nodejs with
> extra services and "consulting". I would however prefer to be the master
> over my data and learn from it
> myself without a
Hi Ben,
thanks for your pointers.
The fact that I need an API-key and have to (If I understand you correctly)
still send my data to the service provider (in worst case
even through the same network interface as my data I need to process comes
in from) means I still have no control over my da
Hi Andreas,
My little contribution to the
topic: https://github.com/Sage/streamline-flamegraph. It does not depend on
an external service but it assumes that you are writing your code with
streamline.js.
The cool feature is that it gives you insights into your "long" stack
traces and it gener
On Tue, Nov 11, 2014 at 12:04 PM, Andreas Marschke
wrote:
> Hi Ben,
>
> thanks for your pointers.
>
> The fact that I need an API-key and have to (If I understand you correctly)
> still send my data to the service provider (in worst case
> even through the same network interface as my data I need
On Nov 11, 2014, at 5:59 PM, Ben Noordhuis 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 app
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 asyn
>
> 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.
>
Isn't this a bit of
On Wednesday, 12 November 2014 01:11:54 UTC+1, Ben Noordhuis wrote:
>
> On Tue, Nov 11, 2014 at 12:04 PM, Andreas Marschke
> > wrote:
> > Hi Ben,
> >
> > thanks for your pointers.
> >
> > The fact that I need an API-key and have to (If I understand you
> correctly)
> > still send my data
+1
The important question here I guess is : How do you get these library
neutral instrumentations into the node runtime? Which is also what I
eluded to asking if would make sense to have people from v8 & node core
team together with people from the node-community at the same table and
start worki
Unfortunately, Google/V8 doesn't really care about nodejs. They only care
about the browser, for which they deem the WebKit inspector to be
sufficient. StrongLoop put so much effort into their node-inspector port of
those tools for that exact reason.
On Nov 12, 2014 11:39 AM, "Andreas Marschke"
wr
Hi Andreas
Another option to consider for performance monitoring is Concurix
(http://concurix.com). Full disclosure--I am the founder and CEO there!
We have a fully on premise profiling and monitoring solution for Node.js.
There is no API key or signup needed, and it runs on stock Node.js on
Hi Alex,
thank you very much. Has any of the work that you and your company have
made filtered back to the community in any way? Just interested.
Because as we've already realized in this Thread. The tools in the
community is very barebones or not entirely interoperable or anything.
At best -
Is there the SET of tools that you can work while being offline ?
so you don't need to communicate to other server, login to other system...
Just like node-inspector, but for profiling and monitoring ?
On Saturday, November 15, 2014 7:05:33 AM UTC+4, Andreas Marschke wrote:
>
> Hi Alex,
>
> than
Alex,
Does your code work well with Streamlined code yet? Liked your software but
in earlier tests the overhead brought our system down because we used
streamline which adds a lot of extra functions when it rewrites the code.
We are currently writing our own flavor of performance monitoring usi
15 matches
Mail list logo