"these features should be enough for everyone" edition - https://github.com/status-im/nim-metrics
Documentation highlights:
- Designed to be thread-safe and efficient, it's disabled by default so libraries can use it without any overhead for those library users not interested in metrics.
- By starting an HTTP server, custom metrics (and some default ones) can be pulled by Prometheus. By specifying backends, those same custom metrics will be pushed to StatsD or Carbon servers, as soon as they are modified. They can also be serialised to strings for some quick and dirty logging. Integration with the Chronicles logging library is available in a separate module.
- That HTTP server used for pulling is running in its own thread. Metric pushing also uses a dedicated thread for networking, in order to minimise the overhead.
- All the networking complexity is hidden from the API user and additional latency is kept to a minimum. Exported (pushed) metrics are treated like disposable data and dropped at the first sign of trouble.
Grafana-supplied eye candy:
Put that screenshot on Readme IMHO.
I wrote a prometheus library too: https://github.com/dom96/prometheus.
It features:
- Counters, Gauges and Histogram support
- Comes standard with a couple of useful collectors for tracking precisely where memory is being used in your program or which futures are waiting
It is pretty simple, but has worked very well for my use cases so far.
Example showing what the GC collector can generate:
You can see the GC kicking in about midway through :)
Thanks for the idea, @juancarlospaco. Screenshot added here: https://github.com/status-im/nim-metrics#prometheus-endpoint
There's also a lightweight StatsD-only library: statsd_client
non-blocking
The StatsD protocol is also used over TCP, not just UDP: https://github.com/statsd/statsd#statsd--
Wonderful!! ill check it out when i have more time