Re: [DISCUSS] Prometheus endpoint in CouchDB 4.x

Hi, chiming in as maintainer of the already mentioned https://github.com/gesellix/couchdb-prometheus-exporter . My impression would be to consolidate the existing endpoints first (maybe at /_metrics, because /_info sounds too informal),

Re: [DISCUSS] Prometheus endpoint in CouchDB 4.x

Hi, I don't see why this can't be a new endpoint (emitting the normal Prometheus format) that couchdb administrators can choose to enable (and leave it disabled by default, returning a 404). I agree with the general view that content type negotiation doesn't really work well in practice, and

Re: [DISCUSS] Prometheus endpoint in CouchDB 4.x

Looking at the Prometheus scrape documentation, you can specify a full URL. https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config Jan's suggestion of using /_{info|metrics}?accept=prometheus with the default being JSON would be better for CouchDB than the

Re: [DISCUSS] Prometheus endpoint in CouchDB 4.x

> On 23. Sep 2020, at 18:25, Richard Ellis wrote: > >> so we should absolutely make this info available in JSON > > This sounds like a good idea to me > >> we could fall back to a ?accept=prometheus option > > I'm opposed to adding endpoints that supply different content-type > responses

Re: [DISCUSS] Prometheus endpoint in CouchDB 4.x

>so we should absolutely make this info available in JSON This sounds like a good idea to me >we could fall back to a ?accept=prometheus option I'm opposed to adding endpoints that supply different content-type responses via non-standard means. The CouchDB API has some examples of this

Re: [DISCUSS] Prometheus endpoint in CouchDB 4.x

Hi all, a few things to consider: 1. The idea of unifying our “get runtime info about CouchDB” endpoints into one is solid, as it is always weird to make sure you know which info you get where. We see this specifically in support engagements, where it is always awkward to ask for the results

Re: [DISCUSS] Prometheus endpoint in CouchDB 4.x

Hi Reddy, It's not purely for one third-party tool. It could be considered a standard way to expose metrics. Here are some projects that support a metrics endpoint https://prometheus.io/docs/instrumenting/exporters/#software-exposing-prometheus-metrics There are a few databases CoachroachDB and

Re: [DISCUSS] Prometheus endpoint in CouchDB 4.x

I feel like it could feel weird and inconsistent to introduce a new format here solely to support a third-party tool. Why not add the missing metrics to existing endpoints and let people using prometheus set up an HTTP middleware in the application layer? If there is in built-in support for

Re: [DISCUSS] Prometheus endpoint in CouchDB 4.x

Thanks Peng Hui, Garren. I can definitely see value in having metrics exposed in Prometheus format. One aspect I'm unclear about is what _active_tasks metrics would represent. My expectation is that /_metrics would be scoped to a node (and then leave the aggregation across nodes to Prometheus or

Re: [DISCUSS] Prometheus endpoint in CouchDB 4.x

Thanks Joan for your quick response and suggestion. As we can see, JSON is not the standard Prometheus format for _metrics endpoint. In order to be compatible with many monitoring tools, what about going with Prometheus standard format first and we may add JSON format support later? Best