-
Notifications
You must be signed in to change notification settings - Fork 474
[Elasticsearch][Ingest pipeline] Stop truncating the elasticsearch server log messages #12813
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
Conversation
🚀 Benchmarks reportTo see the full report comment with |
|
💚 Build Succeeded
History
cc @consulthys |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Package elasticsearch - 1.17.2 containing this change is available at https://epr.elastic.co/package/elasticsearch/1.17.2/ |
…rver log messages (#12813) * Stop truncating the elasticsearch server log messages * Add more test cases
Proposed commit message
This PR fixes the ingest pipeline called
logs-elasticsearch.server-<version>-pipeline-json
that parses elasticsearch server logs.The pipeline was inherited from the Filebeat
elasticsearch
module and hasn't changed in several years. The main issue is that the pipeline makes the assumption that if themessage
field value starts with square brackets (e.g.[xyz] some log message
), thenxyz
is considered to be an index name (indexed in theelasticsearch.index.name
field) and the message is truncated to only what comes after the square brackets (i.e.some log message
). This assumption might have been true at some point in the past, but isn't the case anymore, i.e. the square brackets can contain literally anything, such as component names, class names, etc. Truncating themessage
field breaks downstream processes that expect to find the full log message in that field.For instance, when applied on the following log message
the truncated
message
field will only containis not ready for collect yet
, which now lacks context and is unsuable.As it is not easy to find out all (internal and external) downstream processes that rely on the index name to be extracted from the log message, we need to keep extracting whatever is in the square brackets, but without truncating the
message
field. This PR suggests a non-breaking change that will keep extracting the index name (if it doesn't already exist in the document), while leaving themessage
field alone.Checklist
changelog.yml
file.How to test this PR locally
message
field is unalteredResponse:
If the
elasticsearch.index.name
field is already present in the log document, then it will not be overriddenResponse:
Related issues
Closes #12501