Disable specific deprecation warnings

[joschi]

Hey folks,

after upgrading to Elasticsearch 7.16.2, we receive the following deprecation warning in our clients (Java High-Level REST client):

org.elasticsearch.client.RestClient - request [POST http://example.com:9200/my_index/_search?[...]&ignore_throttled=false[...]] returned 1 warnings: [299 Elasticsearch-7.16.2-xxx "[ignore_throttled] parameter is deprecated because frozen indices have been deprecated. Consider cold or frozen tiers in place of frozen indices."]

Since the application is still supposed to work with older versions of Elasticsearch 7.x, we cannot simply remove the deprecated ignore_throttled option. But we also do not want to spam our logs with that warning message.

Is there a way to disable specific warnings on the Elasticsearch node so that clients using ignore_throttled won't receive a warning?

To be clear, I don't want to silence all deprecations warnings, just this specific one.

Cheers,
Jochen

[ritchierich (Rich Horace)]

@joschi

Kibana needs to be upgraded to the same version

Here's solution to the same question.

Ignore_throttled parameter is deprecated

I've updated my Elasticsearch installation from 7.15.2 to 7.16, but when I open a dashboard I'm greeted with the following Warning: [image] I looked in the deprecated log file before updating and this wasn't in there and I have not found any solution for this.

[joschi]

Thanks for your reply, @ritchierich. We're not using Kibana or any other component of the Elastic Stack.

The warning message is logged by the Java High Level REST client because the Elasticsearch node sends it in its response (Warning HTTP response header) and I want to know how to disable the generation of this warning on the Elasticsearch node.

I'd also be fine with disabling the log message for this particular deprecation warning in the client, but I didn't find any configuration settings to do so.

[spinscale (Alexander Reelsen)]

The only messages on warn level in the low level rest clients are those warnings. The RequestLogger logger class in the client does not allow any customization/filtering however.

I remember that log4j has a level range filter, but I am not sure, if you can apply that on certain classes only or the general appender. (There is a regex filter, but I'm not sure I would want that in production... )

[DavidTurner]

I think the solution I'd recommend would be to stop using the deprecated feature. It is deprecated after all. There's no real advantage to using frozen indices in these recent versions.

If your application needs to support older versions of Elasticsearch then this approach will need some kind of mechanism that detects the cluster version and adjusts your application behaviour accordingly. That's generally quite useful anyway: it means you can use newer features when they're available and fall back to older alternatives otherwise.

[joschi]

@DavidTurner

I think the solution I'd recommend would be to stop using the deprecated feature. It is deprecated after all. There's no real advantage to using frozen indices in these recent versions.

I would, but:

@joschi

Since the application is still supposed to work with older versions of Elasticsearch 7.x, we cannot simply remove the deprecated ignore_throttled option.

In particular, Elasticsearch 7.10.2 should still be supported for some time and everything else is still working. It's just this very, very annoying deprecation warning which cannot be filtered.

[joschi]

@spinscale

The only messages on warn level in the low level rest clients are those warnings. The RequestLogger logger class in the client does not allow any customization/filtering however.

Yes, I saw the RequestLogger class too and that it's package protected.

@spinscale

I remember that log4j has a level range filter, but I am not sure, if you can apply that on certain classes only or the general appender. (There is a regex filter, but I'm not sure I would want that in production... )

But that would filter out all warning messages by the client, not just these specific ones, and I really don't want to route every single log message of the Elasticsearch client through a string filter which checks for ignore_throttled.

[DavidTurner]

@joschi

In particular, Elasticsearch 7.10.2 should still be supported for some time and everything else is still working. It's just this very, very annoying deprecation warning which cannot be filtered.

Repeating for emphasis:

If your application needs to support older versions of Elasticsearch then this approach will need some kind of mechanism that detects the cluster version and adjusts your application behaviour accordingly.

It's not just the deprecation warning, it's also the fact that you're using a feature which is deprecated. IMO the latter bit is worth addressing, and once addressed it'll get rid of the warning too.

[joschi]

"Deprecated" doesn't mean removed and it's still working as before. It just will be removed in some future version of Elasticsearch, i. e. in Elasticsearch 8.

I'm well aware that the option is deprecated (thanks to the warning the client logged), but I also want to disable the warning now, given that the code changes require work and one day before Christmas isn't a great time to address it, not even talking about the availability of people to perform this change in the next weeks.

So in the end, this will spam our client logs until January without any upside to it.

Maybe that's something to consider for the Elasticsearch team: Make it possible to disable deprecation warnings, not generally, but specific ones.