You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The argument for defining the target isn't like other logstash plugins (logstash-filter-geoip). It seems to require that I supply the field without surrounding brackets. If i use brackets, it silently adds the fields to the root of the event. Strangely however, if i target a nested field like [one][two] with the brackets, it does write the fields to that location. It is not obvious to me how this line allows that since the resulting normalized_target seems like it would be [[one][two]]. Maybe that is a valid target or I am misunderstanding what that line does.
Here is the config I expect to work but causes the filter to write fields to root:
Based on my interpretation of the code, the problem is that this normalized_target is not aware that field references can be nested. It looks like the regexp would accept foo and [foo] but would bug out when given nested [foo][bar] producing [[foo][bar]] as a field reference.
The argument for defining the target isn't like other logstash plugins (logstash-filter-geoip). It seems to require that I supply the field without surrounding brackets. If i use brackets, it silently adds the fields to the root of the event. Strangely however, if i target a nested field like
[one][two]
with the brackets, it does write the fields to that location. It is not obvious to me how this line allows that since the resultingnormalized_target
seems like it would be[[one][two]]
. Maybe that is a valid target or I am misunderstanding what that line does.Here is the config I expect to work but causes the filter to write fields to root:
Here is the config where I specify a deep path and the fields are successfully written to it as expected:
And here is the config I ended up using for this filter which works as intended but unlike other plugins in how target is specified:
This is with version 2.0.8 but the line of the code that seems to matter looks the same on master.
The text was updated successfully, but these errors were encountered: