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
Steps to Reproduce:
Restarting Filebeat re-reads and parses the same log lines (json) every time. Can be seen easily with the console output of Filebeat. On first run it correctly outputs the parsed logline, on second, thirds, .... run it outputs it again.
Sample JSON to reproduce the issue: { "@timestamp": "2017-10-17T10:03:14.301Z", "request": "/" }
Sample Filebeat Config 5.0.1 (working) and 5.6.3 (not working):
Exiting filebeat (Ctrl+C) and starting it again doesn't produce any output on 5.0.1 as it isn't parsing anything as there are no new loglines (the one line provided as a sample has been parsed already during last run).
Running with a 5.6.3 or 6.0.0-rc1 installation it produces the same loglines on every start (download, untar, add serverlogs/apache.json file with sample provided above, add filebeat.json.yml with sample provided above, run):
Every time I exit filebeat and start it again the same lines are parsed and output (of course every time with a new parse timestamp (the duplicate timestamps is issue #5440)
The text was updated successfully, but these errors were encountered:
friesoft
changed the title
Filebeat 6.0.0-rc1: logfile are fully parsed on every start
Filebeat 6.0.0-rc1: logfiles are fully parsed on every start
Oct 25, 2017
The issue seems to happen when relative paths are used in the paths configuration. A workaround is to use absolute paths. I'm working on a fix and will open a PR shortly.
If a relative path was used in a prospector definition, it could happen
that when loading the state from the registry, the path didn't match the
pattern, which made it ignore the saved state. Fixeselastic#5442.
Additionally, this PR cleans up some code related to the `recursive_glob`
setting. The docs used to claim that the feature is disabled by default, but
that wasn't the case and it was impossible to disable it. This change leaves
it enabled by default, but makes it possible to disable it.
* Fix relative paths in prospectors definitions
If a relative path was used in a prospector definition, it could happen
that when loading the state from the registry, the path didn't match the
pattern, which made it ignore the saved state. Fixes#5442.
Additionally, this PR cleans up some code related to the `recursive_glob`
setting. The docs used to claim that the feature is disabled by default, but
that wasn't the case and it was impossible to disable it. This change leaves
it enabled by default, but makes it possible to disable it.
* addressed comments
Restarting Filebeat re-reads and parses the same log lines (json) every time. Can be seen easily with the console output of Filebeat. On first run it correctly outputs the parsed logline, on second, thirds, .... run it outputs it again.
Sample JSON to reproduce the issue:
{ "@timestamp": "2017-10-17T10:03:14.301Z", "request": "/" }
Sample Filebeat Config 5.0.1 (working) and 5.6.3 (not working):
Sample Filebeat Config 6.0.0-rc1 (not working):
Running with a 5.0.1 installation (download, untar, add serverlogs/apache.json file with sample provided above, add filebeat.json.yml with sample provided above, run):
Exiting filebeat (Ctrl+C) and starting it again doesn't produce any output on 5.0.1 as it isn't parsing anything as there are no new loglines (the one line provided as a sample has been parsed already during last run).
Running with a 5.6.3 or 6.0.0-rc1 installation it produces the same loglines on every start (download, untar, add serverlogs/apache.json file with sample provided above, add filebeat.json.yml with sample provided above, run):
Every time I exit filebeat and start it again the same lines are parsed and output (of course every time with a new parse timestamp (the duplicate timestamps is issue #5440)
In the discuss entry on elastic.co we (@kvch) agreed that this is a bug.
https://discuss.elastic.co/t/6-0-0-rc1-json-overwrite-keys-not-working-with-timestamp/105189
The text was updated successfully, but these errors were encountered: