When I first started using metrology, I didn't quite understand the registry (it deserves to be documented better), but I came to appreciate it quite a bit. I am using it this way: I create metrics all over my code. I then have an asyncio task that is able to access the metrics via the global registry, and submit it's values (kind like the builtin reporters do).
One thing I found to be useful is to have more flexibility here. For example, say I have a queue for every connected client. I wanted to log the current queue size for every client to InfluxDB, with the client id attached to the metric. Using this patch, here is what I can do:
for metric, tags in registry.filter_metrics({'name': 'queue-length'}):
write_to_influx(metric.value, client=tags['client'])
That is, it can find all the metrics of a given name, and also can retrieve other information attached.
The patch is backwards-compatible with the existing API. If a string is passed as the name of a metric, things keep working as-is. If a dict of tags is passed, they can be queried as tags.
When I first started using metrology, I didn't quite understand the registry (it deserves to be documented better), but I came to appreciate it quite a bit. I am using it this way: I create metrics all over my code. I then have an asyncio task that is able to access the metrics via the global registry, and submit it's values (kind like the builtin reporters do).
One thing I found to be useful is to have more flexibility here. For example, say I have a queue for every connected client. I wanted to log the current queue size for every client to InfluxDB, with the client id attached to the metric. Using this patch, here is what I can do:
My stats reporter than does:
That is, it can find all the metrics of a given name, and also can retrieve other information attached.
The patch is backwards-compatible with the existing API. If a string is passed as the name of a metric, things keep working as-is. If a dict of tags is passed, they can be queried as tags.