Metrics, this is a useful thing to have in a game engine. We came up with this idea while working on networking. @fletcher, @LucioFranco, @TimonPost decided that it could be quite useful to have metrics, not only for networking but for the entire engine.
So metrics, there are different ways to output them, different ways to get them, different ways to generate them.
Lets put the requirements in a list:
- Should not impact the performance or systems
- Should not be blocking
- Configurable, like in a sense of enabling, disabling, choosing a service to output the metrics too.
- Statsd support
There are a ton of monitoring platforms out there, we want to provide, at least, support for some popular ones.
Any more platforms, priority?
We also want to support some easier way of having metrics of your game like:
- Files (csv, xml, etc)
- Database (SQLite).
The question here is which metric output should we ‘at least’ support?
There are a few crates of interest:
- Hotmic (475 downloads, last active: 5 months, version 0.2.1)
- based on
mio, so it’s blazingly fast (faster than
tic; see rough numbers here)
- supports counters, gauges, and histograms
- provides dynamic faceting: what portion of metric data should be recorded, and in what way
- control mechanism to allow any caller to retrieve metric snapshots at any time]
- Fork of Tic but faster ‘at least what they say’
- Dipstick (13,813 downloads, last active: 6 months, version 0.6.11)
- Send metrics to console, log, statsd, graphite or prometheus (one or many)
- Serve metrics over HTTP
- Locally aggregate the count, sum, mean, min, max and rate of metric values
- Publish aggregated metrics, on schedule or programmatically
- Customize output statistics and formatting
- Define global or scoped (e.g. per request) metrics
- Statistically sample metrics (statsd)
- Choose between sync or async operation
- Choose between buffered or immediate output
- Switch between metric backends at runtime
- Cadence (18,390 downloads, last active: 13 days, version 0.16.11)
- Support for emitting counters, timers, histograms, gauges, meters, and sets to Statsd over UDP.
- Support for alternate backends via the
- Support for Datadog style metric tags.
- A simple yet flexible API for sending metrics.
which crate to use?
Hotmic is fast and has a tokio backend, it is very basic and so easier to customize for our needs. It is only focused on receiving and sending metrics. It does not support statsd so we have to use a statsd parser before we can send data.
Dipstick already provides a backend for graphite, basic Prometheus, HTTP, console. And works with statsd.
Cadence provides also customizable backend with UDP and is havely based on Statsd.
Any idea’s on how to integrate metrics into amethyst and a possible design?
We think it will be a good idea to have metrics in a seperate crate of amehyst like: ‘amethyst_metrics’