# GET \_nodes/stats in 7.13 includes large amount of potentially unwanted "clients" information by default

**URL:** <https://discuss.elastic.co/t/get-nodes-stats-in-7-13-includes-large-amount-of-potentially-unwanted-clients-information-by-default/274090>\
**Category:** Elasticsearch\
**Tags:** elastic-stack-monitoring\
**Created:** [May 26, 2021, 3:47pm UTC](https://discuss.elastic.co/t/get-nodes-stats-in-7-13-includes-large-amount-of-potentially-unwanted-clients-information-by-default/274090 "2021-05-26T15:47:01Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Presence](https://avatars.discourse-cdn.com/v4/letter/p/7feea3/32.png) [@Presence](https://discuss.elastic.co/u/Presence)\
**Post date:** [May 26, 2021, 3:47pm UTC](https://discuss.elastic.co/t/get-nodes-stats-in-7-13-includes-large-amount-of-potentially-unwanted-clients-information-by-default/274090/1 "2021-05-26T15:47:01Z")

</div>

Having just upgraded our Elastic Cloud cluster from 7.12.1 to 7.13.0 we've found that `GET _nodes/stats` now includes a fairly large chunk of data about "clients" which wasn't present before. This could be useful, but I'm not sure if it needs to be included by default? It's pretty hefty!

I believe the related issue from the release notes is [Show Connected Clients API · Issue #61609 · elastic/elasticsearch · GitHub](https://github.com/elastic/elasticsearch/issues/61609).

For us, this broke our integration with the justwatch/elasticsearch-exporter (which we use to make ElasticSearch stats Prometheus scrapable). 😭

I can see that this can be disabled via the `http.client_stats.enabled` cluster setting, but wonder if the default ought to be false, rather than true?

---

<div class="post-metadata">

**Author:** ![Presence](https://avatars.discourse-cdn.com/v4/letter/p/7feea3/32.png) [@Presence](https://discuss.elastic.co/u/Presence)\
**Post date:** [May 26, 2021, 3:54pm UTC](https://discuss.elastic.co/t/get-nodes-stats-in-7-13-includes-large-amount-of-potentially-unwanted-clients-information-by-default/274090/2 "2021-05-26T15:54:46Z")

</div>

Further to this, using the `http.client_stats.enabled` does remove the heavy response 🎉, but it doesn't fix my parsing problem because the `http` part of the response still includes an empty array `"clients":[]`. 😭

---

<div class="post-metadata">

**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\
**Post date:** [May 26, 2021, 4:26pm UTC](https://discuss.elastic.co/t/get-nodes-stats-in-7-13-includes-large-amount-of-potentially-unwanted-clients-information-by-default/274090/3 "2021-05-26T16:26:17Z")

</div>

I think you'll need to take this up with the folks responsible for the parsing code you're using. Adding fields to a response isn't considered a breaking change, we expect clients to ignore fields they don't recognise.

---

<div class="post-metadata">

**Author:** ![Presence](https://avatars.discourse-cdn.com/v4/letter/p/7feea3/32.png) [@Presence](https://discuss.elastic.co/u/Presence)\
**Post date:** [May 26, 2021, 10:36pm UTC](https://discuss.elastic.co/t/get-nodes-stats-in-7-13-includes-large-amount-of-potentially-unwanted-clients-information-by-default/274090/4 "2021-05-26T22:36:16Z")

</div>

Thanks David. That’s a totally fair design assumption.

Sadly the exporter we’re using seems to have fallen out of regular maintenance some time ago, so I guess it was inevitable something like this would arise eventually. Will investigate what can be done though.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [June 23, 2021, 10:37pm UTC](https://discuss.elastic.co/t/get-nodes-stats-in-7-13-includes-large-amount-of-potentially-unwanted-clients-information-by-default/274090/5 "2021-06-23T22:37:06Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
