Additional Libuv Metrics

[anthonyalayo]

PR #3749 added support for libuv metrics. These are great! I really appreciate them.

There are some more metrics that I think would be very helpful:

1. Loop lag metrics

I added loop lag metrics myself with some boilerplate on top of libuv. I did this by using a uv_timer_t, kicking off the timer, and calculating the delay in when it was run. This helped show us big spikes in our main loop that we could optimize.

2. Worker Pool utilization metrics

We currently use file operations such as uv_fs_open. These operations as far as I know will be serviced with libuv's internal thread pool: https://docs.libuv.org/en/v1.x/threadpool.html

I don't believe there are any metrics exposed for thread pool utilization? We increased UV_THREADPOOL_SIZE above the default due to issues we were seeing, but it was mostly a touch and feel approach. Being able to see utilization of this pool would be great.

How do maintainers feel about this?

[bnoordhuis]

Loop lag metrics

I'm not too keen on adding that. For one, it's not clear to me how meaningful it would be in UV_RUN_NOWAIT mode.

Worker Pool utilization metrics

We currently use file operations such as uv_fs_open. These operations as far as I know will be serviced with libuv's internal thread pool

Sometimes. They can also be serviced by io_uring. I'm inclined to say thread pool metrics aren't that useful for that reason alone.

I mean, tracking per-request latency (i.e., the time a uv_fs_t operation takes from start to finish) is useful but that's something embedders can implement themselves. We're unlikely to bake that into libuv itself because it's a) not necessary, and b) adds overhead.

[anthonyalayo]

Both sound fair, I hadn't thought about those cases.