-
Notifications
You must be signed in to change notification settings - Fork 11
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
add ECS support and target option #20
add ECS support and target option #20
Conversation
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.
🍑 I do like the proposed changes
one potential suggestion whether it makes sense to use event.original
in ECS mode, that would represent the JSON "line" ... might be far fetched given that the original data is a multiline string that gets split-ed.
spec/codecs/es_bulk_spec.rb
Outdated
next LogStash::Codecs::ESBulk.new | ||
end | ||
describe LogStash::Codecs::ESBulk, :ecs_compatibility_support do | ||
ecs_compatibility_matrix(:disabled, :v1, :v8 => :v1) do |ecs_select| |
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.
I think we want to test with setting the field to v8
:
ecs_compatibility_matrix(:disabled, :v1, :v8 => :v1) do |ecs_select| | |
ecs_compatibility_matrix(:disabled, :v1, :v8) do |ecs_select| |
event = LogStash::Event.new(line) | ||
event.set("@metadata", @metadata) | ||
event = targeted_event_factory.new_event(line) | ||
event.set(@metadata_field, @metadata) | ||
yield event |
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.
would it make sense to event.set('[event][original]', bulk.get("message").dup.freeze)
in ECS mode?
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.
There are four options here. Considering the following input
{ "index" : { "_index" : "test", "_type" : "type1", "_id" : "1" } }
{ "field1" : "value1" }
{ "delete" : { "_index" : "test", "_type" : "type1", "_id" : "2" } }
{ "create" : { "_index" : "test", "_type" : "type1", "_id" : "3" } }
{ "field1" : "value3" }
{ "update" : {"_id" : "1", "_type" : "type1", "_index" : "index1"} }
{ "doc" : {"field2" : "value2"} }
-
Store the whole input as
event.original
.
The input generates four events. Each event saves the complete raw data.
It could generate too much extra bandwidth -
Store { "field1" : "value1" } as
event.original
.
This is the line when target_event_factory is called. Metadata is not included. The information is not complete.
This is the result ofevent.set('[event][original]', bulk.get("message").dup.freeze)
The information is not particularly interesting because the same stuff transforms into an event. -
tailor-make a new line to concatenate metadata { "index" : { "_index" : "test", "_type" : "type1", "_id" : "1" } } and data { "field1" : "value1" }
This will be a full event that requires concatenating the decoded string -
do not store
event.original
I am opened to save it in event.original
if you think it is useful
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.
oh right, it's tricky with the multi-line and the managed state ... was undecided on this making sense.
Reading your comments I am leaning towards 4. do not store event.original
for now and ship as is...
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.
🍒
add
target
optionFixed: #19