Skip to content
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

'logfmt' parser doesn't parse empty string as expect #1737

Closed
GaoyangWang opened this issue Nov 13, 2019 · 2 comments
Closed

'logfmt' parser doesn't parse empty string as expect #1737

GaoyangWang opened this issue Nov 13, 2019 · 2 comments
Assignees

Comments

@GaoyangWang
Copy link

Bug Report

Describe the bug
When I config 'logfmt' parser to parse the input content, such as: key1="" key2 key3="this is value", it will parse key1 as same as key2, a boolean value "true". For the expected 'logfmt' behaviour, key1 should be an empty string instead of a boolen value.

To Reproduce

  • Rubular link if applicable:
  • Example log message if applicable:
key1="" key2 key3=123 key4="this is a text"
  • Steps to reproduce the problem:
  1. just use the hello_world example
  2. config parser as 'logfmt'
  3. add a lua filter to handle the input parser's result
  4. the data (messagepack) pass to filter, key1 is stored as a boolean value.

Expected behavior
'logfmt' should support to parse an empty string.

Screenshots

Your Environment

  • Version used: 1.3.2
  • Configuration:
  • Environment name and version (e.g. Kubernetes? What version?):
  • Server type and version:
  • Operating System and version: Ubuntu 18.04.3
  • Filters and plugins: Lua filter and 'logfmt' parser plugin

Additional context

@GaoyangWang
Copy link
Author

I think the root cause is in src/flb_parser_logfmt.c line 173:

if (value_len == 0) {
    msgpack_pack_true(tmp_pck);
}

@edsiper edsiper self-assigned this Dec 10, 2019
edsiper added a commit that referenced this issue Dec 10, 2019
edsiper added a commit that referenced this issue Dec 10, 2019
@edsiper
Copy link
Member

edsiper commented Dec 10, 2019

thanks for reporting and troubleshooting the root cause of the issue.

I've pushed a fix into GIT Master and on 1.3 branches for the next v1.3.4 release this week. The output will look as follows:

{"date":1576020907.000000,"key1":"","key2":null,"key3":"123","key4":"this is a text"}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants