Possible improvements to the Deno.metrics interface

[wperron]

Following a discussion that happened on the Discord server, I think there's opportunities to improve on the metrics op by making it more flexible or more open. As it stands the metrics op only allows wrapping other ops and keeps a global set of metrics and counters exposed through the Deno.metrics method.

I think we can improve on it by making it possible on the Rust side to register custom metrics, or maybe namespaced metrics. I could see this coming handy in Rust applications that embed deno_runtime for adding scripting capabilities and that have a set of custom ops defined. We could also allow registering metrics from the JS side, though we'd have to check the performance implications here since the counters are kept on the privileged Rust side. One advantage I could see could be to label metrics from Worker instances differently, but have all metrics exposed through Deno.metrics in the main thread.

We could also add different types of metrics. Right now the metrics are simple counters, but there are a lot of different types of metrics we could have. I think following the OpenMetrics standard or the Prometheus format here is a good approach.

The main idea I have for this would be to centralize everything metrics in Deno.metrics so that there is an obvious, "good" way of writing observability tooling for Deno that is always available and easily extendable.

for reference: https://discord.com/channels/684898665143206084/688040863313428503/802173265106829363

the metrics interface at the time of writing this post : https://github.com/denoland/deno/blob/1518fabfbba3cb951357f7c7977d6346943a9a8f/runtime/metrics.rs

---

Interesting conversation on the Discord server on the subject https://discord.com/channels/684898665143206084/684911491035430919/825784049393205258

[grian32]

If we're going to get metrics for CPU and RAM usage, I think it'd be a good idea to have minimum usage, maximum usage, and average usage.