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
awscloudwatch
input drops data
#38918
Labels
bug
Team:Elastic-Agent
Label for the Agent team
Team:Obs-InfraObs
Label for the Observability Infrastructure Monitoring team
Comments
faec
added
bug
Team:Elastic-Agent
Label for the Agent team
Team:Obs-InfraObs
Label for the Observability Infrastructure Monitoring team
labels
Apr 13, 2024
Pinging @elastic/elastic-agent (Team:Elastic-Agent) |
faec
added
Team:Cloud-Monitoring
Label for the Cloud Monitoring team
and removed
Team:Obs-InfraObs
Label for the Observability Infrastructure Monitoring team
labels
Apr 15, 2024
This was referenced Apr 15, 2024
faec
added
Team:Obs-InfraObs
Label for the Observability Infrastructure Monitoring team
and removed
Team:Cloud-Monitoring
Label for the Cloud Monitoring team
labels
Apr 15, 2024
faec
added a commit
that referenced
this issue
Apr 23, 2024
Fix a bug in cloudwatch worker allocation that could cause data loss (#38918). The previous behavior wasn't really tested, since worker tasks were computed in cloudwatchPoller's polling loop which required live AWS connections. So in addition to the basic logical fix, I did some refactoring to cloudwatchPoller that makes the task iteration visible to unit tests.
mergify bot
pushed a commit
that referenced
this issue
Apr 23, 2024
Fix a bug in cloudwatch worker allocation that could cause data loss (#38918). The previous behavior wasn't really tested, since worker tasks were computed in cloudwatchPoller's polling loop which required live AWS connections. So in addition to the basic logical fix, I did some refactoring to cloudwatchPoller that makes the task iteration visible to unit tests. (cherry picked from commit deece39)
6 tasks
faec
added a commit
that referenced
this issue
Apr 24, 2024
Fix a bug in cloudwatch worker allocation that could cause data loss (#38918). The previous behavior wasn't really tested, since worker tasks were computed in cloudwatchPoller's polling loop which required live AWS connections. So in addition to the basic logical fix, I did some refactoring to cloudwatchPoller that makes the task iteration visible to unit tests. (cherry picked from commit deece39) Co-authored-by: Fae Charlton <fae.charlton@elastic.co>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
bug
Team:Elastic-Agent
Label for the Agent team
Team:Obs-InfraObs
Label for the Observability Infrastructure Monitoring team
The
awscloudwatch
input can skip data in its target log groups, with severity depending on configuration and log size. This seems to apply to all platforms and all versions at least since 8.0.Easy reproduction:
number_of_workers
to 1 (the default)start_position
tobeginning
(the default)log_group_name_prefix
to a value matching 2 or more log groupsThe first matching log group will ingest data starting from the beginning, but all other log groups will only include data from after ingestion began.
This loss continues during ingestion: events from any time span will only include data from at most one log group at a time.
More finicky reproduction with a single log group:
number_of_workers
to 1 (the default)start_position
tobeginning
(the default)scan_frequency
to ingest -- optionally setscan_frequency
to1s
to make this easier)Data added to the log group between the start of ingestion and the completion of the first scan will be skipped.
The text was updated successfully, but these errors were encountered: