haskell-servant / servant-ekg Goto Github PK

I was able to add prometheus metrics supports with this super small snippet:

import Data.Proxy (Proxy)
import Data.Text (Text)
import qualified Data.Text as Text
import Network.Wai (Application, Request)
import Network.Wai.Middleware.Prometheus (instrumentHandlerValue)
import Servant.Ekg
  ( APIEndpoint (APIEndpoint),
    HasEndpoint (getEndpoint),
  )

-- | A middleware that records latency metrics for all endpoints in 'api'
instrumentServantHandlers :: HasEndpoint api => Proxy api -> Application -> Application
instrumentServantHandlers proxy app = do
  instrumentHandlerValue (makeLabel proxy) app

makeLabel :: HasEndpoint api => Proxy api -> Request -> Text
makeLabel proxy req = case getEndpoint proxy req of
  Nothing -> "<unknown>"
  Just (APIEndpoint pathParts _method) -> "/" <> Text.intercalate "/" pathParts

type GetMetrics = "metrics" :> Get '[PlainText] Text
handleGetMetrics :: Handler Text
handleGetMetrics = do
  Encoding.decodeUtf8With Encoding.lenientDecode <$> Prometheus.exportMetricsAsText

It only depends on the HasEndpoint typeclass. I'm wondering if maybe we should move HasEndpoint into the servant core package to make Prometheus support possible without people having to pull in the ekg dependency? cc @haskell-servant/maintainers

IDK if servant-prometheus deserves its only library or should just be a cookbook with the above code.

Servant responds to HEAD requests with the result of the GET path (minus the body), since haskell-servant/servant@050aa21

If the WAI verb is HEAD, and the path verb is GET, this path should match.

e.g.

instance ReflectMethod method => HasEndpoint (Verb method status cts a) where
    getEndpoint _ req =
      if requestMethod req == method || (requestMethod req == methodHead && method == methodGet) then
        Just (APIEndpoint [] method)
      else
        Nothing

    enumerateEndpoints _ = [APIEndpoint mempty method]
      where method = reflectMethod (Proxy :: Proxy method)

Though actually, this is incomplete; a GET route should also register a HEAD route in enumerateEndpoints, and the WAI verb should be used in preference to the route verb in the result of getEndpoint.

I've been using the repository as the source for the package, but I would be interested in using a version on Hackage. Does it make sense to push a new version?

I'm happy to move the https://github.com/christian-marie/servant-ekg project here, but, as per christian-marie#4 I'm not sure how.

Does anyone know the process?

Do we need GitHub support to do this?

What do you think about using a monotonic clock like the one in System.Clock instead of getCurrentTime? System clocks occasionally move backwards in order to correct clock skew, which makes a mess of latency statistics.

(To be clear, I haven't yet seen this issue with this particular library, but it's a known challenge.)

Happy to follow up with a PR if you like the idea.

Otherwise this is going to be slow...

Would it be possible to get an update for servant-ekg that supports the current version of warp-3.3.5? I tried the build with the upper bound edited out and it succeeded just fine, so maybe all there is to it is to edit the Cabal file an Hackage to allow the newer version.

Using lts-14.27.

The API type has overlapping endpoints plus a raw endpoint for Pandoc-generated API documentation. The application runs hoisted on a custom monad

type TheAPI = "try" :> "this" :> ...
                  :<|> "try" :> "that" :> ... 
                  :<|> "try" :> "those" :> ...
                  :<|> "lookup"
                  :<|> Raw

theAPI :: Proxy TheAPI
theAPI = Proxy

apiServer :: ServerT TheAPI CustomM
apiServer = ... :<|> ... etc

myApp config = serve theAPI $ hoistServer theAPI (nt cconfig) apiServer

where nt does the natural transformation via runReaderT and runLoggerT.

After a vanilla System.Remote.Monitoring.forkServer, I'm wrapping the application as follows

wrapWithEkg <- newStore >>= monitorEndpoints theAPI
runSettings settings (wrapWithEkg $ myApp cfg)

where runSettings does runTLS over a custom TCP port.

I can connect to EKG. The standard EKG metrics are there, but none of the Servant specific measurements show up.