Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A lot of WARN messages from ElasticSearch usage #6424

Open
henning-gerhardt opened this issue Feb 17, 2025 · 4 comments
Open

A lot of WARN messages from ElasticSearch usage #6424

henning-gerhardt opened this issue Feb 17, 2025 · 4 comments
Labels

Comments

@henning-gerhardt
Copy link
Collaborator

Describe the bug
Using the current 3.8.x branch version results in a lot of warning messages like

[WARN] 2025-02-17 12:03:57,941 [http-nio-127.0.0.1-8080-exec-4] org.opensearch.client.RestClient - request [POST http://xxxx.slub-dresden.de:80/es/kitodo_task/_search?typed_
keys=true&max_concurrent_shard_requests=5&ignore_unavailable=false&expand_wildcards=open&allow_no_indices=true&ignore_throttled=true&search_type=query_then_fetch&batched_reduce_size=
512&ccs_minimize_roundtrips=true] returned 1 warnings: [299 Elasticsearch-7.17.24-fcf25fff740db6ab3ed5d145c58d70e4c3528ea7 "[ignore_throttled] parameter is deprecated because frozen
indices have been deprecated. Consider cold or frozen tiers in place of frozen indices."]

We are using ElasticSearch 7.17.24 on a dedicated host but the dedicated host should not the issue as the requests are done with an deprecated parameter like the message saying.

Expected behavior
There should be no WARN or higher level log message on normal usage.

Release
3.8.2-SNAPSHOT (may be since 3.8.0 and may be in current main branch too)

@henning-gerhardt henning-gerhardt changed the title [3.8.x] A lot of WARN messages from ElasticSearch usage A lot of WARN messages from ElasticSearch usage Feb 17, 2025
@henning-gerhardt
Copy link
Collaborator Author

Removed the 3.8.x prefix in title as I can reproduce this messages even on current main branch.

@henning-gerhardt
Copy link
Collaborator Author

Looks like that the ignore_throttled got deprecated in ElasticSearch 7.16 and before Kitodo.Production version 3.8.x the used ElasticSearch client did not use this parameter but it looks like that the OpenSearch client in 3.8.x and newer is using this deprecated parameter.

@henning-gerhardt
Copy link
Collaborator Author

henning-gerhardt commented Feb 17, 2025

More bad news:

While OpenSearch and Elasticsearch share several core features, mixing and matching the client and server has a high risk of errors and unexpected results. As OpenSearch and Elasticsearch continue to diverge, such risks may increase. Although your Elasticsearch client may continue working with your OpenSearch cluster, using OpenSearch clients for OpenSearch clusters is recommended.

So I found the first issue between using the OpenSearch client with an ElasticSearch server :-( Ignoring this WARN messages is no solution as it would hide even more important messages. Even going back to a former ElasticSearch server version is no option and switching to OpenSearch is even no option.

@henning-gerhardt
Copy link
Collaborator Author

henning-gerhardt commented Feb 17, 2025

Maybe description in https://www.ibm.com/docs/en/spectrum-symphony/7.3.2?topic=troubleshooting-suppressing-elasticsearch-deprecation-warnings-in-logs (thanks to @solth for this link) could be a work around:

These messages are informational and do not affect IBM® Spectrum Symphony functionality using Elasticsearch. You can suppress these Elasticsearch messages by configuring logger.deprecation.level = off in the $ELK_CONFDIR/elasticsearch/log4j2.properties file. The default log setting is warn; by setting the parameter to off, you can avoid seeing the warnings

but if this may be true for this IBM product this must not be the case in every scenario with Kitodo.Production.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant