-
Notifications
You must be signed in to change notification settings - Fork 25.1k
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
Dangling meta character '*' near index 0 #24749
Comments
hey, can you provide a full stacktrace from your logs? |
...plus the full index templates that you're using, and some examples of failed docs |
Also, are you using an ingest pipeline? |
With some values obscured, here's the full stack trace with the document data:
Our setup is has queue-backed rsyslog instances writing bulk indexing requests to ES. The full index templates are as follows:
|
Do you have any examples of failed documents? |
There was an example in the exception trace:
|
sorry, didn't see that |
Hmmm nothing obvious that I can see. Your regexes should use Have you been able to narrow it down at all? eg removing parts of the template to see if the problem goes away? I'd also be interested to know if upgrading ES or Java helps. I don't have any ideas - I'll leave it for somebody else to investigate. |
This is our production cluster ingesting about 2TB of log data per day, with ~40TB total data. We don't have a lot of freedom to play around with arbitrary tests to see if the issue goes away, when it's seemingly sporadic as is. We're already on the 2.4.1 series running in docker, so I could bump to 2.4.4 but I don't have any reason to believe that that would fix the underlying problem. At this point, we don't have to operational capacity to migrate to 5.x, so I was hoping the issue would be pretty obvious from the stack trace. |
Today you would only get these errors at index time. Relates elastic#24749
I don't think 2.4.4 would fix the problem either. I suspect @clintongormley is right that a simple pattern is sometimes parsed as a regex even though it shouldn't. The fact that you mentioned that this issue is sporadic also leads me to thinking that it might be specific to one node of the cluster. I will close this issue and improve validation of the match pattern for now: #29013. Let's revisit if/when someone reports this issue with a newer version. We will have more information to understand what is happening. |
Today you would only get these errors at index time. Relates #24749
Today you would only get these errors at index time. Relates #24749
Elasticsearch version: 2.4.1 (docker)
Plugins installed: [ license, marvel-agent ]
JVM version (
java -version
): java-8-openjdk-amd64 (openjdk:8-jre docker)OS version (
uname -a
if on a Unix-like system): Linux HOSTNAME 4.4.0-34-generic #53~14.04.1-Ubuntu SMP Wed Jul 27 16:56:40 UTC 2016 x86_64 GNU/LinuxDescription of the problem including expected versus actual behavior: Elasticsearch is periodically (and seemingly randomly) rejecting log messages due to a mapper parsing exception with a nested pattern syntax expression. See below for a sample log message. There is nothing special in our setup. We have separated master/client/data nodes. We have two index templates, one which matches all indexes "" at priority 0 and one for each dedicated index, e.g. "storage-" at priority 1. Each of those index templates defines some index properties (that don't overlap), as well as some mapping properties and dynamic mapping templates, e.g.:
The issue only affects some logs in each index. The logs it affects don't have anything special in their content either. The error appears to be erroneous, but any insight would be greatly appreciated.
Steps to reproduce:
Provide logs (if relevant):
The text was updated successfully, but these errors were encountered: