bitnomial/prometheus

Prometheus.io Haskell client.

prometheus's Issues

Allow non-Double Gauges

Currently using Prometheus Gauges to log a Word64 using fromIntegral and it gets reported as:

db_slot_height  2.3628703e7

This is a little suboptimal.

Would it be worth adding a Word64 gauge? If you can point me in the direction of what you want, I may even find time to do it myself.

Bump base build dep?

Could we get the base build dep bumped?

Consider listing the package in Stackage

The prometheus package is currently not in Stackage. Please consider adding it. It is recommended that the package author maintains the Stackage listing, but if you have no interest in maintaining the Stackage listing, I can volunteer to do so on your behalf.

Specify labels at the point of observation?

I was looking into Prometheus libraries and was attracted to this one by its type safety and restricted use of IO.

However, I can't figure out how to set labels at the point of observation, which is a particularly common use case. e.g. I'd like to record the method & status code of HTTP requests & responses alongside their latency.

This is something of a blocker for me. Are you open to accepting patches?

Please bump upper bound of text dependency on Hackage

Here in git you have:

               , text            >= 1.2  && < 2.1

but the version on Hackage has:

text >=1.2 && <1.3,

This can be fixed by a metadata update on Hackage.

I am currently using:

allow-newer: prometheus:text

in my cabal.project file

Name and label validation

How do you want to handle name and label validation, mentioned in the README as a wanted feature? I think the easiest option is to replace invalid characters. It's probably possible to make them a compile-time failure instead, but I think not worth it. If that's the approach you want, I can put together a PR to bring https://github.com/Simspace/ekg-prometheus-adapter/commit/704078488730b7e87eaa95ee3bbe3b2ad6cf1cf8 into this package.

New version?

The latest version in git has a cabal file that says its version 2.1.0 (and which supports containers == 0.6.*), but the latest version on Hackage is 2.1.1 which does not support containers == 0.5.*.

prometheus-2.0.0 Build Failure

https://matrix.hackage.haskell.org/package/prometheus#GHC-8.2/prometheus-2.0.0

Data.Semigroup (Semigroup) needs to be imported.

Please release a new version

Current HEAD has more relaxed upper version bounds on bytestring, containers and transformers

If that can be fixed with a Hackage metadata revision then that would also be fine.

In my cabal.project file I currently have;

allow-newer:
  , prometheus:text

if impl(ghc >= 9.6)
  allow-newer:
    , prometheus:bytestring
    , prometheus:containers
    , prometheus:transformers

There is no System.Metrics.Prometheus.Concurrent.Http

and this module is mentioned in the example in the .cabal file and README.

Question: metric persistance

Is there a solution for persisting metrics here? Is it needed? Specifically - if I restart my metrics server, how will that affect my counters? It seems they would be wiped.

Thunk Leak in Histogram

Illustrated by this ghci session: https://gist.github.com/ramirez7/591582438c34f6eac9c0b11ca95d086f

HistogramSample just needs some strictness annotations I believe.

Loosen http-client version bounds

New versions of http-client have been released that are compatible
with prometheus. Can the version bounds be widened to include these
new versions of http-client?

               , http-client    >= 0.4  && < 0.7

Should be sufficient.

Label values must be specified up-front (?)

Hi, I was comparing this library to prometheus-client and other prometheus libraries. One drawback, as far as I can tell from the API docs, is that all label values must be specified up-front. Is this correct? The documentation gives this as an example, which gives "success" or "failure" for the possible label values:

main :: IO ()
main = runRegistryT $ do
    -- Labels can be defined as lists or added to an empty label set
    connectSuccessGauge <- registerGauge "example_connections" (fromList [("login", "success")])
    connectFailureGauge <- registerGauge "example_connections" (addLabel "login" "failure" mempty)

This seems somewhat inflexible. For example, the Prometheus docs suggest having an http_requests_total with a label for the status code (https://prometheus.io/docs/practices/instrumentation/#use-labels). If you had to specify the status code up front, it seems like you'd have to auto-create values for 100–599, which isn't ideal.

Other libraries don't have this restriction, e.g. https://github.com/prometheus/client_ruby#summary, for comparison