Prometheus has a specification on how APIs should be designed: https://prometheus.io/docs/instrumenting/writing_clientlibs/
Some notable things missing from prometheus:
- Metric descriptions
- Easily specifying labels dynamically
- Metrics should be global variables
- From the specification: "These should be primarily used as file-static variables, that is, global variables defined in the same file as the code they’re instrumenting."
- Metrics should be implicitly registered
- From the specification: "There MUST be a default CollectorRegistry, the standard metrics MUST by default implicitly register into it with no special work required by the user."
I know global variables + implicit registration is anti-idiomatic Haskell, but I think observability should be as drop-in as possible, and this would align the library with all the other Prometheus client libraries, which would make it easy for someone familiar with instrumenting with Prometheus in other languages to instrument Haskell codebases.
This would be a pretty drastic change to the API. One could argue this should be a separate library, but we already have two Haskell Prometheus APIs, and adding a third seems unideal.
Prometheus has a specification on how APIs should be designed: https://prometheus.io/docs/instrumenting/writing_clientlibs/
Some notable things missing from
prometheus:I know global variables + implicit registration is anti-idiomatic Haskell, but I think observability should be as drop-in as possible, and this would align the library with all the other Prometheus client libraries, which would make it easy for someone familiar with instrumenting with Prometheus in other languages to instrument Haskell codebases.
This would be a pretty drastic change to the API. One could argue this should be a separate library, but we already have two Haskell Prometheus APIs, and adding a third seems unideal.