Liebe Kundin, lieber Kunde,
wir bedanken uns für Ihre Nachricht.
Unsere smarten sowie fachlich kompetenten Kundenberater werden Ihr Anliegen
zeitnah bearbeiten.
Für Rückfragen teilen wir Ihnen hier gerne Ihre persönliche Vorgangsnummer
T-QEWN8PP4Z2-94 mit.
Unsere Geschäftszeiten sind von Montag
ormats/#text-based-format
> > > which declares a Content-Type of "text/plain; version=0.0.4" - so
> > > defaulting to that, but following Joan's suggestion and switching to
> JSON
> > > for a supplied Accept:application/json in the standard way seems a
&
efaulting to that, but following Joan's suggestion and switching to JSON
> > for a supplied Accept:application/json in the standard way seems a like
> > good choice to me.
> >
> > Rich
> >
> >
> >
> > From: Jan Lehnardt
> > To: dev@couch
>> for a supplied Accept:application/json in the standard way seems a like
>> good choice to me.
>>
>> Rich
>>
>>
>>
>> From: Jan Lehnardt
>> To: dev@couchdb.apache.org
>> Cc: "Gesellchen, Tobias"
>> Date:
Thanks, Joan for your reply around your vacation.
Good suggestion about the proposed job config for prometheus endpoint.
I will come up with more details after integrating these valuable suggestions.
Thanks,
Peng Hui
> On Sep 24, 2020, at 4:35 AM, Joan Touzet wrote:
>
> Looking at the Prome
od choice to me.
>>
>> Rich
>>
>>
>>
>> From: Jan Lehnardt
>> To: dev@couchdb.apache.org
>> Cc: "Gesellchen, Tobias"
>> Date: 23/09/2020 16:42
>> Subject:[EXTERNAL] Re: [DISCUSS] Prometheus endpoint in CouchDB
Thanks Will for your comments and question. I made study on _active_tasks
endpoint in the CouchDB 4.x. Currently, we can get the information about
“indexer” and “replication” tasks in 4.x. In the response, the node information
[1] can be found like below. This gives us chance to scope _active_t
27;s text
> >> representation linking back to
> >>
> https://prometheus.io/docs/instrumenting/exposition_formats/#text-based-format
> >> which declares a Content-Type of "text/plain; version=0.0.4" - so
> >> defaulting to that, but following Joan's su
tandard way seems a like
>> good choice to me.
>>
>> Rich
>>
>>
>>
>> From: Jan Lehnardt
>> To: dev@couchdb.apache.org
>> Cc: "Gesellchen, Tobias"
>> Date: 23/09/2020 16:42
>> Subject:[EXTERNAL] R
estion and switching to JSON
> for a supplied Accept:application/json in the standard way seems a like
> good choice to me.
>
> Rich
>
>
>
> From: Jan Lehnardt
> To: dev@couchdb.apache.org
> Cc: "Gesellchen, Tobias"
> Date: 23/09/2020 16
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 defau
n/json in the standard way seems a like
> good choice to me.
>
> Rich
>
>
>
> From: Jan Lehnardt
> To: dev@couchdb.apache.org
> Cc: "Gesellchen, Tobias"
> Date: 23/09/2020 16:42
> Subject:[EXTERNAL] Re: [DISCUSS] Prometheus endp
.
Rich
From: Jan Lehnardt
To: dev@couchdb.apache.org
Cc: "Gesellchen, Tobias"
Date: 23/09/2020 16:42
Subject: [EXTERNAL] 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 Cou
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 o
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 Sc
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 Prom
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 s
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 regar
I like this, but not at the expense of JSON output. It would be the only
new API surface for CouchDB that isn't JSON-based, and there needs to be
excellent justification for such. Prometheus is well-known enough to be
supported, but we should continue to put out JSON stats for the
foreseeable f
Hey Donat,
Thanks for checking. The idea is to keep the _stats, _system and _active_tasks
endpoints to be backward compatible. If Prometheus endpoint is used widely, we
can consider to deprecate these endpoints.
Best regards,
Peng Hui
> On Sep 23, 2020, at 1:05 AM, Bessenyei Balázs Donát wrot
Hi Peng Hui (and Garren),
I think the Prometheus support would be an awesome feature!
>From the e-mail it's not clear to me what would happen to the already
existing endpoints mentioned (`_stats`, `_system` and
`_active_tasks`).
Are they going to be deprecated / removed? Or does the info become
av
Hey all,
We would like to add a Prometheus metrics endpoint for CouchDB and wanted to
see if the community would be interested in us contributing this to CouchDB
4.x.
Prometheus is a CNCF open-source project and the Prometheus metrics endpoint
format is supported by many monitoring tools. Its
22 matches
Mail list logo
