Elastic message "Cannot extract fields for query" after Readonlyrest installation

1

Hi,
I installed elasticsearch 7.8.1 on one node windows7. I didn’t install Kibana, only elasticsearch for testing purpose. I didn’t create any indices in elasticsearch or anything else (clean installation). I installed ROR plugin for elasticsearch 7.8.1 and created a rule in readonlyrest.yml:
readonlyrest:
access_control_rules:

- name: "Require HTTP Basic Auth"
  type: allow
  auth_key: user:password

Now, when I call some specific queries (match_all, query_string), the output of curl is ok.
curl -XGET -H ‘Content-Type: application/json’ -k -vvv -u user:password http://localhost:9200/_search?q=host:test
< HTTP/1.1 200 OK
{“took”:62,“timed_out”:false,“_shards”:{“total”:0,“successful”:0,“skipped”:0,“failed”:0},“hits”:{“total”:{“value”:0,“relation”:“eq”},“max_score”:0.0,“hits”:}}

But I see WARN message in elasticsearch.log.
[2020-12-10T18:01:19,186][WARN ][t.b.r.e.r.q.QueryFieldsUsage$] [elk] Cannot extract fields for query: query_string
The same message for match_all query:
[2020-12-10T18:01:22,451][WARN ][t.b.r.e.r.q.QueryFieldsUsage$] [elk] Cannot extract fields for query: match_all

2

Hi, @peterrinka

Thanks for you report. We’ve used wrong log level for this message. It should be debug instead. Nothing to worry about. We will remove it in future release. You can ignore it.

If it’s troublesome for you, I can tell you how to reconfigure logging to get rid of it.

3

Thanks @Matheusz.
but if it’s the DEBUG message instead of the WARN one in future, will it not still indicate a problem with the queries in elasticsearch?

And please, could you tell me how to reconfigure the logging?

Many thanks again.

4

You can add this section to log4j.properties file:

logger.rorignore.name = tech.beshu.ror.es.request.queries
logger.rorignore.level = error
logger.rorignore.additivity = false

We’ve recently improved our FLS engine (details here: https://github.com/beshu-tech/readonlyrest-docs/blob/master/fls_engine.md#fls-engine). For some kind of queries we can improve the performance of the request, but other have to be handled in old style. The log tells us that the fastest method cannot be used. In general user should not be interested in this message, because it tells about our internal implementation details. With one exception, when you as a user ,pick to use the fastest method only (it’s described in docs). So, we have to improve the logging, because it seems that the log level should be different depending on ROR settings :wink: But as I said, at the moment you can ignore it :slight_smile:

5

Yes, I undestand now.

Thank you @Matheusz,
Best regards.