-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
[receiver/filelog] record numbers are incorrect when header
is configured
#35869
Labels
Comments
andrzej-stencel
added
bug
Something isn't working
needs triage
New item requiring triage
labels
Oct 18, 2024
Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
djaglowski
pushed a commit
that referenced
this issue
Oct 28, 2024
#### Description Fixes #35869 by refactoring of the `Reader::ReadToEnd` method. This refactors the `Reader::ReadToEnd` method by separating reading the file's header from reading the file's contents. This results in very similar code in `readHeader` and `readContents` methods, which was previously deduplicated at the cost of slightly higher complexity. The bug could be fixed without separating header reading from contents reading, but I hope this separation will make it easier to implement content batching in the Reader (#35455). Content batching was my original motivation for these code changes. I only discovered the problem with record counting when reading the code. #### Link to tracking issue Fixes #35869 #### Testing In the first commit I have added tests that document the erroneous behavior. In the second commit I have fixed the bug and corrected the tests. #### Documentation Added changelog entry.
jpbarto
pushed a commit
to jpbarto/opentelemetry-collector-contrib
that referenced
this issue
Oct 29, 2024
) #### Description Fixes open-telemetry#35869 by refactoring of the `Reader::ReadToEnd` method. This refactors the `Reader::ReadToEnd` method by separating reading the file's header from reading the file's contents. This results in very similar code in `readHeader` and `readContents` methods, which was previously deduplicated at the cost of slightly higher complexity. The bug could be fixed without separating header reading from contents reading, but I hope this separation will make it easier to implement content batching in the Reader (open-telemetry#35455). Content batching was my original motivation for these code changes. I only discovered the problem with record counting when reading the code. #### Link to tracking issue Fixes open-telemetry#35869 #### Testing In the first commit I have added tests that document the erroneous behavior. In the second commit I have fixed the bug and corrected the tests. #### Documentation Added changelog entry.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Component(s)
receiver/filelog
What happened?
Description
Configuring the
header
option for the File Log receiver together withinclude_file_record_number
causes the reported record numbers to be higher than they should be. This happens even when there are no header lines in the file.Steps to Reproduce (input file with header)
Prepare input file
Run the collector with the below config
otelcol-contrib --config config.yaml
Expected Result
I would expect the "my-log" log to have
log.file.record_number
equal to1
.Actual Result
The log has
log.file.record_number
equal to3
.The output from Debug exporter shows the following log:
my-log log.file.name=logs.txt log.file.record_number=3 headerattr=xyz
Steps to Reproduce (input file without header)
Prepare input file
Run the collector with the below config
otelcol-contrib --config config.yaml
Expected Result
I would expect the "my-log" log to have
log.file.record_number
equal to1
.Actual Result
The log has
log.file.record_number
equal to2
.The output from Debug exporter shows the following log:
my-log log.file.name=logs.txt log.file.record_number=2
Collector version
v0.111.0
Environment information
No response
OpenTelemetry Collector configuration
Log output
Additional context
No response
The text was updated successfully, but these errors were encountered: