Open mj0nez opened 1 month ago
basically we had two requirements for metrics: 1) should be type-safe 2) should create usable docs
Literal
was just the easiest way to get there without impacting ergonomics of internal code too much. if it can be done in some other way, i'm open to it. I'm not entirely sure I understand your requirements though, and why you need it to change.
To create a metric with the prometheus client library I have to provide a name and description, set aside the type of the metric. Name and type I can cover with a defaultdict but the description is currently only in comments. So, I extracted the descriptions manually, but was unsure if this would be sustainable for the future, when new metrics would be added, or existing ones modified.
To be honest, I don’t see a solution which does not involve duplicating at least the metric names while keeping the current behavior. But I wanted to see if anybody had an idea... Feel free to close the issue and thanks for your reply! :)
I think we can check in some code into arroyo CI that extracts metric definitions from sourcecode and publishes a machine-readable file alongside docs.
Hi,
Thank you for arroyo! I'm currently adopting it and to integrate the exposed metrics with our Prometheus setup, I had to redefine the metrics in metric_def.py. It would be nice if we could use some simple structure like the following to give each metric a description and type that may be evaluated by downstream consumers/other backends.
AFAIK it's not possible to generate a
Literal
like the currentMetricName
dynamically, so this is something to consider. But if you accept this request, I would be happy to contribute. :)