that sounds unusual indeed. message:ABC and NOT message:ABC should result in non-overlapping sets of documents with the number of matches with NOT message:ABC plus the number of matches message:ABC should equal the number of matches with *. Can you confirm that this is not the case?
Yeah this is a bit strange so e.g: I have these data for *:
-sdabcd
-sds
-abcde
When I apply the filter message: ABC:
-sdabcd
-abcde
this make sense since abc exists on -sdabcd and -abcde
When I apply the filter NON message: ABC:
Nothing shows up, but normally I should see -sds since it doesn't contain abc
I assume you're using these strings as simplified examples for your actual data. While useful to explain the issue, this makes it hard to diagnose problems with the query that might be caused by the way the data are analyzed during indexing. If you could provide example values, that reflect the shape of the field values more accurately, it might ease the investigation.
You're probably colliding with the regexp query syntax here. Try escaping the / with backslashes, as in SyscheckFile.path:\/App_Data. (In addition, for this to work correctly the SyscheckFile.path field should not be analyzed, because the default string analyzer will tokenize the value and discard puctuation like the /.)
Already tried /App_Data and *(/)*App_Data * and -SyscheckFile.path://App_Data and so forth but it seems to be strange since the same filter applied without NOT is working but when I add NOT it doesn't work, so this is mainly the problem and it can be an issue related to kibana itself since the search is translated to a Lucence query.
The query is sent to the Elasticsearch api as a query string query. No translation is happening there. What is the type of the SyscheckFile.path field in the mapping?
"type": "phrase"
But still doesn't explain the NOT filtering, and actually it can be related to that "/" but the thing is that it's working when I just apply SyscheckFile.path://App_Data
That is because the unescaped // represent an empty regex, which is matched by any string.
What I meant with the field type is the type defined for the SyscheckFile.path field in the Elasticsearch mapping of the index containing the documents. You can see the mapping by executing curl -H 'application/json' ' ${YOUR_ELASTICSEARCH_API}/${YOUR_INDEXNAME}/_mapping/*/field/SyscheckFile.path.
Since the data in that field are filesystem paths and not normal text, I would recommend setting the type of the field to keyword (If you are using Elasticsearch 5.x or later) or set "index": "not_analyzed" for earlier Elasticsearch versions. This would prevent the default analyzer from incorrectly tokenizing the path and should enable prefix queries like the one you're attempting to perform.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.