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
lares 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
> like
> > > good choice to me.
> > &g
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, Tobia
lication/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
>> Subjec
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
.
>>
>> 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
&
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
k 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 suggestion and switching to
> JSON
> >> for a
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 endpoint
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:42
> Subject:[EXTERN
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
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] Re: [DISCUSS] Prometheus endpoint in CouchDB
: 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 CouchDB” en
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
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
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
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
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
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
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
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
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.
22 matches
Mail list logo
