Feature Request: Performance hooks entry for http

[vmarchaud]

Is your feature request related to a problem? Please describe.
Retrieve metrics from a HTTP server.

Describe the solution you'd like
Pretty much the same as the current implementation between http2 and perf_hooks : https://github.com/nodejs/node/blob/master/test/parallel/test-http2-perf_hooks.js

Since the http server is only js-land, i believe we could just implement by hooking to the perf_hooks js api.
I've looked a little bit at the code, we could add a stats object in the request state and emit them when the request is ended (of course only if the entry has an observer).
I'm really interested on implementing it so i'm opening it an issue to have some feedback before coding anything.

Describe alternatives you've considered

Currently i believe all APM vendors are forced to monkey-patch the event-emitter on http.Server.prototype and then listen on request event, add event listener to know when the response is sent and compute some metrics about both the request and the response.

[vmarchaud]

@jasnell i believe you worked a lot on the perf_hooks, do you have any opinion on this ?

[Flarna]

Currently i believe all APM vendors are forced to monkey-patch ...

Yes, APMs do monkey-patching of http but we have more needs then the data provided by perf_hooks therefore this would be no replacement but a good extension/partial replacement.

[vmarchaud]

@Flarna I totally agree, it's a large task to offer all the functionality of an APM in the core.
I believe starting to add more metrics natively will be useful for both APM vendors that will offload complexity of their agent and common users that will be able to get basic monitoring easily.

[jasnell]

It is certainly possible. One of the challenges with the http implementation currently is that it is fairly brittle performance wise... we would need to be careful about where we introduce data collection and how. The actual emitting of the perf entries is done at the C++ layer because there is integration into the trace events mechanism but that's a fairly minor detail. Bottom line, this is certainly doable and I'm happy to help mentor someone through what is needed. A good first step, however, would be to detail which metrics are most helpful.

[vmarchaud]

One of the challenges with the http implementation currently is that it is fairly brittle performance wise

Agreed that we need to take a look at the benchmark before/after.

The actual emitting of the perf entries is done at the C++ layer because there is integration into the trace events mechanism but that's a fairly minor detail

I suppose you were referring to the http2 implementation but i didn't find any place on the code where the pref entries are linked to the trace events mechanism (i found your old PR that was never merged there though: #18809). I would be interested to understand the connection between both

A good first step, however, would be to detail which metrics are most helpful.

Based from the specification of OpenCensus (which i believe people studied which metrics were useful for end users when making a choice) and the already-implemented http2 metrics, i think we could target:

• Time to first byte received
• Received bytes
• Time to first byte sent
• Total duration (from first byte read to last byte written)
• Sent bytes

What do you think ?