Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changes Proposed
Currently, when Logstash receives an input log that is JSON, it parses the JSON properties into a field called
app
.While this behavior is nice in that it allows logs to be searched by the custom properties from the JSON log (based on the detected field type for each JSON property), it has the problem that the first log received for an index will determine the type of any fields parsed from the JSON log.
In our case where all customer logs are ingested into a shared index per day, this is problematic, since subsequent JSON logs may have different field types for keys that existed on JSON logs that have already been ingested. When this occurs, Elasticsearch will reject the incoming JSON log due to the mismatch in field types.
The proposed fix here is to use a flattened type for handling dynamic fields from JSON logs on a new
custom
field. When you use a flattened field type, the entire object for a custom JSON log is indexed and still searchable, but only using basic search functionality.So for a log like:
You could search for the document like so:
The only downside of
flattened
fields is that they can only be queried using basic search functionality, but that should be sufficient for letting users query their documents in Kibana. The enormous upside is that aflattened
field can contain a complex data-structure for searching, but only takes up 1 field in your index mappings, not 1 field per custom property in the JSON logs. Also,flattened
fields will not be subject to the field type mismatch issues that are causing some customer logs to fail ingestion.So this PR:
custom
field to be aflattened
typecustom
fieldSecurity Considerations
There are no changes to security configuration for Elasticsearch here, just changing the destination field type for custom JSON logs.